Re: [phpOpenTracker-general] SOLVED :very slow response for 1st hit when using phpopentracker

Well a long way around to a 'doh!' answer for this one... turned out to be the 
speed of the reverse lookup done on the IP address, so the greater the 
latency between the web server and the client PC's network's DNS lookup 
result, the longer the page or web bug will take to load.

Not that the actual lookup takes anything like the abount of time of the 
resulting delay... didn't bother to investigate that further, since stopping 
the lookup fixed the issue.

Does anyone really leave this switched on?

phpOpenTracker/conf/phpOpenTracker.php:

// Resolving of the hostname can be turned off.
$PHPOPENTRACKER_CONFIGURATION['resolve_hostname'] = false;

Well along the way I learned about using gdb to debug php programs, which is 
cool :) http://dd.cron.ru/dbg/

Cheers
Richard

On Fri, 17 Mar 2006 11:47 am, you wrote:
> Hi John
>
> Thanks for your response, this is turning out to be a bit weirder that I
> initially thought.
>
> Logging shows there are no directly related slow queries, so I switched
> from a sockets connection to an tcp connection between phpOpentTracker
> client and server to make it easier for me to see where the delay actually
> happens (the problem exists on both tcp and sockets connections between
> client and server). I'm from a networking background so looking at packets
> is my usual analysis method where possible...
>
> The phpOpenTracker [client] authenticates sucessfully (and the client
> acknowleges this with and ACK), then there is a delay of up to several
> seconds before the client starts to send queries to the postgres server.
> The time to for the server to respond to the queries is meets expecations.
>
> Looks like phpOpenTracker uses PHP's postgres functions directly, which I
> do without issues in other scripts, so it really does look like this
> relates somehow to the processing around the session.
>
> I did some simple isolated session handling tests - all seems normal there.
>
> More updates later if I find out anything else....
>
> Regards
> Richard G
>
> On Wed, 15 Mar 2006 11:33 am, John Pye wrote:
> > Hi Richard,
> >
> > Not sure about Postgresql but, as I recall, in Mysql there is some
> > effort made to defer the SQL 'INSERT' so that PHP doesn't have to sit
> > around waiting for it to complete. Perhaps you need to also check your
> > database tables are correctly indexed?
> >
> > Maybe it would be interesting to experiment with switching over to the
> > 'web bug' style of reporting. This would help you to isolate where the
> > delay is coming from, since in that case the page should load really
> > quickly but the 1-pixel GIF would take a bit longer.
> >
> > It does sound as though a new session is triggering the delay; you'll
> > need to track down where it's coming from in more detail. Perhaps add
> > some logging of the time spent on database queries?
> >
> > Cheers
> > JP
> >
> > Richard Green wrote:
> > >Hi
> > >
> > >Using postgresql 8.1 for my database back end (optimized by increasing
> > > buffer storage to 128MBytes). Hardware is good - SCSI drive, lots of
> > > RAM, no swapping.
> > >
> > >My site takes several seconds (16s for php to genereate the HTML for a
> > > page) to respond to the first hit to my site (similar for both directly
> > > call to logging function and when using web bug).
> > >
> > >For subsequent hits to the site, the overhead is minimal (e.g. 0.054s
> > > for php to generate html for a page).
> > >
> > >I think this relates to sessions, or the SQL query that takes place when
> > > there is a new session. Restarting my browser (thus session cookie is
> > > removed) causes the problem to repeat.
> > >
> > >- Has anyone seen a similar problem?
> > >- Does anyone have any further optimization ideas?
> > >
> > >Thanks and regards
> > >Richard Green