On Wed, Jul 08, 2009 at 02:33:23PM -0700, Alan Steinberg wrote: > [email protected] wrote: >> On Wed, Jul 08, 2009 at 02:10:31PM -0700, Alan Steinberg wrote: >> >>> Our pkg.depotd is running with 50 threads and a 60-second timeout. >>> >>> Our apache2 httpd.conf file contains: >>> ProxyTimeout 30 >>> ProxyRequests Off >>> AllowEncodedSlashes On >>> ProxyPass /dev-private http://oursystem.domain:10800 nocanon disablereuse=On >>> >>> Do we have a bad setup somewhere, or is there a bug in the new >>> transport code? >>> >> >> There are likely problems in your setup. Setting disablereuse=on will >> cause performance issues with the new transport. It performs better >> when it's able to take advantage of connection re-use. I'm not an >> Apache expert, but perhaps someone else can offer more guidance about >> your other choices. >> >> -j >> > Hmmm. We just turned that on after having timeout issues a couple of > builds ago, and it is in the sample conf file inside the > src/util/apache2 directory. Since both errors I reported occured even > when going directly to the port number, would that eliminate any issues > with the apache2 conf file, could it still be related?
I'm not sure I understand your response. The new transport takes advantage of HTTP/1.1 pipelining in order to improve the performance of GET requests. If you set disablereuse=On, you're defeating this performance enhancement since every request made to Apache will result in a new connection to CherryPy, defeating the connection pooling that Apache performs and slowing down the incoming pipelined requests. Also notice that our example configuration calls out that disablereuse exists to work around bug 8903. That's been fixed in CherryPy, which ought to make it uncessary to use this feature. Dan told me that he was going to update the apache configuration with suggested values for the new transport, but I guess he hasn't done that yet. Apache's connection pooling may still be exacerbating the problem you're seeing with CherryPy. The CherryPy (depot) runs with a fixed number of threads. If Apache has more connections open than the depot has threads available, it doesn't matter where you connect, you'll get timeouts. I'd be interested to see the configuration values for the depot (the number of threads it's running), as well as the paramaters that you've set for Apache to use when handling this traffic. Is your Apache configured to use prefork or worker? If it's using the threaded worker process approach, the default configuration can generate up to 400 concurrent client connections. Assume that each worker will connect to each member of the load balanced pool at least once. If you don't have enough depot threads to handle this setup, this may be why you're seeing timeouts. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
