From: Per Jessen on
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
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
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
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
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)