sslug-teknik team mailing list archive

[Troels Arvin <troels@xxxxxxxx>]

Klavs Klavsen wrote:

> iflg. apache selv, så mener de stadigvæk at mod_so ikke er 100% stabil
Jeg ved ikke, hvor du har set det. Jeg er sikker på, at DSO er ustabilt 
på visse eksotiske platforme, men jeg har aldrig hørt om DSO-problemer 
på Linux.

Tværtimod mener jeg at have læst core PHP udviklere anbefale --with-apxs 
fremfor --with-apache.

> Iøvrigt kan man læse mange steder at apache med mod_so ikke performer så godt
> som en statisk kompileret apache
Nej, men jeg vover den påstand, at det i praksis ikke er et problem.

På http://httpd.apache.org/docs/dso.html nævnes 5% runtime performance 
nedgang på _visse_ platforme, hvor PIC åbenbart stadig er besværligt.

> igen ved højtrafik sites, betyder 5-10% ydelse noget.
Klart. Men jeg vil vove den påstand at sådanne sites burde søge efter 
mere effektive flaskehals-afhjælpninger andre steder. Fx. i form af en 
lightweight web-server (Rasmus Lerdorf anbefalede Boa, da jeg talte med 
ham ved PHP-foredraget) til statiske ting, benyttelse af shared-memory 
sessions til at sænke behov for database-opslag (hvor relevant), osv.

Det med, at performace kommer før alt, er ikke altid smart. Fx. ville 
det betyde, at objektorienteret PHP-kodning og inkludering af faste sæt 
af PHP-funktioner i PHP include-filer, osv., var noget "fy". Og det er 
IKKE fy: Effektiv kode-genbrug har giver ofte lidt overhead, men er 
_meget_ nødvendigt på større sites.

> Desværre så nøjes jeg med at hæfte mig ved at apache selv skriver at mod_so ikke
> er 100% stabil

Det må du selv om. Jeg kan ikke finde noget som helst belæg for det, 
hverken i teori eller praksis.

Efter min mening er det et fjollet, hvis man grundet en _formodet_ 
performance nedgang praktiserer upraktiske måder at installere PHP eller 
Apache på.

> har jeg ikke lavet nogle ydelses målinger.. hvis du har nogen
> ville jeg da gerne se dem.
Jeg har ikke foretaget performance-målinger, nej. Systematiske 
performance-målinger, som er gode nok til at kunne stoles på, tager tid. 
Og da tid er penge, er det efter min mening mere fornuftigt at benytte 
lidt ekstra kroner på at kompensere med en hurtigere CPU, hvis man er 
overbevist om, at DSO-installation giver et 5% overhead.

> > > Suse's apache.. - det er bare tage dem fra rpm pakken..
> >
> > Betyder behov for mere dokumentation, og gør det sværere for andre at
> > tage over, hvis sysadm bliver syg/skifter job. Og betyder, at man taber
> > sit pakke-systems store systemadministrative fordele.
>
> Det kan jeg virkelig ikke se
Det er en gammel slager: Jeg holder på, at man bør benytte sit systems 
pakkehåndteringsfaciliteter, med mindre der er meget _vægtige_ 
argumenter imod det. Jeg opfatter det som centralt at kunne verificere 
pakkers integritet, at have nogle tjeks, der hjælper til at sikre imod 
software-mismatches. Jeg kunne fortsætte længe med dette emne. Men vil 
blot afslutte med det retoriske spørgsmål: "Hvorfor mon pakkesystemer 
(såsom .rpm og .deb) er opfundet - for sjov?"

/Troels