concurrent user threading problem
hi all, orry for the long mail; i'm at my witts end here, and just wanted to check that i'm not losing my marbles! we have been running a commercial app on tomcat for the last two years. we've had intermittent out of memory problems processing large pages meaning we've had to reboot occasionally (the app produces xml, transforms it using xslt to output html), but in general the performance has been good and the app has been stable. as the business has been growing, we recently upgraded to a new funky dell server, multiprocessor with hyperthreading, but this seems to have exacerbated the problem dramatically: we now have a situation where if a single user requests a page, it is lightening fast, but once there are two requests at the same time, both are about 100 times slower; i would expect twice slower at most. once returning to only one request at a time, the speed recovers immediately. in top you can see that java has 100% of the CPU time, and one of the 4 effective CPU's is maxed out. so i'm desperately trying to track down the cause of this problem; i'm guessing it must be some kind of race condition. we have reviewed all our code, ensured that methods accessing shared objects are synchronized, been through all the config, removed most of the logging etc etc, and upgraded to tomcat 4.1.29 and all to no avail; we don't seem to be able to narrow down where the problem could be. what i wanted to check was: the app has one servlet only, through which all requests are processed. all requests go through the doGet method. to try and check if our code was to blame, we synchronised this method. my understanding is that this would mean if two requests were received at approximately the same time, one would have to wait until after the first had been processed, meaning the two requests could not access any of our code at the same time, and therefore the second would be say twice as slow as the first. however, this is not the case, still they are both about 100 times slower. this makes me think that it cannot be an error in our code? but then tomcat seems to serve concurrent users on other people's apps with no problem, so i can't believe tomcat is to blame. is my assumption about synchronizing the doGet method correct? is there anything special i should know about using tomcat on a multiprocessor server? any suggestions at all greatfully received! thanks, tamsin ps: tomcat: 4.1.29 java: 1.4.2 postgresql: 7.3.4 saxon xerces - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrent user threading problem
phew. problem resolved! for info, we switched the kernel on the new server to use a single processor (no hyperthreading) and it is now fine. very strange that the problem occured though, i don't know what part of the system didn't like the hyperthreading. tamsin hi all, orry for the long mail; i'm at my witts end here, and just wanted to check that i'm not losing my marbles! we have been running a commercial app on tomcat for the last two years. we've had intermittent out of memory problems processing large pages meaning we've had to reboot occasionally (the app produces xml, transforms it using xslt to output html), but in general the performance has been good and the app has been stable. as the business has been growing, we recently upgraded to a new funky dell server, multiprocessor with hyperthreading, but this seems to have exacerbated the problem dramatically: we now have a situation where if a single user requests a page, it is lightening fast, but once there are two requests at the same time, both are about 100 times slower; i would expect twice slower at most. once returning to only one request at a time, the speed recovers immediately. in top you can see that java has 100% of the CPU time, and one of the 4 effective CPU's is maxed out. so i'm desperately trying to track down the cause of this problem; i'm guessing it must be some kind of race condition. we have reviewed all our code, ensured that methods accessing shared objects are synchronized, been through all the config, removed most of the logging etc etc, and upgraded to tomcat 4.1.29 and all to no avail; we don't seem to be able to narrow down where the problem could be. what i wanted to check was: the app has one servlet only, through which all requests are processed. all requests go through the doGet method. to try and check if our code was to blame, we synchronised this method. my understanding is that this would mean if two requests were received at approximately the same time, one would have to wait until after the first had been processed, meaning the two requests could not access any of our code at the same time, and therefore the second would be say twice as slow as the first. however, this is not the case, still they are both about 100 times slower. this makes me think that it cannot be an error in our code? but then tomcat seems to serve concurrent users on other people's apps with no problem, so i can't believe tomcat is to blame. is my assumption about synchronizing the doGet method correct? is there anything special i should know about using tomcat on a multiprocessor server? any suggestions at all greatfully received! thanks, tamsin ps: tomcat: 4.1.29 java: 1.4.2 postgresql: 7.3.4 saxon xerces - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrent user threading problem
Hello very strange that the problem occurred though, i don't know what part of the system didn't like the hyperthreading. What operating system are you running? Regards Harry Mantheakis London, UK phew. problem resolved! for info, we switched the kernel on the new server to use a single processor (no hyperthreading) and it is now fine. very strange that the problem occured though, i don't know what part of the system didn't like the hyperthreading. tamsin hi all, orry for the long mail; i'm at my witts end here, and just wanted to check that i'm not losing my marbles! we have been running a commercial app on tomcat for the last two years. we've had intermittent out of memory problems processing large pages meaning we've had to reboot occasionally (the app produces xml, transforms it using xslt to output html), but in general the performance has been good and the app has been stable. as the business has been growing, we recently upgraded to a new funky dell server, multiprocessor with hyperthreading, but this seems to have exacerbated the problem dramatically: we now have a situation where if a single user requests a page, it is lightening fast, but once there are two requests at the same time, both are about 100 times slower; i would expect twice slower at most. once returning to only one request at a time, the speed recovers immediately. in top you can see that java has 100% of the CPU time, and one of the 4 effective CPU's is maxed out. so i'm desperately trying to track down the cause of this problem; i'm guessing it must be some kind of race condition. we have reviewed all our code, ensured that methods accessing shared objects are synchronized, been through all the config, removed most of the logging etc etc, and upgraded to tomcat 4.1.29 and all to no avail; we don't seem to be able to narrow down where the problem could be. what i wanted to check was: the app has one servlet only, through which all requests are processed. all requests go through the doGet method. to try and check if our code was to blame, we synchronised this method. my understanding is that this would mean if two requests were received at approximately the same time, one would have to wait until after the first had been processed, meaning the two requests could not access any of our code at the same time, and therefore the second would be say twice as slow as the first. however, this is not the case, still they are both about 100 times slower. this makes me think that it cannot be an error in our code? but then tomcat seems to serve concurrent users on other people's apps with no problem, so i can't believe tomcat is to blame. is my assumption about synchronizing the doGet method correct? is there anything special i should know about using tomcat on a multiprocessor server? any suggestions at all greatfully received! thanks, tamsin ps: tomcat: 4.1.29 java: 1.4.2 postgresql: 7.3.4 saxon xerces - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrent user threading problem
redhat.. version: rpm -q redhat-release redhat-release-8.0-8 is that the right way to find the OS version?? tamsin Hello very strange that the problem occurred though, i don't know what part of the system didn't like the hyperthreading. What operating system are you running? Regards Harry Mantheakis London, UK phew. problem resolved! for info, we switched the kernel on the new server to use a single processor (no hyperthreading) and it is now fine. very strange that the problem occured though, i don't know what part of the system didn't like the hyperthreading. tamsin hi all, orry for the long mail; i'm at my witts end here, and just wanted to check that i'm not losing my marbles! we have been running a commercial app on tomcat for the last two years. we've had intermittent out of memory problems processing large pages meaning we've had to reboot occasionally (the app produces xml, transforms it using xslt to output html), but in general the performance has been good and the app has been stable. as the business has been growing, we recently upgraded to a new funky dell server, multiprocessor with hyperthreading, but this seems to have exacerbated the problem dramatically: we now have a situation where if a single user requests a page, it is lightening fast, but once there are two requests at the same time, both are about 100 times slower; i would expect twice slower at most. once returning to only one request at a time, the speed recovers immediately. in top you can see that java has 100% of the CPU time, and one of the 4 effective CPU's is maxed out. so i'm desperately trying to track down the cause of this problem; i'm guessing it must be some kind of race condition. we have reviewed all our code, ensured that methods accessing shared objects are synchronized, been through all the config, removed most of the logging etc etc, and upgraded to tomcat 4.1.29 and all to no avail; we don't seem to be able to narrow down where the problem could be. what i wanted to check was: the app has one servlet only, through which all requests are processed. all requests go through the doGet method. to try and check if our code was to blame, we synchronised this method. my understanding is that this would mean if two requests were received at approximately the same time, one would have to wait until after the first had been processed, meaning the two requests could not access any of our code at the same time, and therefore the second would be say twice as slow as the first. however, this is not the case, still they are both about 100 times slower. this makes me think that it cannot be an error in our code? but then tomcat seems to serve concurrent users on other people's apps with no problem, so i can't believe tomcat is to blame. is my assumption about synchronizing the doGet method correct? is there anything special i should know about using tomcat on a multiprocessor server? any suggestions at all greatfully received! thanks, tamsin ps: tomcat: 4.1.29 java: 1.4.2 postgresql: 7.3.4 saxon xerces - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrent user threading problem
anorakgirl, as the business has been growing, we recently upgraded to a new funky dell server, multiprocessor with hyperthreading, but this seems to have exacerbated the problem dramatically: we now have a situation where if a single user requests a page, it is lightening fast, but once there are two requests at the same time, both are about 100 times slower; i would expect twice slower at most. once returning to only one request at a time, the speed recovers immediately. in top you can see that java has 100% of the CPU time, and one of the 4 effective CPU's is maxed out. however, this is not the case, still they are both about 100 times slower. this makes me think that it cannot be an error in our code? Despite the slowness, are there any actual errors? Like, do you get weird NPEs or OutOfMemoryErrors or anything like that? If not, then it is likely a synchronization issue. If you are using an XSLT processor, is it shared and synchronized? If you don't share one processor, do you pool them instead? I worked on a project that used XSLT to transform large XML documents into even larger HTML documents. We found that one of the ways we could speed up the transformations was by pooling pre-initialized XSLT transformer objects. Then, your only synchronization bottleneck is when you request a transformer object, instead of waiting for an entire transform to occur. Of course, if you drain the pool, your new request will have to wait... -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrent user threading problem
All, phew. problem resolved! That's good! for info, we switched the kernel on the new server to use a single processor (no hyperthreading) and it is now fine. That's bad! very strange that the problem occured though, i don't know what part of the system didn't like the hyperthreading. Were you using IBM or Sun JDK? Does anyone have a mental picture of how hyperthreading is affecting the VM? Not technically speaking, but epidemiologically? I mean, do JVMs simply not work using the hyperthreading technology, or are some having good luck with them? -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrent user threading problem
Hello rpm -q redhat-release redhat-release-8.0-8 Complete shot in the dark - I have not yet got round to using Java with Linux - but you may want to check out the compatibility of your RH version with your hardware. Start with Red Hat themselves, but you could even try looking at the IBM site for any write ups or reports on this. Blackdown has a 'linux-java' forum that might be worth looking at too. Good luck. Harry Mantheakis London, UK redhat.. version: rpm -q redhat-release redhat-release-8.0-8 is that the right way to find the OS version?? tamsin Hello very strange that the problem occurred though, i don't know what part of the system didn't like the hyperthreading. What operating system are you running? Regards Harry Mantheakis London, UK phew. problem resolved! for info, we switched the kernel on the new server to use a single processor (no hyperthreading) and it is now fine. very strange that the problem occured though, i don't know what part of the system didn't like the hyperthreading. tamsin hi all, orry for the long mail; i'm at my witts end here, and just wanted to check that i'm not losing my marbles! we have been running a commercial app on tomcat for the last two years. we've had intermittent out of memory problems processing large pages meaning we've had to reboot occasionally (the app produces xml, transforms it using xslt to output html), but in general the performance has been good and the app has been stable. as the business has been growing, we recently upgraded to a new funky dell server, multiprocessor with hyperthreading, but this seems to have exacerbated the problem dramatically: we now have a situation where if a single user requests a page, it is lightening fast, but once there are two requests at the same time, both are about 100 times slower; i would expect twice slower at most. once returning to only one request at a time, the speed recovers immediately. in top you can see that java has 100% of the CPU time, and one of the 4 effective CPU's is maxed out. so i'm desperately trying to track down the cause of this problem; i'm guessing it must be some kind of race condition. we have reviewed all our code, ensured that methods accessing shared objects are synchronized, been through all the config, removed most of the logging etc etc, and upgraded to tomcat 4.1.29 and all to no avail; we don't seem to be able to narrow down where the problem could be. what i wanted to check was: the app has one servlet only, through which all requests are processed. all requests go through the doGet method. to try and check if our code was to blame, we synchronised this method. my understanding is that this would mean if two requests were received at approximately the same time, one would have to wait until after the first had been processed, meaning the two requests could not access any of our code at the same time, and therefore the second would be say twice as slow as the first. however, this is not the case, still they are both about 100 times slower. this makes me think that it cannot be an error in our code? but then tomcat seems to serve concurrent users on other people's apps with no problem, so i can't believe tomcat is to blame. is my assumption about synchronizing the doGet method correct? is there anything special i should know about using tomcat on a multiprocessor server? any suggestions at all greatfully received! thanks, tamsin ps: tomcat: 4.1.29 java: 1.4.2 postgresql: 7.3.4 saxon xerces - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrent user threading problem
thanks all for the pointers, i will look into the hardware/os stuff, not really something i know anything about. it was the sun jdk, trying the ibm one was going to be the next step. as its working now and the users are happy, i'm going to take an afternoon off to make up for the late nights i've had on this! thanks again, tamsin All, phew. problem resolved! That's good! for info, we switched the kernel on the new server to use a single processor (no hyperthreading) and it is now fine. That's bad! very strange that the problem occured though, i don't know what part of the system didn't like the hyperthreading. Were you using IBM or Sun JDK? Does anyone have a mental picture of how hyperthreading is affecting the VM? Not technically speaking, but epidemiologically? I mean, do JVMs simply not work using the hyperthreading technology, or are some having good luck with them? -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrent user threading problem
Hi Tamsin: I might face the same problem like you did. I am just wondering if you are still trying to find a way to make your webapp run on the new hardware with hyperthreading turned on? If yes, what if the compiler used to compile your code wasnt optimised for a hyperthreaded environment ? I might be wrong, but maybe compiling tomcat or / and compiling your webapp with a compiler that does optimizations for a hyperthreaded environment might solve the issue. If you are doing some tests in this regards and have results do let me know. Thanks. On Thursday, November 13, 2003, at 05:21 AM, tamsin wrote: phew. problem resolved! for info, we switched the kernel on the new server to use a single processor (no hyperthreading) and it is now fine. very strange that the problem occured though, i don't know what part of the system didn't like the hyperthreading. tamsin hi all, orry for the long mail; i'm at my witts end here, and just wanted to check that i'm not losing my marbles! we have been running a commercial app on tomcat for the last two years. we've had intermittent out of memory problems processing large pages meaning we've had to reboot occasionally (the app produces xml, transforms it using xslt to output html), but in general the performance has been good and the app has been stable. as the business has been growing, we recently upgraded to a new funky dell server, multiprocessor with hyperthreading, but this seems to have exacerbated the problem dramatically: we now have a situation where if a single user requests a page, it is lightening fast, but once there are two requests at the same time, both are about 100 times slower; i would expect twice slower at most. once returning to only one request at a time, the speed recovers immediately. in top you can see that java has 100% of the CPU time, and one of the 4 effective CPU's is maxed out. so i'm desperately trying to track down the cause of this problem; i'm guessing it must be some kind of race condition. we have reviewed all our code, ensured that methods accessing shared objects are synchronized, been through all the config, removed most of the logging etc etc, and upgraded to tomcat 4.1.29 and all to no avail; we don't seem to be able to narrow down where the problem could be. what i wanted to check was: the app has one servlet only, through which all requests are processed. all requests go through the doGet method. to try and check if our code was to blame, we synchronised this method. my understanding is that this would mean if two requests were received at approximately the same time, one would have to wait until after the first had been processed, meaning the two requests could not access any of our code at the same time, and therefore the second would be say twice as slow as the first. however, this is not the case, still they are both about 100 times slower. this makes me think that it cannot be an error in our code? but then tomcat seems to serve concurrent users on other people's apps with no problem, so i can't believe tomcat is to blame. is my assumption about synchronizing the doGet method correct? is there anything special i should know about using tomcat on a multiprocessor server? any suggestions at all greatfully received! thanks, tamsin ps: tomcat: 4.1.29 java: 1.4.2 postgresql: 7.3.4 saxon xerces - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrent user threading problem
Mufaddal, I might be wrong, but maybe compiling tomcat or / and compiling your webapp with a compiler that does optimizations for a hyperthreaded environment might solve the issue. If you are doing some tests in this regards and have results do let me know. It's not Tomcat that would have to be recompiled, but the JVM or, more importantly, the JIT. Good luck with that! I had some colleagues that were in the Sun no-holds-barred developer group that could download the source code to the VMs and JITs. Unfortunately, the code they let you download wasn't compilable. :( I think you'll have to wait for support from Sun/IBM or the OS supported (which may actually be Sun or IBM, depending on the architecture). -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
