Re: mod_jk performance optimization
Thanx for your reply, for it really helped. I used jk from 3.3 and the previous error which appeard at mod_jk.log is gone. :-) But...(there's always a but) another error appears when I request several servlet tasks simultaneously. In mod_jk.log: [jk_ajp13_worker.c (381)]: Error ajp13_process_callback - write failed I've also checked tomcat.log and the following error appears: Ctx( /WebApplication ): Exception in: R( /WebApplication + /servlet/ServletObj + null) - java.lang.OutOfMemoryError no stack trace available After this the system is slower than ever. I tried to restart Tomcat but the system continues to be very...very slow. I'd appreciate if some clues about this problem could be thrown at me :-) Thanx. Serrano. From: [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: mod_jk performance optimization Date: Thu, 2 May 2002 10:04:13 -0700 (PDT) On Thu, 2 May 2002, M. Serrano wrote: Hi. I've got installed in my box Linux, Apache 1.3.19, JDK 1.3.1 and TC 3.3.1 working with ajp13. The following error appeard in my mod_jk.log after a bit of continuous utilisation: [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [jk_ajp13_worker.c (621)]: Error reading request From the line numbers, you may use an older version of jk, try updating from CVS head first ( the bug may be already fixed ) ( you can use either the 'frozen' jk from 3.3 or j-t-c ). The error message means from some reasons tomcat didn't sent back any content - so you may need to look in tomcat's lots as well. ( the 'reading request' means the request from tomcat to jk to send a chunk of data ) Costin After analysing the server's config files and reading some threads, I concluded that the problem might be resolved through a bit of extra re-configuration. Although the problem appearence was delayed, it still existed. I wonder if anyone out there could help me with this subject. I'm sending in attach some lines of httpd.conf, server.xml and mod_jk.conf Thanx a lot for your time. Serrano. ## ## httpd.conf -- Apache HTTP server configuration file ## # # Timeout: The number of seconds before receives and sends time out. # Timeout 300 # # KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to Off to deactivate. # KeepAlive On # # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow an unlimited amount. # We recommend you leave this number high, for maximum performance. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Number of seconds to wait for the next request from the # same client on the same connection. # KeepAliveTimeout 15 # # Server-pool size regulation. Rather than making you guess how many # server processes you need, Apache dynamically adapts to the load it # sees --- that is, it tries to maintain enough server processes to # handle the current load, plus a few spare servers to handle transient # load spikes (e.g., multiple simultaneous requests from a single # Netscape browser). # # It does this by periodically checking how many servers are waiting # for a request. If there are fewer than MinSpareServers, it creates # a new spare. If there are more than MaxSpareServers, some of the # spares die off. The default values are probably OK for most sites. # MinSpareServers 5 MaxSpareServers 10 # # Number of servers to start initially --- should be a reasonable ballpark # figure. # StartServers 8 # # Limit on total number of servers running, i.e., limit on the number # of clients who can simultaneously connect --- if this limit is ever # reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW. # It is intended mainly as a brake to keep a runaway server from taking # the system with it as it spirals down... # MaxClients 150 # # MaxRequestsPerChild: the number of requests each child process is # allowed to process before the child dies. The child will exit so # as to avoid problems after prolonged use when Apache (and maybe the # libraries it uses) leak memory or other resources. On most systems, this # isn't really needed, but a few (such as Solaris) do have notable leaks # in the libraries. For these platforms, set to something like 1 # or so; a setting of 0 means unlimited. # # NOTE: This value does not include keepalive requests after the initial # request per connection. For example, if a child process handles # an initial request and 10 subsequent keptalive requests, it # would only count as 1 request towards this limit. # MaxRequestsPerChild 200 # # DocumentRoot: The directory out of which you will serve your # documents. By default, all requests are taken from
RE: mod_jk performance optimization
If error handling, or something else, get into a recursive loop, it can eat up all available memory and result in symptoms like this. Cheers, Larry -Original Message- From: M. Serrano [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 1:18 PM To: [EMAIL PROTECTED] Subject: Re: mod_jk performance optimization Thanx for your reply, for it really helped. I used jk from 3.3 and the previous error which appeard at mod_jk.log is gone. :-) But...(there's always a but) another error appears when I request several servlet tasks simultaneously. In mod_jk.log: [jk_ajp13_worker.c (381)]: Error ajp13_process_callback - write failed I've also checked tomcat.log and the following error appears: Ctx( /WebApplication ): Exception in: R( /WebApplication + /servlet/ServletObj + null) - java.lang.OutOfMemoryError no stack trace available After this the system is slower than ever. I tried to restart Tomcat but the system continues to be very...very slow. I'd appreciate if some clues about this problem could be thrown at me :-) Thanx. Serrano. From: [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: mod_jk performance optimization Date: Thu, 2 May 2002 10:04:13 -0700 (PDT) On Thu, 2 May 2002, M. Serrano wrote: Hi. I've got installed in my box Linux, Apache 1.3.19, JDK 1.3.1 and TC 3.3.1 working with ajp13. The following error appeard in my mod_jk.log after a bit of continuous utilisation: [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [jk_ajp13_worker.c (621)]: Error reading request From the line numbers, you may use an older version of jk, try updating from CVS head first ( the bug may be already fixed ) ( you can use either the 'frozen' jk from 3.3 or j-t-c ). The error message means from some reasons tomcat didn't sent back any content - so you may need to look in tomcat's lots as well. ( the 'reading request' means the request from tomcat to jk to send a chunk of data ) Costin After analysing the server's config files and reading some threads, I concluded that the problem might be resolved through a bit of extra re-configuration. Although the problem appearence was delayed, it still existed. I wonder if anyone out there could help me with this subject. I'm sending in attach some lines of httpd.conf, server.xml and mod_jk.conf Thanx a lot for your time. Serrano. ## ## httpd.conf -- Apache HTTP server configuration file ## # # Timeout: The number of seconds before receives and sends time out. # Timeout 300 # # KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to Off to deactivate. # KeepAlive On # # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow an unlimited amount. # We recommend you leave this number high, for maximum performance. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Number of seconds to wait for the next request from the # same client on the same connection. # KeepAliveTimeout 15 # # Server-pool size regulation. Rather than making you guess how many # server processes you need, Apache dynamically adapts to the load it # sees --- that is, it tries to maintain enough server processes to # handle the current load, plus a few spare servers to handle transient # load spikes (e.g., multiple simultaneous requests from a single # Netscape browser). # # It does this by periodically checking how many servers are waiting # for a request. If there are fewer than MinSpareServers, it creates # a new spare. If there are more than MaxSpareServers, some of the # spares die off. The default values are probably OK for most sites. # MinSpareServers 5 MaxSpareServers 10 # # Number of servers to start initially --- should be a reasonable ballpark # figure. # StartServers 8 # # Limit on total number of servers running, i.e., limit on the number # of clients who can simultaneously connect --- if this limit is ever # reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW. # It is intended mainly as a brake to keep a runaway server from taking # the system with it as it spirals down... # MaxClients 150 # # MaxRequestsPerChild: the number of requests each child process is # allowed to process before the child dies. The child will exit so # as to avoid problems after prolonged use when Apache (and maybe the # libraries it uses) leak memory or other resources. On most systems, this # isn't really needed, but a few (such as Solaris) do have notable leaks # in the libraries
Re: mod_jk performance optimization
On Thu, 2 May 2002, M. Serrano wrote: Hi. I've got installed in my box Linux, Apache 1.3.19, JDK 1.3.1 and TC 3.3.1 working with ajp13. The following error appeard in my mod_jk.log after a bit of continuous utilisation: [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [jk_ajp13_worker.c (621)]: Error reading request From the line numbers, you may use an older version of jk, try updating from CVS head first ( the bug may be already fixed ) ( you can use either the 'frozen' jk from 3.3 or j-t-c ). The error message means from some reasons tomcat didn't sent back any content - so you may need to look in tomcat's lots as well. ( the 'reading request' means the request from tomcat to jk to send a chunk of data ) Costin After analysing the server's config files and reading some threads, I concluded that the problem might be resolved through a bit of extra re-configuration. Although the problem appearence was delayed, it still existed. I wonder if anyone out there could help me with this subject. I'm sending in attach some lines of httpd.conf, server.xml and mod_jk.conf Thanx a lot for your time. Serrano. ## ## httpd.conf -- Apache HTTP server configuration file ## # # Timeout: The number of seconds before receives and sends time out. # Timeout 300 # # KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to Off to deactivate. # KeepAlive On # # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow an unlimited amount. # We recommend you leave this number high, for maximum performance. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Number of seconds to wait for the next request from the # same client on the same connection. # KeepAliveTimeout 15 # # Server-pool size regulation. Rather than making you guess how many # server processes you need, Apache dynamically adapts to the load it # sees --- that is, it tries to maintain enough server processes to # handle the current load, plus a few spare servers to handle transient # load spikes (e.g., multiple simultaneous requests from a single # Netscape browser). # # It does this by periodically checking how many servers are waiting # for a request. If there are fewer than MinSpareServers, it creates # a new spare. If there are more than MaxSpareServers, some of the # spares die off. The default values are probably OK for most sites. # MinSpareServers 5 MaxSpareServers 10 # # Number of servers to start initially --- should be a reasonable ballpark # figure. # StartServers 8 # # Limit on total number of servers running, i.e., limit on the number # of clients who can simultaneously connect --- if this limit is ever # reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW. # It is intended mainly as a brake to keep a runaway server from taking # the system with it as it spirals down... # MaxClients 150 # # MaxRequestsPerChild: the number of requests each child process is # allowed to process before the child dies. The child will exit so # as to avoid problems after prolonged use when Apache (and maybe the # libraries it uses) leak memory or other resources. On most systems, this # isn't really needed, but a few (such as Solaris) do have notable leaks # in the libraries. For these platforms, set to something like 1 # or so; a setting of 0 means unlimited. # # NOTE: This value does not include keepalive requests after the initial # request per connection. For example, if a child process handles # an initial request and 10 subsequent keptalive requests, it # would only count as 1 request towards this limit. # MaxRequestsPerChild 200 # # DocumentRoot: The directory out of which you will serve your # documents. By default, all requests are taken from this directory, but # symbolic links and aliases may be used to point to other locations. # DocumentRoot /usr/local/jakarta-tomcat-3.3.1/webapps/ROOT # This should be changed to whatever you set DocumentRoot to. # Directory /usr/local/jakarta-tomcat-3.3.1/webapps/ROOT # # This may also be None, All, or any combination of Indexes, # Includes, FollowSymLinks, ExecCGI, or MultiViews. # # Note that MultiViews must be named *explicitly* --- Options All # doesn't give it to you. # Options indexes includes followSymLinks # # This controls which options the .htaccess files in directories can # override. Can also be All, or any combination of Options, FileInfo, # AuthConfig, and Limit # AllowOverride None # # Controls who can get stuff from this server. # Order allow,deny Allow from all /Directory # Include TOMCAT Include /usr/local/jakarta-tomcat-3.3.1/conf/auto/mod_jk.conf-local - mod_jk.conf-local - ## Auto generated on
