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

[James MacLean]

Chris Stromsoe wrote:
> On Wed, 3 Jan 2007, Chuck Hagenbuch wrote:
>> Quoting Chris Stromsoe <cbs at cts.ucla.edu>:
>>
>>> I've traced the performance problem to the PHP database calls, so 
>>> it's probably not a datatree/shares problem.
>>>
>>> For the first call to exists(), calls to pg_fetch_row() return in 
>>> maybe 1/4 to 1/3 of a microsecond (measured using microtime() -- 2 
>>> to 3 calls return with the same time-stamp).
>>>
>>> For the second call to exists(), between 10 and 16 calls to 
>>> pg_fetch_row() return with the same timing characteristics as the 
>>> first call to exists(). All of the subsequent calls to 
>>> pg_fetch_row() take ~100ms to return.
>>
>> Still sounds like it could be a memory issue. Also, from the poster 
>> having trouble with Turba, there might be a general change in PHP 5.2 
>> that affects this. I'm using PHP 5.2, I know that you (Chris) are 
>> from earlier posts - do other people out there see a similar pattern?
>
> I just tested with 5.1.6 and the problem is not there.  It feels a 
> little slower than logging in with 5.2 + my work-around, but it's 
> still seconds to log in, rather than 10+ minutes.  Before reporting 
> this as a bug, can anybody else confirm that reverting to 5.1.6 fixes 
> the behavior?
>
>
Just wanted to chime in that this was what we also found here with MySQL 
as the backend. Key for us was that once the size of the return set got 
big enough, it appears that PHP would hang most times with PHP 5.2. 
Testing the same return set against PHP 5.1, it would return, just much 
to slow to be useful.

I tried to report it on feenet ##php, but they advised they did not help 
with third-party apps :(.

JES
-------------- next part --------------
A non-text attachment was scrubbed...
Name: macleajb.vcf
Type: text/x-vcard
Size: 208 bytes
Desc: not available
Url : http://lists.horde.org/archives/horde/attachments/20070104/b35242b7/macleajb.vcf