(转)tomcat优化及常见错误解决

苏童

How to optimize tomcat performance in production

 

Contents  [hide] 1 Tomcat maxThreads configuration 2 How the process works: 3 Guidelines for maxThreads: 4 Solving multipart/form-data Read timed out issue 5 Logging settings in Production 6 Access logging settings similar to httpd 7 Sharing Global Connection Pool 8 Templating Server.xml 9 Virtual hosting Host definition 10 Choosing right connectors for production 11 Undocumented options ExtendedAccessLogValve 12 Undocumented options Caching

Tomcat maxThreads configuration

Tomcat maxThreads represents the maximum number of request processing threads to be created by the HTTPConnector.

<Connector port="8080" address="localhost"     
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />

This determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to the default value of 200.

How the process works:

   * At server startup, the HTTP Connector will create a number of processing threads based on the value configured for the minSpareThreads attribute.
* Each incoming request requires a thread for the duration of that request.
* If the number of simultaneous requests cannot be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the maxThreads attribute).
* If still more simultaneous requests are received, they are stacked up up to the configured maximum (the value of the acceptCount attribute).
* Any further simultaneous requests will receive "connection refused" errors, until resources are available to process them.

Guidelines for maxThreads:

maxThreads is an important tuning parameter, however if you are reaching an error like:

   org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (150) are
currently busy, waiting. Increase maxThreads (150) or check the servlet status

you should at first investigate if it's rather a problem of individual requests taking too long: are your threads returning to the pool? if, for example, database connections are not released, threads pile up waiting to obtain a database connection thereby making it impossible to process additional requests. This is a problem in your webapp.
Take a thread dump to find out where they're stuck. Increasing too much maxThreads will lead to :

   * Consume a good chunk of memory.
* Your system will spend too much time context switching

So once you have already optimized your application try raising you maxThread attribute up to 500-750. I wouldn't advice to create larger Connectors, rather if 750 Connections are not enough create a Cluster configuration with several Tomcat instances. For example 2 instances of tomcat each one with maxThreads=500 instead of a single Tomcat with maxThreads=1000

Solving multipart/form-data Read timed out issue

If you are facing issues like this org.springframework.web.multipart.MultipartException: Could not parse multipart servlet request; nested exception is org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Read timed out

then set disableUploadTimeout to false and increase connectionUploadTimeout value. This value is specified in milli-seconds

connectionUploadTimeout	Specifies the timeout, in milliseconds, to use while a data upload is in progress. This only takes effect if disableUploadTimeout is set to false.
disableUploadTimeout	This flag allows the servlet container to use a different, usually longer connection timeout during data upload. If not specified, this attribute is set to true which disables this longer timeout.

<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" connectionUploadTimeout="300000" disableUploadTimeout="false"/>

Logging settings in Production

· conf/logging.properties

.handlers = \
1catalina.org.apache.juli.FileHandler, \
java.util.logging.ConsoleHandler

· Causes duplicate logging 
· May fill up catalina.out (no rotation)
Change to
· conf/logging.properties

.handlers = \
1catalina.org.apache.juli.FileHandler

· Only log to file 
· For development, logging to stdout/stderr is sometimes easier to work with
· http://www.cronolog.org - example tool

>> "$CATALINA_BASE"/logs/catalina.out 2>&1 &
· Rotate on a daily basis

2>&1 | /bin/cronolog %Y-%m-%d.catalina.out
· Changes made in catalina.sh

Access logging settings similar to httpd

· Access Logging can be done using a valve 
– Valve logs as soon as the request is done 
– Introspects request and response to generate output

<Valve className="org.apache.catalina.valves.AccessLogValve"
pattern="%h %l %u %t %r %s %b %S %D"
directory="${catalina.base}/logs"
prefix="tomcat_access_"
suffix=".log" />
The %D pattern gives the duration of the URL in miliis

· Pattern similar to that of httpd [1]

Sharing Global Connection Pool

· Sharing a connection pool

<GlobalNamingResources>
<Resource type="javax.sql.DataSource"
name="sharedpool"/>
</GlobalNamingResources>

· conf/context.xml

<Context>
<ResourceLink global="sharedpool"
name="jdbc/DS"/>
</Context>

· All global defaults can be configured in 
– conf/context.xml 
· Can be overridden by application 
– conf/web.xml 
· Can be overridden by application

Templating Server.xml

· Use catalina.properties for server.xml substitution variables

#server shutdown port in catalina.properties
shutdown.port=-1
<Server port="${shutdown.port}">
…
</Server>

Virtual hosting Host definition

· Each host requires an entry in server.xml 
· Each host requires their own appBase 
· Default host still required

<Engine name="Catalina" defaultHost="bart.foo.com">
<Host name="bart.foo.com" appBase="webapps-bart"/>
<Host name="homer.foo.com" appBase="webapps-homer"/>
</Engine>

· Standard rules apply 
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html 
· http://bart.foo.com/ is served by the root context for the host bart.foo.com 
· ROOT.xml, ROOT.war, ROOT
 

Choosing right connectors for production

Requirement Connectors in preference order

Stability          BIO        NIO/APR
SSL                APR     NIO        BIO
Low concurrency    BIO     APR        NIO
High concurrency
No Keep-Alive      BIO     APR        NIO
High concurrency
Keep-Alive         APR     NIO        BIO

If you send a request to tomcat then with all of the connectors you will use tomcat thread to process that request
BIO is Blocking IO Connectors and NIO and APR are Non-Blocking IO Connectors. 
BIO means if you use http with keep-alive parameter then you will continue to use that thread in order to maintain keep-alive connection while with Non-Blocking IO Connectors you don't need to use thread to maintain keep-alive requests, so you can make efficient use of threads here 

Undocumented options ExtendedAccessLogValve

· W3C Extended Log File Format 
http://www.w3.org/TR/WD-logfile.html 
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/ExtendedAccessLogValve.html
· Enhancements include logging of: 
– Request parameters (helpful for POST) 
– ServletContext attributes 
– HttpServletRequest methods 
 

Undocumented options Caching

· Content requiring authentication should not be cached 
· Tomcat sets caching headers to enforce this 
· IE uses a local cache to download files 
· IE downloads the file and then obeys the headers and deletes it from the cache before you have a chance to open it 
· Tomcat can be configured to 
– allow private caching – recommended 
– allow public caching – not recommended 

<Context ... >
<Valve className="...Authenticator"
securePagesWithPragma="false"
</Context>
<Context ... >
<Valve className="...Authenticator"
disableProxyCaching="false"
</Context>

· className depends on the authentication type configured 
· All in package 
org.apache.catalina.authenticator 
· BasicAuthenticator 
· FormAuthenticator 
· DigestAuthenticator 
· SSLAuthenticator