Re: [Sqlrelay-discussion] sqlrelay TTL issue
Brought to you by:
mused
Menu
▾
▴
Re: [Sqlrelay-discussion] sqlrelay TTL issue
|
From: David M. <dav...@fi...> - 2006-01-07 05:27:53
|
Jose, I did some testing with the current version and I can't reproduce the problem with the 60 second ttl. It's possible that there's a bug in 0.36.2 but the code is pretty similar, so if there's a bug, it's a subtle one. If using a ttl of something other than 60 works for you, then I'd recommend doing that. If you need to use a ttl of 60, then you'll probably have to upgrade to the current version. Dave dav...@fi... On Tue, 2005-12-13 at 11:13 -0800, Jose Selva wrote: > Hi, > > My name is Jose and I'm having a problem with sqlrelay 0.36.2. I'm using Debian linux stable, PHP 4.3, and ORACLE 9.2. > > The current sqlrelay configuration is: > > <instance id="test-con" port="9090" socket="/tmp/test-con.socket" dbase="oracle8" connections="0" maxconnections="25" maxqueuelength="0" growby="3" ttl="60" endofsession="commit" sessiontimeout="600" runasuser="oracle" runasgroup="oracle" cursors="10" authtier="listener" handoff="pass"> > <users> > <user user="test" password="test"/> > </users> > <connections> > <connection connectionid="test" string="user=test;password=test;oracle_sid=JOSE.WORLD" metric="1"/> > </connections> > </instance> > > As you can see, we have a ttl of 60. Here is the problem I'm currently having: > > The benchmark environment is set up so the site gets 3 requests every 5-10 seconds, which needs between 1 and 3 connections active. (Note that we have an average of 25 queries per PHP page) > > If I run apache benchmark requesting 500 pages with a level of concurrency of 5, the number of connections in the pool increases to reach 12-15. > > The problem comes after the apache benchmark is done. Since the volume of requests goes down again, I was expecting to see the number of connections in the pool going down after 60 seconds of inactivity, but this does not happen. > > If I run the apache benchmark again (500 pages and 5 concurrency) the number of connections would go up again to reach 21-24. After the requests are handled, the number of connections would not decrease. > > This is a problem because it seems that those connections used during high volumes of requests are not available anymore once they have been inactive more than 60 seconds, and instead of being released, they stay in the pool and not available for more upcoming requests. > > If I run the same experiment described above with a 15 TTL this problem does not happen. The number of connections goes down right after the connections have been inactive more than that TTL. > > Here is an excerpt of the debug statements found in the connections that have this problem (60 TTL): > > 12/09/2005 00:36:10 GMT connection [18919] : done initializing session... > > 12/09/2005 00:36:10 GMT connection [18919] : announcing availability... > > 12/09/2005 00:36:10 GMT connection [18919] : acquiring announce mutex > > ---- Stuck here --- > > > And this is what I got when using 15 TTL: > > 12/08/2005 14:28:34 PST connection [31305] : initializing session... > > 12/08/2005 14:28:34 PST connection [31305] : done initializing session... > > 12/08/2005 14:28:34 PST connection [31305] : announcing availability... > > 12/08/2005 14:28:34 PST connection [31305] : acquiring announce mutex > > 12/08/2005 14:29:34 PST connection [31305] : decrementing connection count... > > ---- Releases resources just fine ---- > > > Do you have any ideas on why the 60 TTL is causing this problem?. > > Also, if I go ahead with the 15 TTL, what would be the performance impact in my application? > > Any ideas/help would be much appreciated > > Thanks in advance. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > |
