Hi, >Does anyone have any solid information about the scalability of Tomcat? It >seems very limiting to me, but that is hopefully due to improper
What are you looking for by "solid information"? ;) Here are some details about one of our environments: An 18-CPU Sun Ultra Enterprise-class server, 4GB RAM on the machine. About 20 tomcat instances, all 4.x. Various JVM sizes from very small to 1GB. Various amounts of concurrent users, but the biggest JVM does support hundreds of concurrent users. Pretty much vanilla tomcat configuration, except increased (100) number of min and max processors. We hardly ever have to restart due to emergencies. We restart monthly just out of habit and because no app, no server is perfect, and we want to be safe. Does that answer your question? I'd be surprised if it did, because our apps are likely to be very different, and thus present different stress characteristics to the server and the underlying JVM. Do you have load tests in place that simulate user action over a few days? Tests that you can run in a test environment that's a copy of production? >Tomcat 3.2.4 - contexts *are* reloadable right now I would update tomcat to the latest stable release. There have been many performance improvements and bug fixes. Stability and scalability should both be improved, all else being equal. >application are served by Tomcat 3.2.4. About 80-120 people per day log >into this application and spend anywhere from 10 minutes to one hour >working >on the application. At any given time there are between 15 and 50 active >database connections. There are not huge numbers. >Tomcat needs to be restarted every few days. If we don't restart it, it >seems tomcat eventually locks up and does not respond at all. No errors or >anything are reported, it just will not respond. Apache continues to work >during this time and all static HTML pages are accessible. Perhaps it would be worth your while to turn on more tomcat internal logging, if you haven't done so already. I don't know how to do it in tomcat 3.x, but in 4.x you can get ample information about tomcat's internal processes by increasing the logging levels for certain components. Have you tried using OS-level tools to look for thread locks? I think JDK 1.4 also have something (ctrl-break or something like that, when running from a console) that will show you deadlocks. >RAM - This slowly increases and never stops increasing. We do not have any >special parameters set for the VM when it starts, but this does not seem to >matter. The RAM gets up to about 135 MB after four or five days, but would >continue to grow if tomcat were not allowed. What's your -Xmx setting, if any? The JVM by default will only allocate 64MB on the heap, plus a bit extra for overhead. People have complained in the past the the Linux top and ps outputs regarding memory size are confusing. >normal, should we just throw more hardware at it? Are there configuration >parameters that can be used to increase performance, such as set >reloadable=false in all contexts? Would we get better performance if we >upgraded to 4.x, or would that just be more work for little improvement? Hardware can't hurt ;) But your load doesn't seem that high. I would say upgrade to the latest tomcat and JVM, if that doesn't pose a problem for you. If your app is to the servlet spec, hopefully you don't have too much work in order to upgrade. Turn off reloadable="true" unless you need it. Play with the number of request processing threads. But try to do all this after you develop realistic load tests so that you can test and compare each configuration, and find the bounds for each one... Yoav Shapira Millennium ChemInformatics
This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
-- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
