I removed the disablereuse setting, and still see the same issue. My
original email showed that we set to the -s option of pkg.depotd to 50
threads. I don't know enough about apache to answer your prefork vs.
worker setup.
-- Alan
johan...@sun.com wrote:
On Wed, Jul 08, 2009 at 02:33:23PM -0700, Alan Steinberg wrote:
johan...@sun.com 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
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
