I have a web service that is deployed as part of a larger application deployed on a PXI RT chassis and it currently contains almost 50 VIs. In the development environment, it takes probably less than 1 minute to deploy all of the VIs. When built into an exe, it takes on the order of 5 minutes before the web service starts. Does anyone have any thoughts as to why it takes so long to deploy the web service? Is there some kind of checkbox in the build spec that I ought to be hitting to get this to do what it is supposed to do?
Is this behavior happening when you run the executable from your Windows PC, when when you run it from the RT PXI target, or both?
If this is happening when running on Windows only, this is expected behavior caused by the non-deterministic nature of Windows. The executable often does not actually start running for 4-5 minute, despite the fact that it shows up as running in Task Manager.
Sigh...that's bizarre and I would say undesirable behavior. But, no, I am running on a PXI-RT machine. TBH - when I run it from the development environment (i.e. right click and hit start), it takes < 1 minute to load (still too long for me, but considerably better, especially when considering that it is throwing up all those ws front panels).
Does all the other functionality of the project seem to be starting on time? How can you tell? I want to make sure this is specific to the Web Service and not a case of the whole application starting up slowly.
So far as I can tell the web service is always the slowest part of the application to deploy. In development mode, you hit start and every front panel has to launch before the system even starts to deploy. In the run time environment when debugging, the same thing happens except now the front panels take foooooorrrrrrevvvvvver to spawn. It's not clear why but this has become a huge problem when trying to figure out what is going on. All this being said, it is not clear to me that this is the sole problem, but in the development environment, the system is relatively fast to launch.
One thing that is odd is that when rebooting with the exe, the system is relatively slow to respond to icmp packets (ping) on boot.
I will try to get timing information on all of this so that we have a more complete picture.
I'm interested to see how long it takes for the web services to start up when you are running an example project. This is a good way to take the code out of the equation. Please try running Web Services - Weather Monitor RT.lvproj from the LabVIEW example finder on your RT PXI target and let me know the behavior.
Takes over 5 minutes for web services to start in this project and that is too long. Start getting 404 messages at about 4 minutes. Takes less than 30 seconds to respond to a ping and to see activity associated with the main VI on the distributed system manager. I should have prefaced this with - when the web service was smaller, it didn't take this long to respond.
The weather app returns almost immediately.
Takes over 5 minutes for web services to start in this project and that is too long.
Are you referring to your project or the weather web services project?
Are the VIs with web services just taking a long time to deploy? Are they taking 5 minutes to respond after they are already deployed?
What is the time difference between running the weather web services project in the development environment vs running it as an executable on your RT PXI?
This KnowledgeBase article might be helpful if you have not yet seen it.
The weather service app fires up immediately.
Takes over 5 minutes before the web service in my project responds (in the executable) while the core application appears to be running within the first minute after boot.
Time difference is essentially 5+ minutes between the weather app web service response and my project's web service response.
The knowledge base article you are linking to is not relevant. This article is concerned with remote front panels and the response of them. The client computer in this case has NO LVRTE on it as it communicates solely through a web based interface. Also, this article is concerned when the app is not responsive at all as opposed to this case where the app is just slow to respond.