-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Munirathinavel,
One post is sufficient: we all got a copy. On 2/13/2010 8:48 AM, Munirathinavel wrote: > I'm using Tomcat 6.0.18 & apache2.2 server & I need to know configure my > server.xml & context.xml for high performance & heavy traffic. It's always best to have the most up-to-date version of your software. Tomcat 6.0.24 is available: you might want to consider using that in your testing environment from here on out. How do you connect Apache httpd to Tomcat? What purpose does httpd serve? > <GlobalNamingResources> > <Resource name="UserDatabase" auth="Container" > type="org.apache.catalina.UserDatabase" > description="User database that can be updated and saved" > factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > pathname="conf/tomcat-users.xml" /> > </GlobalNamingResources> Do you need this UserDatabase in here? I wouldn't use that in production. > <Service name="Catalina"> > <Connector port="8009" debug="0" enableLookups="false" > protocol="AJP/1.3" > maxThreads="120" minSpareThreads="30" maxSpareThreads="60" > reloadable="false" connectionTimeout="20000" > redirectPort="8443"/> Here's where things get interesting: Does 120 simultaneous connections sound like a reasonable load for your webapp? What kinds of loads do you /want/ to be able to handle? If you need to be able to handle huge amounts of traffic, you might want to consider removing Apache httpd from your setup. You haven't said what you use it for: some people use it work static content hosting, which isn't a good enough reason. Others use it for load balancing, which you haven't mentioned so I assume you aren't. Some folks, like me, use it to direct traffic to more than one instance of Tomcat when a hardware load-balancer isn't available. If you aren't doing any of these things, then get rid of httpd: it's just slowing things down. If you have a lot of keepalive requests, consider using the NIO connector which doesn't tie up request processing threads while waiting for the 3nd, 3rd, etc. request on the same connection. If you need to send large static files, definitely consider using the APR connector with sendFile="true". If you need SSL, also consider using the APR connector, as the OpenSSL-based SSL implementation is faster than the one you get with the Java provider. Finally, the use of an <Executor> is usually recommended because those thread pools can dynamically size themselves. The standard <Connector> thread pools, for whatever reason, will only create new threads... they won't take them out of service. An <Executor> can keep the thread pool lean and mean. > <Engine name="Catalina" defaultHost="***********"> > > <Realm className="org.apache.catalina.realm.UserDatabaseRealm" > resourceName="UserDatabase"/> Yikes! > <Host name="***********" appBase="gateway" > unpackWARs="true" autoDeploy="true" > xmlValidation="false" xmlNamespaceAware="false"> > > <Listener className = > "org.apache.jk.config.ApacheConfig" > workersConfig="conf/workers.properties" > mod_Jk="D:/Apache2.2/modules/mod_jk.so" jkLog="logs/mod_jk.log" > jkDebug="info" noRoot="false"/> > </Host> > > <Listener className = "org.apache.jk.config.ApacheConfig" > workersConfig="conf/workers.properties" > mod_Jk="D:/Apache2.2/modules/mod_jk.so" jkLog="logs/mod_jk.log" > jkDebug="info" noRoot="false"/> > </Engine> > </Service> > <Listener className = "org.apache.jk.config.ApacheConfig" > workersConfig="conf/workers.properties" > mod_Jk="D:/Apache2.2/modules/mod_jk.so" jkLog="logs/mod_jk.log" > jkDebug="info" noRoot="false"/> You probably don't want to use the ApacheConfig listener: just write your own mod_jk configuration files. You certainly don't need /three/ of them. > <Resource name="jdbc/vehrentDB" auth="Container" > type="javax.sql.DataSource" > maxActive="100" Only you can decide what settings are best for your webapp. Here are some things to think about: 1. You have 120 max threads, meaning a maximum of 120 simultaneous connections to handle. Your database connection pool is configured for 100 connections. What percentage of your requests do /not/ require database access? If the answer is lower than about 20%, then you probably want to make your maxThreads and maxActive closer to each other. Otherwise, request threads will block waiting for database connections. There are good reasons to limit your database connection pool size: if your database is not particularly high-performance, then you might want users to wait. It's just something to think about. > <Resource name="jdbc/empowerDB" auth="Container" > type="javax.sql.DataSource" > maxActive="100" If you have 2 databases, I might think about the ratio of connections used for each database: if the usage is roughly 50/50, maybe you want only 60 connections in each database connection pool. Reducing from 100 to 60 connections to your database might eliminate some overhead that's not needed. Then again, if your pool size is set that high and the ratio really is 50/50, then you'll end up with an effective pool size of 60 connections, anyway, since the pool won't create connections it doesn't need. You haven't said a word about your application, so it would be helpful to know what it's supposed to do, in general. You also haven't mentioned anything about current load versus ideal or target load. Nothing about memory requirements, numbers of concurrent sessions you'd like to support, or average sizes of sessions. If you provide some of that information, we may be able to give you further tips. Everything above is just kind of generic. In general, Tomcat is quite fast in it's default configuration. I would take a wild-ass guess that, for any non-trivial web application, Tomcat configuration can only account for somewhere around 10% of performance advantages... and that's mostly with the <Connector> configuration under heavy loads. It's most likely that, when there is a performance problem, that your web application is going to be the "problem". Good luck, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt2wF4ACgkQ9CaO5/Lv0PBcrACffFQQwcHtim/diSfALNcvUcQc ba8An23H17/eD00962524sjKcqdzJTw/ =emWJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
