Just got back. In my test, each client is a java process, not thread. So each client needs to initiate client stubs. Based on your suggestion, I changed my test using java threads. then I saw consistent responses from server. However, the number of threads at server side did not change regardless how many simultaneous threads I created. The number is 72.
Whether to use process or thread to do this test is based on the realistic environment that this test wants to simulate. I think process is the correct way to go. That is, we have to assume that each JVM is on a different machine. I still don't understand why using java processes caused so much delay at server side. BTW, I did not draw any conclusion saying that only 2 threads were there at server processing requests. I posted it as a question. Thanks, Sam. ---------------------------------------- > Date: Wed, 23 Jan 2008 17:35:41 -0600 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: [email protected] > Subject: Re: [gt-user] WS Core containerThreads not working > > I don't see how you came to the conclusion that only 2 service threads > are running in the container. Also, the performance will also depend on > whether or not you are reusing port stubs, as the first invocation is > extremely expensive as opposed to subsequent invocations. Here are some > throughput numbers I obtained a while back using GT4.0.4 on a dual Xeon > 3GHz with HT and 32 client nodes and 20 threads at the container: > > * no security: 500 WS calls per sec > * GSISecureConversation: 204 WS calls per sec > * GSITransport: 65 WS calls per sec > > There are also different settings for each security mechanism, such as > encryption and integrity checks, which can affect performance. The > number above (for the 2 security cases) are with encryption. > > I heard that GT4.1.x and GT4.2.x are using persistent sockets, which > hurt the performance of the GSITransport. I expect the GSITransport to > be significantly better in the latest GT version. Another thing to > remember is that these numbers reflect the re-use of port stubs on the > client side. Without re-using the port stubs, my intuition says that > the throughput would be one to two orders of magnitude lower, but I > haven't actually measured it to know for sure. > > In conclusion, you think that you only have 2 threads servicing the WS > calls at the GT4 container. I believe your tests are inconclusive based > on what you described so far. Can you be more specific on the tests and > results you have done, which leads you to believe that there are only 2 > threads (when in fact you have set it higher)? > > Ioan > > > Samuel LIU wrote: >> 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 >> > _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail®-get your "fix". http://www.msnmobilefix.com/Default.aspx
