- This topic has 2 replies, 1 voice, and was last updated 8 years, 4 months ago by
.
-
Posts
-
-
Hi All!
We exposed a simple orchestration as web service on our server, which has good configuration. The orch. simply receives a msg, applies a map to it and returns (Both schemas only containing 3 elements, so pretty simple). I made a sample windows app. then to call that orchestration as web service, when I run that app. on server, the response time is pretty consistent and short.
But when I run the test app. from my own machine (which is on a domain, server is on workgroup), the response times are variable and sometimes quiet large. like once it took around 1 minute to give response and once it took around 2 seconds, so the differences b/w response time are variable. I want to know what might be causing this?, the fact that I am on a domain and the server on a workgroup makes a difference?, I've got a reasonable machine with 512 MB ram, 2.66 Ghz processor, would the slowness of my machine could cause this? or something else…
Regards,
Sajid.
-
Like you, I am seeing variable response times for my same orchestration to run. My test used a simple HelloWorld type of orchestration which featured a call to a custom .NET assembly which only returned a different string every time when the orch calls it.
My orch consistently took 6 to 8 seconds on the first run, and then just under 1 second on all successive calls. I tried it with two kinds of ports: a file-drop, and a web service. Both port types showed roughly the same speeds for the request-response cycle. The same pattern always occurs here: The first run is slow, and the rest of the invocations are fast. Everything is running on one basic development workstation on WinXP with no network hops.
You might check that your paging file in WinXP is smaller (preferably much smaller) than 1 GB during your tests because I have seen low memory conditions and paging to disk really bog my computer. Also might check that your antivirus is not hogging the cpu and disk resources during tests.
-
Thanks for the reply,
I guess you are right the same is happening with me, the initial request takes considerably more time and then the following requests take lesser and more consistent time to process requests. What I've read about biztalk, why it should be doing this is that, when the process (BizTalk assembly containing the process) isn't utilized for a specified amount of time, it is unloaded from the memory, hence when you call it after that it takes time to process the request, but after that it loads that assembly in the memory for a specific period of time and calls made to it during that time would process faster and more consistently.
But this creates the problem of those initial calls (when the biztalk assembly is not loaded in the memory) would take more time, thats not a desirable option in most cases, so my question now is how can we avoid that initial lag in time that happens because of the assembly being not already loaded in the memory?
Also, is their a way we can set the time in biztalk to keep the assembly in memory, if the assembly isn't utilized (called)? and what would be the impacts of increasing that time?
Regards,
Sajid.
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.