0

I've webapp on tomcat6 which is connecting to an M$ PlayReady DRM instance on IIS6.0 The performance is seen to be best when we bench mark (using ab) the DRM service with 25 concurrent connections, which gives about 250 requests per second, which is ace. higher concurrent connections results in TCP/IP timeouts and other lower level mess. But there is no way to control how the tomcat app connects to the service - it's not internally managing a pool of connections etc, they are all isolated http connections to the server. Ideally I'd like a situation where we can have 25 http 1.1 connections being kept alive permanently from tomcat and requesting the licenses through this static pool of connections, which I think would the best performance. But this is not in the code, so was looking for a way to possibly simulate this at the Linux level. I was possibly thinking that iptables connlimit might be able to gracefully handle these connections, but whilst it could limit, it'd probably still annoy the app. What about a proxy? nginx (or possibly squid) seems potentially appealing to run on the tomcat server and hit on localhost as we might want to add additional DRM servers to use under load balance anyway. Could this take 100 incoming connections from tomcat, accept them all and proxy over the the IIS server in a more respectful manner? Any other angles?

EDIT - looking over mod_proxy for apache, which we are already using for conventional use on an apache instance in front of this tomcat instance, might be ideal. I can set a max value on the proxy_pass to only allow 25 connections, and keep them alive permanently. Is that my answer?

Many thanks,

Chris

1 Answer 1

0

Read up on ProxyPass in mod_proxy documentation.

You are on the right way. See the parameters section for controlling the connection pool

Edit

According to doc:mod_proxy:

Apache will never create more than the Hard Maximum or max connections to the backend server.

Also it says:

In the Prefork MPM, this is always 1, while with the Worker MPM it is controlled by the ThreadsPerChild.

So as far as I understand, it should just be working you configured it. Since I see no reason why the max-parameter is getting ignored you might want to configure ttl and smax parameters so that excess-connections get closed after the ttl.

5
  • Initially I was hesitant to consider just sticking in an Apache instance on a whim, but the more I think about it, the better and more suitable an idea it seems to be. Nov 6, 2010 at 17:49
  • Well I'm seeing no pooling happening at all. Running work MPM with the following: StartServers 1 MaxClients 960 MinSpareThreads 4 MaxSpareThreads 16 ThreadsPerChild 64 MaxRequestsPerChild 0 ProxyPass /Drm/ 192.168.102.31:50000/DrmSoap max=10 min=5 ProxyPassReverse /DrmSoap/ 192.168.102.31:50000/DrmSoap I still see hundreds of backend connections, despite this appearing to only permit 10 connections per process, and so only 10 connections in total, it does not enforce this in any way i can see. Nov 8, 2010 at 13:21
  • You should enable disableReuse (see mod_proxy doc). Also the maximum number of open connections is determined by ThreadsPerChild (64) * MinSpareThreads (4) = 256 so you might want to lower these values.
    – pacey
    Nov 8, 2010 at 13:41
  • well these numbers all appear to have large impacts on the client side too, reducing the threads per child causes the MaxClients to be automatically reduced to numbers which wholly defeat the point of the exercise, e.g. 64. A thread is surely required for a client connection to be accepted, and by reducing that, i'm crippling my self before I even start..? I want to push 500 concurrent client requests per second over 25 tcp connections. This doesn't seem to have the suitable disconnect between each side to allow this to happen. Nov 8, 2010 at 15:40
  • Oh, and disableReuse is already off by default, I turned it "On" i.e. "Off"... and i did get a LOT more connections for sure. Nov 8, 2010 at 15:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .