Will PHP ever "grow up" and have threading?
in [General]
|
From: Per Jessen on 25 Mar 2010 04:35 Tommy Pham wrote: > I don't > use Linux nor an expert in it but implementing custom thread solution= > like that means understanding about SELinux vs AppArmor vs Grsecurity= > or am I wrong?=20 Yes, you are wrong. The Posix thread model implemented in the pthread library in Linux is easy to pick up for anyone who has studied computer= science - where he or she will already have been introduced to mutexes,= semaphores, the Dining Philosophers, race conditions, deadlocks and such.=20 --=20 Per Jessen, Z=C3=BCrich (12.6=C2=B0C)
From: Per Jessen on 25 Mar 2010 04:46 Tommy Pham wrote: > As some of you mention that implementing threads will make the DB wor= k > harder than the standard serial operations queries, let me ask you > these then: >=20 > * 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.=20 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?=20 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.=20 --=20 Per Jessen, Z=C3=BCrich (12.7=C2=B0C)
From: Per Jessen on 25 Mar 2010 05:23 Per Jessen wrote: > CPU 100% - rarely, but it happens. > Memory 100% - all the time. > Disk IO 100% - less than all the time, but it's very busy. FYI, it's actually quite difficult to drive a disk subsystem to consistent 100% utilization over a period of time. Oracle uses asynchronous I/O and could probably drive a disk subsystem quite hard, but AFAIK, mysql doesn't. --=20 Per Jessen, Z=C3=BCrich (13.9=C2=B0C)
From: Tommy Pham on 25 Mar 2010 06:38 On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen <per(a)computer.org> wrote: >> * 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. > You're assuming that everyone in the PHP world uses MySQL 4.1 or newer. What about those who don't? Which goes back to being portability.
From: Per Jessen on 25 Mar 2010 06:55
Tommy Pham wrote: > On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen <per(a)computer.org> wrote:= >>> * 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. =C2=A0= Is it >>> worth it for you implement threads if you're a speed freak? >> >> Use mysqlnd - asynchronous mysql queries. >> >=20 > You're assuming that everyone in the PHP world uses MySQL 4.1 or > newer. What about those who don't?=20 They don't get to use threading, nor asynchronous mysql queries.=20 Come on, you're asking about a future feature in PHP 7.x , but would like to support someone who is seriously backlevel on mysql?? --=20 Per Jessen, Z=C3=BCrich (16.9=C2=B0C) |