/ Forside / Teknologi / Udvikling / PHP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
PHP
#NavnPoint
rfh 3959
natmaden 3372
poul_from 3310
funbreak 2700
stone47 2230
Jin2k 1960
Angband 1743
Bjerner 1249
refi 1185
10  Interkril.. 1146
Kompilering af PHP-kode
Fra : Jonas Koch Bentzen


Dato : 10-08-02 01:16

Jeg har lige siddet og leget lidt med PHP Accelerator
(http://php-accelerator.co.uk/) og vil gerne dele mine erfaringer med
jer... En af de mest positive ting var, at installationen er pærenem:
Librariet hentes i binær udgave, så det eneste, man behøver at gøre, er
at kopiere librariet ned i f.eks. /usr/local/lib og så tilføje følgende
linje til php.ini:

zend_extension = /usr/local/lib/php_accelerator_1.3.2.so

Derefter genstarter man serveren, og så kører det.

Den seneste version af PHP Accelerator er til PHP 4.2.1, men jeg har
ikke haft nogen problemer med at bruge det med PHP 4.2.2 på de to
servere, jeg testede det på (sandsynligvis fordi, PHP 4.2.1 og 4.2.2 er
rimelig ens bortset fra en rettelse af en sikkerhedsfejl).

Jeg testede først på min egen bærbare vha. ApacheBench (1000
forespørgsler, 50 ad gangen). Resultatet var, at PHP med PHP Accelerator
var godt tre gange hurtigere. Okay, godt nok. Jeg installerede så PHP
Accelerator på en server ude i byen og kørte samme test. Denne gang
kørte jeg det på et PHP-script, der lavede en del forespørgsler til
PostgreSQL, hvilket selvfølgelig vil sige, at forskellen på med og uden
accelerator bliver mindre, eftersom scriptet stadig skal udføre de samme
databaseforespørgsler. Alligevel var det skuffende at se, at båndbredden
åd stort set al forspring, PHP Accelerator havde (jeg sidder på en 384
Kbit/s-linje). Tidsmæssigt var der ikke den store forskel på testen med
PHP Accelerator og testen uden. Det viser ret tydeligt, at det altså er
båndbredden, ikke scriptfortolkningstiden, der er flaskehalsen. Okay,
det vidste I jo godt i forvejen, men det store spørgsmål er så, om det
overhovedet er værd at bruge acceleratorer a la PHP Accelerator?

For PHP Accelerator:
- Lidt højere hastighed - som dog alligevel ikke får den store betydning
for slutbrugeren - det er båndbredden, der er flaskehalsen.
- Lidt mindre resurseforbrug, omend der ikke er den store forskel.

Imod PHP Accelerator:
- Det giver en mere usikker opsætning: Det er om jeg så må sige endnu et
led i kæden, der kan briste, og hvis man skal have et stabilt
højtrafiksite er det et åbent spørgsmål, om det overhovedet er risikoen
værd. F.eks. er det et problem, at man sandsynligvis skal til at
udskifte PHP Accelerator hver gang, man opgraderer sin PHP. Glemmer man
at gøre det, risikerer man fejl.

Min egen anbefaling efter at have udført dette (indrømmet:
ufuldstændige) forsøg er, at man nok bør gå mere efter at løse
båndbreddeflaskehalsen end at gå efter kompilerede scripts a la PHP
Accelerator. Det, man kan gøre ved båndbreddeflaskehalsen, er f.eks. at
bruge mod_gzip (eller ob_start("ob_gzhandler") i sine PHP-scripts).

Hvis der er andre, der har erfaring med scriptkompileringsmekanismer a
la Zend Accelerator, APC eller lignende, vil jeg meget gerne høre om det.


 
 
Larz (10-08-2002)
Kommentar
Fra : Larz


Dato : 10-08-02 02:20

Jonas Koch Bentzen wrote:
> Jeg har lige siddet og leget lidt med PHP Accelerator

Ja, den kender jeg :)

> For PHP Accelerator:
> - Lidt højere hastighed - som dog alligevel ikke får den store betydning
> for slutbrugeren - det er båndbredden, der er flaskehalsen.

Det kommer helt an på kompleksiteten af dine scripts ;)
Det har en stor betydning når du har *mange* besøgende - specielt hvis
du benytter shm! :)

> Imod PHP Accelerator:
> - Det giver en mere usikker opsætning: Det er om jeg så må sige endnu et
> led i kæden, der kan briste, og hvis man skal have et stabilt
> højtrafiksite er det et åbent spørgsmål, om det overhovedet er risikoen
> værd. F.eks. er det et problem, at man sandsynligvis skal til at
> udskifte PHP Accelerator hver gang, man opgraderer sin PHP. Glemmer man
> at gøre det, risikerer man fejl.

Jaah, hvis du vil op og have performance der ligner weblogic og
lignende, er du nødt til at ty til php accelerator eller lignende...

> Min egen anbefaling efter at have udført dette (indrømmet:
> ufuldstændige) forsøg er, at man nok bør gå mere efter at løse
> båndbreddeflaskehalsen end at gå efter kompilerede scripts a la PHP
> Accelerator. Det, man kan gøre ved båndbreddeflaskehalsen, er f.eks. at
> bruge mod_gzip (eller ob_start("ob_gzhandler") i sine PHP-scripts).

Tjah, du får nok ikke så meget ud af phpa hvis du ikke har et site der
har rigtig mange sidevisninger...
Iøvrigt kan du bruge zlib til det samme ;) i .htaccess kan du (hvis du
ikke vil have det global - i så fald gør det i php.ini) sætte
zlib.output_compression til On...

> Hvis der er andre, der har erfaring med scriptkompileringsmekanismer a
> la Zend Accelerator, APC eller lignende, vil jeg meget gerne høre om det.

Jeg lavede en del research på området da vi besluttede at smide phpa på
vores site... Faktisk er Zend Accelerator og PHP Accelerator de to
eneste der er værd at kigge på! Nick Lindrigde som er forfatteren til
phpa giver personlig og ofte meget hurtig support, så det er helt klart
et projekt der er noget værd!
Det eneste alternativ for os var Zends... Og den gad vi ikke betale
80.000,- for når vi kunne få en der matchede performance gratis!


--
-
Lars
http://coder.dk/sohofaq.php - Uofficiel WOL SOHO 77 FAQ
http://wshlman.moons.dk/ - Say goodbye to GameSpy
- A Free Half Life Manager!
To mail me remove your-pants.


Jonas Koch Bentzen (10-08-2002)
Kommentar
Fra : Jonas Koch Bentzen


Dato : 10-08-02 08:45

Larz skrev:
>
> Tjah, du får nok ikke så meget ud af phpa hvis du ikke har et site der
> har rigtig mange sidevisninger...

Det har jeg (trafikken er ca. 15 GB per måned). Men det, du (og Niels) i
virkeligheden siger, at hvis jeg har et site, der har så mange
besøgende, at processoren virkelig er presset, så er der gode ting at
hente ved PHP Accelerator.

> Jeg lavede en del research på området da vi besluttede at smide phpa på
> vores site... Faktisk er Zend Accelerator og PHP Accelerator de to
> eneste der er værd at kigge på!

Det er også mit indtryk. Alene det, at de fleste andre projekter ikke er
blevet opdateret i månedsvis eller årevis gør, at man er tilbøjelig til
at vælge en af de to.


Larz (11-08-2002)
Kommentar
Fra : Larz


Dato : 11-08-02 19:15

Jonas Koch Bentzen wrote:
> Det har jeg (trafikken er ca. 15 GB per måned). Men det, du (og Niels) i
> virkeligheden siger, at hvis jeg har et site, der har så mange
> besøgende, at processoren virkelig er presset, så er der gode ting at
> hente ved PHP Accelerator.

phpa bruger også shared memory til at cache sider, så du vinder noget
ved det!

> Det er også mit indtryk. Alene det, at de fleste andre projekter ikke er
> blevet opdateret i månedsvis eller årevis gør, at man er tilbøjelig til
> at vælge en af de to.

Yeps :)

--
-
Lars
http://coder.dk/sohofaq.php - Uofficiel WOL SOHO 77 FAQ
http://wshlman.moons.dk/ - Say goodbye to GameSpy
- A Free Half Life Manager!
To mail me remove your-pants.


Jonas Koch Bentzen (11-08-2002)
Kommentar
Fra : Jonas Koch Bentzen


Dato : 11-08-02 19:17

Larz skrev:
> Jonas Koch Bentzen wrote:
>
>> Det har jeg (trafikken er ca. 15 GB per måned). Men det, du (og Niels)
>> i virkeligheden siger, at hvis jeg har et site, der har så mange
>> besøgende, at processoren virkelig er presset, så er der gode ting at
>> hente ved PHP Accelerator.
>
>
> phpa bruger også shared memory til at cache sider, så du vinder noget
> ved det!

Den lægger også nogle filer i /tmp... Bruger den både delt hukommelse og
noget fil-noget, eller kun en af delene?


Larz (11-08-2002)
Kommentar
Fra : Larz


Dato : 11-08-02 19:20

Jonas Koch Bentzen wrote:
>> phpa bruger også shared memory til at cache sider, så du vinder noget
>> ved det!
>
> Den lægger også nogle filer i /tmp... Bruger den både delt hukommelse og
> noget fil-noget, eller kun en af delene?

Den bruger både $TMP og shm (hvis du har shm enablet) - shm er som regel
begrænset (typisk 8MB) - hvorimod $TMP filerne bare har en bestemt TTL
(time to live).

--
-
Lars
http://coder.dk/sohofaq.php - Uofficiel WOL SOHO 77 FAQ
http://wshlman.moons.dk/ - Say goodbye to GameSpy
- A Free Half Life Manager!
To mail me remove your-pants.


Jonas Koch Bentzen (11-08-2002)
Kommentar
Fra : Jonas Koch Bentzen


Dato : 11-08-02 20:07

Larz skrev:
> Jonas Koch Bentzen wrote:
>
>>> phpa bruger også shared memory til at cache sider, så du vinder noget
>>> ved det!
>>
>>
>> Den lægger også nogle filer i /tmp... Bruger den både delt hukommelse
>> og noget fil-noget, eller kun en af delene?
>
>
> Den bruger både $TMP og shm (hvis du har shm enablet)

Hvor slås det til? I php.ini?


Larz (11-08-2002)
Kommentar
Fra : Larz


Dato : 11-08-02 21:02

Jonas Koch Bentzen wrote:
>>>> phpa bruger også shared memory til at cache sider, så du vinder noget
>>>> ved det!
>>>
>>> Den lægger også nogle filer i /tmp... Bruger den både delt hukommelse
>>> og noget fil-noget, eller kun en af delene?
>>
>> Den bruger både $TMP og shm (hvis du har shm enablet)
>
> Hvor slås det til? I php.ini?

Se om det er slået til med phpa_cache_admin -mv
Slå til til med phpa_cache_admin -e og slå det fra med -d

(c:

--
-
Lars
http://coder.dk/sohofaq.php - Uofficiel WOL SOHO 77 FAQ
http://wshlman.moons.dk/ - Say goodbye to GameSpy
- A Free Half Life Manager!
To mail me remove your-pants.


Tinky Winky (10-08-2002)
Kommentar
Fra : Tinky Winky


Dato : 10-08-02 13:05

> For PHP Accelerator:
> - Lidt højere hastighed - som dog alligevel ikke får den store betydning
> for slutbrugeren - det er båndbredden, der er flaskehalsen.
> - Lidt mindre resurseforbrug, omend der ikke er den store forskel.

Kan den også bruges til at beskytte sin kode, ligesom Zend's encoder?



Jonas Koch Bentzen (10-08-2002)
Kommentar
Fra : Jonas Koch Bentzen


Dato : 10-08-02 15:14

Tinky Winky skrev:
>>For PHP Accelerator:
>>- Lidt højere hastighed - som dog alligevel ikke får den store betydning
>>for slutbrugeren - det er båndbredden, der er flaskehalsen.
>>- Lidt mindre resurseforbrug, omend der ikke er den store forskel.
>
>
> Kan den også bruges til at beskytte sin kode, ligesom Zend's encoder?

Nej. Jeg mener dog, jeg har set enkelte gratis programmer, der kan det,
på freshmeat.net.


Niels Andersen (10-08-2002)
Kommentar
Fra : Niels Andersen


Dato : 10-08-02 08:24

Jonas Koch Bentzen wrote in <3D545B3F.2030103@eksempel.dk>:
> Alligevel var det skuffende at se, at båndbredden
> åd stort set al forspring, PHP Accelerator havde (jeg sidder på en 384
> Kbit/s-linje). Tidsmæssigt var der ikke den store forskel på testen med
> PHP Accelerator og testen uden. Det viser ret tydeligt, at det altså er
> båndbredden, ikke scriptfortolkningstiden, der er flaskehalsen.

Her snakker vi jo så om det specifikke site. I forhold til at køre PHP
Accelerator er der tale om få beregninger til meget html.

Var forholdet omvendt, ville det straks være noget andet.

Spørgsmålet er altså hvor flaskehalsen var i forvejen. Der er vel ingen
grund til at bruge PHP Accelerator, hvis ikke CPU'en halter, og der er
masser af båndbredde endnu.

> Okay,
> det vidste I jo godt i forvejen, men det store spørgsmål er så, om det
> overhovedet er værd at bruge acceleratorer a la PHP Accelerator?

Hvis CPU'en er flaskehalsen, så er det da en billig måde at forøge
performance. Ellers kan jeg ikke se hvorfor man skulle bruge produktet.

> For PHP Accelerator:
> - Lidt højere hastighed - som dog alligevel ikke får den store betydning
> for slutbrugeren - det er båndbredden, der er flaskehalsen.
> - Lidt mindre resurseforbrug, omend der ikke er den store forskel.

Ærligt talt, så forstår jeg ikke hvorfor du legede med PHP Accelerator, hvis
båndbredden var flaskehalsen. :)

--
Mvh.

Niels Andersen
(la nels. anersyn.)

Anders Johannsen (11-08-2002)
Kommentar
Fra : Anders Johannsen


Dato : 11-08-02 18:14

> Alligevel var det skuffende at se, at båndbredden
>åd stort set al forspring, PHP Accelerator havde (jeg sidder på en 384
>Kbit/s-linje). Tidsmæssigt var der ikke den store forskel på testen med
>PHP Accelerator og testen uden. Det viser ret tydeligt, at det altså er
>båndbredden, ikke scriptfortolkningstiden, der er flaskehalsen. Okay,
>det vidste I jo godt i forvejen, men det store spørgsmål er så, om det
>overhovedet er værd at bruge acceleratorer a la PHP Accelerator?

Det er svært for mig at gennemskue, hvad du ønsker at produktet skal gøre.
Kommentarer og lidt baggrund følger nedenfor.

Der er to trin, når PHP skal udføre et script: Først oversættes koden til et
internt format (såkaldt op-kode), derpå påbegynder eksekveringen af den
oversatte kode.

PHP Accelerator cacher op-koden, og sparer derfor første trin. Desværre
måler Apache Bench den samlede tid for begge trin samt overhead ved
webserveren. Det gør det sværere at måle den egentlige virkning af
acceleratoren, hvis man sidder på en forbindelse med begrænset båndbredde.

Uden at have prøvet det aktuelle produkt, vil jeg mene, at det lade sig gøre
at få et indtryk af, hvor stor en tidsmæssig besparelse man kunne opnå.

Den potentielle tidsmæssige gevinst (pr. forespørgelsel) er defineret ved

Tsamlet - Teksekvering

Tsamlet kan aflæses i Apache Bench som "Time per request"
Eksekveringstiden kan findes ved at registrere tiden som det første og det
sidste i et script, og finde forskellen. Nedenstående pseudo-kode
illustrerer dette:

<?php
$begin = time();
[actual script]
$end = time();
$exec = $end - $begin;
?>

I relativt avancerede scripts med over 100Kb kode pr. forespørgsel, har jeg
observeret at op mod halvdelen af den samlede tid bliver brugt i
oversættelsesstadiet. Hvis acceleratoren holder hvad den lover, vil denne
tid kunne spares helt væk.

Jo større kodemængde der skal udføres, jo større er besparelsen.

Det kan i øvrigt også tænkes, at flaskehalsen flytter sig, hvis ens
båndbredde er 100Mbit i stedet for f.eks. 384Kbit.

/A



Søg
Reklame
Statistik
Spørgsmål : 177559
Tips : 31968
Nyheder : 719565
Indlæg : 6408938
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste