0.8sec is in -nosec scenario. Yes, in this scenario, I could not infer the 2 container thread limit. However, when I enabled signing and encryption on the communication channel (GSI Transport) or messages (GSI Secure Conversation), I could see the obvious delays among request processing at server side: 2 responses at a time and interleaved by about 10 seconds. Client side overhead was ruled out by comparing starting timestamps.
My purpose of conducting this test is to measure service invocation overhead given different security options: no security, channel level, or message level. The performance of my service code has been tested separately. Thanks, Sam. ---------------------------------------- > Date: Wed, 23 Jan 2008 14:39:06 -0600 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: [email protected] > Subject: Re: [gt-user] WS Core containerThreads not working > > If you have such short requests that they can be handled in 0.8 sec, > then how do you know that there are only 2 at a time being serviced? > > Here is the test I would do to see how many threads are really running. > > In the service code, add a sleep 60 sec call... and on the client, start > as many threads, which is hopefully larger than what you set as a max on > the GT4 container, something on the order of O(100s), and invoke the > service as fast as possible from all client threads. If for example you > had a max of 50 threads set on the GT4 container, you would see after 60 > seconds that 50 invocations were completed successfully, then after > another 60 sec, another 50 invocations, etc... if indeed you only have 2 > threads, then you would see only 2 at a time every 60 sec. > > Now, about seeing performance difference in your own code (without the > sleep 60) as you increase the number of threads, it all depends on your > specific code and what the client/service are doing. Also, from my > experience, the client side is generally more heavy weight that the > service side... which means that you will need multiple concurrent > clients to generally saturate a given service. > > Ioan > > Samuel LIU wrote: >> I am trying to test the service response time of a Grid service I wrote >> given different request rate. By default, WS Core sets initial thread number >> to be 2. When I started globus container w/ -nosec, I could not see much >> difference. All requests were served within 0.8 sec. However, when I started >> container with GSI Transport or GSI Secure Conversation settings, I could >> see clearly two requests were served at a time. >> >> The problem is: based on gt4 doc, when I changed thread settings to: >> >> >> >> >> >> and restarted container, I saw no difference: still 2 requests were accepted >> at one time, then another 2, ... >> >> Can anyone suggest what went wrong? I am using globus 4.0.5 on a CentOS >> machine. >> >> Thanks, >> Sam. >> _________________________________________________________________ >> Climb to the top of the charts! Play the word scramble challenge with star >> power. >> http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan >> >> > > -- > ================================================== > Ioan Raicu > Ph.D. Candidate > ================================================== > Distributed Systems Laboratory > Computer Science Department > University of Chicago > 1100 E. 58th Street, Ryerson Hall > Chicago, IL 60637 > ================================================== > Email: [EMAIL PROTECTED] > Web: http://www.cs.uchicago.edu/~iraicu > http://dev.globus.org/wiki/Incubator/Falkon > http://www.ci.uchicago.edu/wiki/bin/view/VDS/DslCS > ================================================== > ================================================== > > _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail®-get your "fix". http://www.msnmobilefix.com/Default.aspx
