On the issue of tcp connection (client <-->apache) on CLOSE_WAIT for a long time: unfortunately, I don't know how to tune it on Linux. But I tune this down to 10 seconds on Solaris (tcp_time_wait). This was recommended when I was on BEA land, for high traffic web site, with a lot of people come and go. That would reduce the number of lingering (CLOSE_WAIT) connections. Assuming you are not using keep alive.
If you haven't changed TCP buffer size, then, you should. That will get your 5M data from resin to apache quicker. Default buffer sizes are too small for 'real' application. Update /etc/sysctl.conf with sample values (adjust them accordingly) and then do "sysctl -p" (http://dsd.lbl.gov/TCP-tuning/linux.html) # increase TCP max buffer size net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 # increase Linux autotuning TCP buffer limits # min, default, and max number of bytes to use net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 You can find your current settings by "sysctl -a" ________________________________________ From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of okrische [EMAIL PROTECTED] Sent: Friday, May 25, 2007 7:57 AM To: [email protected] Subject: [Resin-interest] mod_caucho and resin 2.1.17 and sockets Hello everyone, i face a problem with - apache-2.0.59-prefork as httpd, - mod_caucho from resin 2.1.17 and - Linux Debian Etch (2.6.18-4-amd64) The httpd uses the mod_deflate module to compress the output. It delivers the output in chunks to the client, as far as i can see. This is the scenario: Resin passes the output for a huge page (e.g. 5MB) back to mod_caucho. mod_caucho passes it to the httpd. The httpd delivers the compressed chunks to the client. So far so good. But now the client decides "i have got everything i need", and "pushes the stop button". So not everything from those 5MB have been received by the client. a) the socket "client <-> httpd" on httpd server goes into 'CLOSE_WAIT' ("The remote end has shut down, waiting for the httpd socket to close") b) the socket "mod_caucho" <-> "resin" on httpd server is 'ESTABLISHED' and has data in its tcp input queue (can not pass the content to httpd anymore?) c) the socket "resin <-> mod_caucho" on resins server is 'ESTABLISHED' and has data in its tcp output queue (can not pass the content to mod_caucho on httpd server) But for any reason, as long as the socket from a) stays in CLOSE_WAIT, the connection from b) can not be re-used for new requests. It just hangs. So, if more clients do the same as above, earlier or later all connections to the Resin are busy. Does someone know this kind of problem and has some ideas to share? Why the httpd could stay so long in CLOSE_WAIT? Why it could not shut down and send his FIN? Can the mod_caucho recognize, that the socket from its httpd process has been closed by the remote client and could release all ressources? So mod_caucho can go on with the next request from another httpd process? Or is mod_caucho bound to one httpd process as long this httpd process "lives" ? Thanks for some ideas or tips or hints. Olaf Krische -- View this message in context: http://www.nabble.com/mod_caucho-and-resin-2.1.17-and-sockets-tf3816644.html#a10804724 Sent from the Resin mailing list archive at Nabble.com. _______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest _______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
