sslug-teknik team mailing list archive
-
sslug-teknik team
-
Mailing list archive
-
Message #07877
Re: PHP4/Apache2
Troels Arvin wrote:
>
> Morten Olsen wrote:
> > Jeg kunne forestille mig det ville være svært at portere ASP, idet det
> > nok bruger alt hvad det kan komme i nærheden af af MS ting, OLE, COM(+)
> > osv.
> Præcis.
>
> > ?? Jeg kan ikke se det store hit hvis apache går fra multi-process til
> > multi-thread.
> Hvad med forøget hastighed? Nok går Linux' fork() for at være hurtig
> osv., men hvis det virkelig kan mærkes med threads, er det vel fint.
Kernetråde under linux er præcis det samme som processer, og tager lige
lang tid at oprette. Den eneste forskel imellem en tråd og en process er
at tråde deler hukommelsen.
Både fork() og pthread_create (jeg mener at Pthreads som standard
benytter kernetråde, ved ikke om det er muligt at benytte user-level
tråde) er implementeret vha. clone() systemkaldet.
clone(xxx,xxx,CLONE_VM,xx) laver en ny process med samme
hukommelsesområde == en tråd.
> > hvis man har et
> > problematisk cgi-script der laver seg-fault, så lægger det hele
> > web-serveren ned.
> Sådan som jeg forstår Apache 2's opbygning:
> Du har stadig én grund-proces, som står og 'spytter' børne-processer ud,
> efterhånden som der bliver brug for det. Hvert barn kan dernæst spawn'e
> et vist antal threads. Så der gives altså ikke køb på stabiliteten i, at
> en proces kan dø uden hele serverens død.
OK, det lyder ikke helt usmart. Men som jeg skrev i forrige brev, så
ligger problemet i hvordan man venter på klienter. Man kan forestille
sig at man laver et antal underprocesser/tråde der alle sætter sig til
at lytte på port 80, vha et kald til accept() på en socket oprettet af
forældreprocessen. Problemet er nu at når en klient forbinder sig, så
vækkes alle X antal underprocesser, skeduleren vælger 1 til at tage sig
af klienten, og resten lægges så til at sove igen. Dette kaldes
"tundering herd", og når der lige pludselig er 50-100 processer i run
køen, som skeduleren gennemsøger linært, betyder det en masse tid spildt
i skeduleren. Den nuværende Apache benytter vistnok en process til at
lytte, alle underprocesserne venter på en semafor, desværre
implementeret vha. flock(). Desværre fordi denne bruger præcis samme
wake-all metode som accept(). I 2.2.8 og 2.3.1 skulle der været lavet
wake-one mulighed for accept().
Mvh Morten
>
> --
> Troels Arvin
> Copenhagen, Denmark
> http://www.mdb.ku.dk/tarvin/
References