Tommy Pham wrote: > As some of you mention that implementing threads will make the DB work > harder than the standard serial operations queries, let me ask you > these then: > > * How often does your DB server(s)/cluster utilizes 100% CPU (SMP/MC), > memory, and disk IO? Assuming we're talking under heavy load - my database server is an old(ish) HP Proliant ML570 - 4 x 3GHz Xeons with HT, dual U320 SCSI busses, 48GB RAM : CPU 100% - rarely, but it happens. Memory 100% - all the time. Disk IO 100% - less than all the time, but it's very busy. > * If you could implement threads and run those same queries in 2+ > threads, the total time saved from queries execution is 1/2 sec or > more, which is pass along as the total response time reduced. Is it > worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. > (I remember a list member, not mentioning his name, does optimization > of PHP coding for just microseconds. Do you think how much more he'd > benefit from this?) Anyone who optimizes PHP for microseconds has lost touch with reality - or at least forgotten that he or she is using an interpreted language. > * If the requests are executed in parallel, the sooner the request > fulfillment completes, the faster it is to move to the next request > and complete it right? Correct. -- Per Jessen, Zürich (12.7°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
