In preparing to give more info, as requested by Sebastian, I have discovered that:
You are right, but not exactly for the reasons you describe.
The problem is the fact that I was interleaving the mysql_fetch with echo. However, I do not believe it is simply an 'adding the latency'. The two reasons this is probably not the case are because 1) the timing measures I made where from within the code, not by "watching the browser", so I knew exactly the time it was taking. Secondly, the mysql server and the web client are co-located (i.e. in my house) and the latency between web server + mysql server would be the same as between web server + web browser, of which I know with high confidence is never as long as the timings would indicate.
And actually a third reason for knowing it isn't simply latency is because, when I did perform all the data fetching before doing any output, the times decreased by a factor of 1000: from on order 1 to 6 seconds per fetch down to around .0001 second per fetch. This order of magnitude of difference is too much for simply latency.
Nevertheless, clearly the mixing of I/O between the mysql connection and the web client creates a HUGH impact on the php efficiency.
Thanks for the discussion!!! This got the job done!!!
Question is now: is this a mysql library issue or a php/mysql interaction issue...will make sure the php and mysql folks know this (which they may already know about, I just didn't).
Thank you Thank you! jde
Brent Baisley wrote:
You're also writing out to "screen" as you get the data, so you may be adding the latency from the web server to the client on top of your data fetching. You can probably get a boost by getting all the data into PHP first and then formatting and sending it to the client. At a minimum you should be able to determine if the client is the big slow down.
-- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
