> I suppose your test program connects, and loops the same query multiple > times in the same session? (Just to rule out connect/disconnect > overhead)
Of course. I also run the same query multiple times, to eliminate caching issues. Performance on successive iterations is the same as on the first. It is bizarre how the query that asks for 33 rows on an indexed field works fine, yet the query that asks for 1 row on the primary key performs so badly. > What are your timings if you run your client on the SCO box? mysql simply reports a query time of 10ms or less (0.01s). Of course, this doesn't have any network overhead. > If all your queries are instantaneous They're not - one Windows box (the 98SE one) reports a query time of 180ms and a data fetch time of 10ms, while the Win2000 box reports the opposite (query 10ms, fetch 180ms) > I'd say start dumping packets on the network. I'd agree, but I'm confused as to why a different query (that requests more data; 33 rows vs 1) can reliably execute and fetch in 10ms on all machines? The behaviour is completely reproducible: SELECT (1 record) ON PRIMARY KEY = slow (200ms), SELECT (lots of records on indexed field) = fast (10ms) > 200ms sounds a lot like Nagle's Algorithm kicking in (which > shouldn't happen assuming the mysql libs are written right). Indeed, I wouldn't have thought they'd have included that! Isn't Nagle restricted to telnet? But anyway, not all queries perform equally badly. --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php