[horde] php and postgres, Re: Horde 3.1, memcache sessionhandler, sidebar, and flock()

[Michael M Slusarz]

Quoting Chris Stromsoe <cbs at cts.ucla.edu>:

> On Tue, 2 Jan 2007, Chuck Hagenbuch wrote:
>> Quoting Chris Stromsoe <cbs at cts.ucla.edu>:
>>
>>> The more I look at this, the more it looks like here is either In
>>> any event, I'm stumped about where to look.  Is anybody else using
>>> postgres and shares/datatree seeing the same issues (extremely long
>>> lag times to create the first instance of a share) ?
>>
>> I haven't seen this specific issue, but I do have speed issues in
>> Ansel listing photo galleries (mysql this time, so I don't think
>> this is pgsql specific). I'm looking at various remedies;
>> unfortunately for me removing about 1,000 rows from horde_datatree
>> (10,000 from horde_d_a) by getting bookmarks into their own table
>> didn't do a think for gallery listing speed.
>>
>> I'm planning on doing more, looking into this + shares in plain SQL
>> + your data, but in the mean time, do you still see this as related
>> to the memcache session handler?
>
> The memcache session handler was my first guess, mostly because of
> the flock() serialization changes.  I think that I can completely
> rule session handling out as the source of the problem.
>
> I added calls to microtime() in the various DataTree routines and the
> PEAR DB routines, and traced the slowness I'm seeing down to
> DB/pgsql.php fetchInto(), specifically the pg_fetch_row() call.
>
>
> I wrote some php code to simulate the same set of DB calls outside of
> Horde, but was not able to duplicate the problem independantly, so it
> looks like it isn't anything specific to the DB calls themselves, but
> probably to how memory allocation and garbage collection in PHP works.
>
> I haven't had time to start digging into the PHP source to try to
> figure out where the slowness is coming from.  Since I only see it on
> additional calls to ->exists(), I added code to the postauthenticate
> hook to create the nag, kronolith, and mnemo shares if they don't
> exist, so that the first ->exists() will always be true.

In DataTree/sql.php, can you try changing both DB::connect calls (i.e.:
DB::connect($this->_params,
             array('persistent' => !empty($this->_params['persistent'])));

to the following:

DB::connect($this->_params,
             array('persistent' => !empty($this->_params['persistent']),
                   'autofree' => true));

and see if that helps at all?

michael

___________________________________
Michael Slusarz [slusarz at horde.org]