[CMS] Mambo, HTTP response langzaam?

[Verwijderd]

Beste tweakers,

Mijn situatie:

Pentium II 350 Mhz, 48 MB geinstalleerd met Debian. Run volgende software Apache, PHP e.d. (Apache/2.0.52 (Unix) mod_perl/1.99_13 Perl/v5.8.4 mod_ssl/2.0.52 OpenSSL/0.9.7d PHP/5.0.2 DAV/2). Server is opgezet tbv het experimenteren met webdesign en content management systemene (CMS) in mijn geval Mambo.

Ik gebruik dus nu Mambo met templates die ik van hun site heb gedownload. Heb mbt mijn probleem meerdere templates getest (zie probleem).

Mambo kan ik zeker aanraden (mits mijn probleem niet bij derden zich voordoen) voor het testen en gebruiken van een CMS. Voor de geinteresseerde kijk even op mamboforge voor informatie.

Mijn probleem:

- Opvragen website duurt redelijk lang. De website laden valt wel mee, volgens mij zit de meeste tijd in het verschil in tijd tussen de HTTP-request en de response.


Mijn oplossingen (via een tutorial op mambohut.com):

1 (gedaan)- Enable GZIP compression: login to your admin backend interface>> from “site" drop down menu click on "Global Configuration" >> Click on the server tab >> change "GZIP Page Compression" option to yes

2 (niet mogelijk, moeilijk om te bepalen welke CSS nodig zijn en onduidelijk waar te verwijderen) - Remove any unused CSS classes from your csstemplate_css.css file to reduce its size, you can use "Web Developer Toolbar" extension available for Mozilla Firefox 0.8 browsers to see the current used classes for each page, but make sure you don't remove classes for the frontend admin section.

Click on "Read more" to continue... --> deze readmore kan ik niet aanklikken en kon ook nergens op mambohut wat vinden.

3(staat al standaard goed in de gebruikte templates)- Disable your HTML editor for guest visitors by changing the following 2 lines in your template index.php file

from

code:

<?php include ("editor/editor.php"); ?>

<?php initEditor(); ?>

to

code:

<?php

if ($my->id) {
        include ("editor/editor.php");
        initEditor();
}
?>

4 (niet gedaan aangezien ik voorbeeld templates gebruik, deze zijn al optimized. Bovendien hebben de templates onderling geen verschil in laadtijd)- Optimize all images for size, combine them, and replace graphic rollovers with CSS rollovers to speed display and minimize HTTP requests.

5 (niet gedaan, zie 4)- Reduce the number of objects (images, javascripts, etc...) on the page to increase your page response time.

6 (interessant. vooral prefix catching (server laad pagina in het geheugen voordat de pagina wordt opgevraagd) (correct me if i;m wrong) --> weet nog niet hoe dit te implementeren is in mijn configuratie.....)- Last but not least, consider using caching techniques, many techniques are now available. Do a research to find the most suitable technique for your web host environment.

Mijn concrete vraag ;):

- Voldoet mijn systeem niet aan de minimale eisen voor een Mambo configuratie. Lijkt me erg sterk?!?. (op de site van mambo worden enkel software requirements opgesteld, geen concrete system req.)
- Waar kan het volgens jullie aan liggen (de lange response op HTTP request komt volgens mij door het catchen na de response request, dit duurt telang)? en welke oplossing past daarbij?
- Andere tips/opm?

[elevator]

Kijk eens in je error_log of je niet erg veel notices / warnings hebt waardoor PHP een stuk langzamer wordt of probeer bovenaan je script eens;

ini_set('display_errors', 'off');

te zetten

Daarnaast zou je kunnen proberen APC te installeren - maar ik geloof dat die nog niet werkt met PHP5

[Verwijderd]

elevator schreef op 22 oktober 2004 @ 18:35:
Kijk eens in je error_log of je niet erg veel notices / warnings hebt waardoor PHP een stuk langzamer wordt of probeer bovenaan je script eens;

ini_set('display_errors', 'off');

te zetten

Daarnaast zou je kunnen proberen APC te installeren - maar ik geloof dat die nog niet werkt met PHP5

Hier (het relevante deel van) mijn error_log van vanochted, nadat ik 1 keer de pagina had geladen.

code:

[Fri Oct 22 21:21:37 2004] [warn] child process 458 still did not exit, sending a SIGTERM
[Sat Oct 23 11:11:27 2004] [notice] suEXEC mechanism enabled (wrapper: /opt/lampp/bin/suexec)
[Sat Oct 23 11:11:33 2004] [notice] Digest: generating secret for digest authentication ...
[Sat Oct 23 11:11:33 2004] [notice] Digest: done
[Sat Oct 23 11:11:34 2004] [notice] Apache/2.0.52 (Unix) mod_perl/1.99_13 Perl/v5.8.4 mod_ssl/2.0.52 OpenSSL/0.9.7d PHP/5.0.2 DAV/2 configured -- resuming normal operations

Overigens is dit dus de error_log, maar hier zitten dus niet echt errors in. Al laat je nog een paar keer de pagina wordt er niks extra bijgeschreven in de error_log. Dus dit zijn alleen maar notices dat hij is opgestart.

Verder init_set('dis..... moet ik dat in de index.php zetten. En wat levert dit voor snelheids voordeel?

En APC heb ik nog niks overgehoord, ken het niet. Zal wel even gaan zoeken wat dat pssies inhoudt.

Hopelijk heb je wat aan de errors?

[ Voor 10% gewijzigd door Verwijderd op 23-10-2004 12:23 ]

[crisp]

Meer iets voor SA

Webdesign & Graphics » Software Algemeen

[Spider.007]

Het error_log wat je hierboven hebt gepost is je Apache log; bekijk je PHP logfile eens? (even door je PHP.ini lopen ) Verder zou je inplaats van APC eens ZEND kunnen proberen; of Turck MMCache (die lijkt soms te werken met PHP5). Dit zijn serverside caching mechanismen.

Heb je de load van je server al eens bekeken terwijl je een pagina laadt? Heb je al eens een stresstest tool geprobeert om goed te testen? Heb je alternatieve browsers geprobeerd? Is een `wget` query bijvoorbeeld net zo traag?

[Verwijderd]

Geen verschil in oudere browsers. Load van de server is wel erg hoog, je hoort hem ook erg ratelen als je een pagina opvraagd. Tohc dan een geheugen probleem? ik hoop het niet. Overigens op de verschillende sites van mambo (zoals mamboforge wordt ook al vaker geklaagd over de performance, maar een concrete oplossing ontbreekt ).

Uhm normale html files (met beetje php script en html) laden snel, maar mambo sites duren erg lang. Je hoort hem dan gewoon een tijd ratelen (8 sec) en dan in één keer flits de hele pagina op je scherm.

Erg jammer, want ik vind het wel een erg mooi stukje software, maar zo kan ik echt geen website draaien.

[ Voor 7% gewijzigd door Verwijderd op 23-10-2004 20:37 ]

[Spider.007]

Bekijk met `top` eens wat je server nou echt doet. Kijk bijvoorbeeld of er veel CPU load is; of juist veel geheugen gebruik door je Apache processen. Trek daarna past je conclusies

Mocht het veel CPU gebruik zijn zou je wellicht GZIP weer uit kunnen schakelen. Bij veel geheugengebruik zou je wat modules uit Apache kunnen slopen (mod_perl ed).

[Verwijderd]

Spider.007 schreef op 23 oktober 2004 @ 20:10:
Bekijk met `top` eens wat je server nou echt doet. Kijk bijvoorbeeld of er veel CPU load is; of juist veel geheugen gebruik door je Apache processen. Trek daarna past je conclusies

Mocht het veel CPU gebruik zijn zou je wellicht GZIP weer uit kunnen schakelen. Bij veel geheugengebruik zou je wat modules uit Apache kunnen slopen (mod_perl ed).

Allereerst, leuk dat je zo met me meedenkt. Hier ben ik erg blij mee.

Verder, top uitgevoerd -> results:

code:

user           %cpu       % mem           command
nobody      0.0             0.3                httpd

en als ik een pagina opvraag (gemiddelde)

nobody      16.3           26.3              httpd

Die top is wel handig, je ziet als ik een pagina opvraag, dat dan ineens httpd naar bovenaan de lijst verschuift. Is dit denk je teveel geheugengebruik? of jusit mem gebruik. GZIP uitschakelen is levert juist een nog ergere vertraging op. DUs die had ik maar weer aangezet. Mogelijk dingenuit Apache slopen, moet nog even kijekn hoe ik dat moet doen (neem aan via httpd.conf). Overigens zoals je zij bv. perl uitschakelen, zal dit dan wel snelheidswinst kunnen opleveren? Ook al gebruik je het niet in je pagina's? Ik zou logischerwijs zeggen als ik het niet gebruuik dan kost het ook geen systeembronnen? Correct me if im wrong.....

Verder stappen die ik heb ondernomen.

in httpd.conf uitgeschakeld (ik vond op apache een handleiding om mogelijk performance verbetering te behalen, die ik hieronder opnoem leverde mij een beetje snelheidswinst op)

mmap on
sendfile on

Deze leverde dus wel een beetje snelheidswinst op. Nu nog andere mogelijkheden? Overigens Spider, gebruik je zelf ook mambo? en zo ja, wat voor systeem heb jij dan? Ik vraag me namelijk echt af of het niet aan mijn verouderde systeem ligt, die ik voor de server gebruik.

[Spider.007]

26,3% is erg veel Dat betekent dus dat 1 proces al meer dan een kwart van je geheugen gebruikt; en dat 4 mensen tegelijkertijd al niet meer werkt. Natuurlijk is je servertje erg klein; en geheugen kun je (vooral onder Linux) nooit genoeg hebben. Een upgraden naar 256 Mb zou voor weinig geld te doen moeten zijn; en kan je flink wat performance winst opleveren. Ik zou ook zeker eens proberen om van Apache2 terug te gaan naar Apache1, of van PHP5 naar PHP4. Vooral de move van PHP5>PHP4 zou erg grote voordelen op kunnen leveren als je het combineert met een tool als Turck MMCache. Als je toch met deze hardware en softwareversies zou willen blijven draaien zou ik inderdaad beginnen bij het uitschakelen van overbodige modules (gebruik je mod_dav bijvoorbeeld? Die staat namelijk wel aan). Ook het uitschakelen van het gebruik van .htaccess files, en het reduceren van je maxusers kan performance opleveren.

Welke tool gebruik je trouwens om de laadtijden te meten? Of doe je dit op gevoel? Vooral als je bovenstaande zaken wilt gaan tunen is het een goed idee om objectieve resultaten met behulp van ab of siege te gebruiken

[raoulduke]

Je kan met 'vmstat 1' ook nog kijken of je veel swap en CPU activiteit ziet op de momenten dat je requests doet, dat is bijna net als top maar net iets overzichtelijker om een verloop vast te stellen.

[Verwijderd]

Spider.007 schreef op 23 oktober 2004 @ 21:40:
26,3% is erg veel Dat betekent dus dat 1 proces al meer dan een kwart van je geheugen gebruikt; en dat 4 mensen tegelijkertijd al niet meer werkt. Natuurlijk is je servertje erg klein; en geheugen kun je (vooral onder Linux) nooit genoeg hebben. Een upgraden naar 256 Mb zou voor weinig geld te doen moeten zijn; en kan je flink wat performance winst opleveren. Ik zou ook zeker eens proberen om van Apache2 terug te gaan naar Apache1, of van PHP5 naar PHP4. Vooral de move van PHP5>PHP4 zou erg grote voordelen op kunnen leveren als je het combineert met een tool als Turck MMCache. Als je toch met deze hardware en softwareversies zou willen blijven draaien zou ik inderdaad beginnen bij het uitschakelen van overbodige modules (gebruik je mod_dav bijvoorbeeld? Die staat namelijk wel aan). Ook het uitschakelen van het gebruik van .htaccess files, en het reduceren van je maxusers kan performance opleveren.

Welke tool gebruik je trouwens om de laadtijden te meten? Of doe je dit op gevoel? Vooral als je bovenstaande zaken wilt gaan tunen is het een goed idee om objectieve resultaten met behulp van ab of siege te gebruiken

Tsja, een hardwarematige server upgrade vind ik nu eigenlijk zonde van het geld (het is maar een experimenteer server). Het downgraden van php5 naar 4 zie ik eigenlijk niet zo heel erg zitten (gebruik nu xampp met apache, php en alles erin dus downen is dan moeilijk -> aparte installatielukte niet erg met debian). IK ga wel je tips proberen om in httpd.conf die onderdelen uit te schakelen.

Ook is het idd een goede tip om de laadtijden vanaf nu objectief te meten, zal de tools die je hebt voorgesteld zeker even bekijken.

raoulduke schreef op 23 oktober 2004 @ 21:53:
Je kan met 'vmstat 1' ook nog kijken of je veel swap en CPU activiteit ziet op de momenten dat je requests doet, dat is bijna net als top maar net iets overzichtelijker om een verloop vast te stellen.

Hier zal ik ook even naar kijken . Morgen horen jullie er weer meer van.

[ Voor 10% gewijzigd door Verwijderd op 23-10-2004 22:50 ]

[alt-92]

/completely offtopic
Zo traag is mamboOS 4.5.1 niet eens onder IIS5.1 (xp pro) op een Centrino P-M 1.5 laptop...
Draai het maar eens op een normale hosting server.

[ Voor 9% gewijzigd door alt-92 op 23-10-2004 23:09 ]

[Verwijderd]

Hey guys,

Ik had nog een oude comp staan met 128 mb, dus die heb ik nu even in de server gegooid. Dit scheelt aannemelijk in de snelheid. Nu denk ik, eigenlijk dom dat ik dit topic heb geopend, ik wist dat de specificaties van de comp namelijk laag waren, maar goed. Eind goed al goed zullen we maar zeggen.

Btw, even nog tegen spider, jij zegt voornamelijk in linux moet je veel geheugen hebben? Ik dacht juist altijd dat debian zonder X-window etc eigenlijk maar heel weinig geheigen nodig had om te draaien. Ik hoor altijd dat mensen hele oude systemen gebruiken als webserver, maar dat gaat voor toepassingen zoals mambo, of gewoon wil je een optimaal gebruik maken van php, mysql niet echt op?!?

[alt-92]

er zit nogal verschil tussen dynamic content laten parsen door PHP of static html presenteren he....

[ Voor 9% gewijzigd door alt-92 op 23-10-2004 23:39 ]

[Verwijderd]

BackSlash32 schreef op 23 oktober 2004 @ 23:38:
er zit nogal verschil tussen dynamic content laten parsen door PHP of static html presenteren he....

Sorry, maar ik snap wat je bedoelt, maar wat wil je nou zeggen? Dat daarom veel geheugen nodig is?

[alt-92]

Neuh.. maar met static html kan ik zelfs nog een 486 inzetten als webservert.

Alleen kan ik tijdens het parsen van een CMS door PHP dan ongeveer 3x boodschappen doen in
Maastricht en weer terug rijden naar Amsterdam.
dat is resource-intensief, en system resources gebruiken geheugen...

[ Voor 8% gewijzigd door alt-92 op 23-10-2004 23:53 ]

[Spider.007]

Verwijderd schreef op 23 oktober 2004 @ 23:44:
[...]

Sorry, maar ik snap wat je bedoelt, maar wat wil je nou zeggen? Dat daarom veel geheugen nodig is?

Er zijn uiteraard mensen die Linux met zeer lage systeemspecificaties goed kunnen draaien. Je kunt echter geen wonderen verwachten. Het serveren van simpele HTML bestanden is inderdaad goed te doen op de configuratie die jij hebt; maar het draaien van een database-driven-PHP site kan eigenlijk niet op een dergelijke configuratie. Dynamische content vraagt gewoon redelijk veel kracht van een server; en vooral van een systeem als Mambo moet je niet verwachten dat het soepel draait op 48 Mb

[McMiGHtY]

Nee, static html zijn kleine file's met eventueel wat plaatjes.
Vergt weinig CPU en MEM

Met een dynamische site, met een CMS zeg maar, die zijn data uit een database haalt, en ook nog de nodige mambotags moet afhandelen, heb je met wat meer factoren rekening te houden.
je hebt een httpd, een db, en ook nog je php parser en de mambo parses voor je mambo tags

[Verwijderd]

Oke, jullie hebben me overtuigd.

Nu met 128 mb werkt het wel wat vloeiender voor particulier gebruik. Laat de configuratie dus maar zo. Tijd van static html is voorbij, dus het moet wel zo .....

Nogmaals bedankt voor jullie moeite.

[WiNlUx]

Verwijderd schreef op 24 oktober 2004 @ 00:07:
Oke, jullie hebben me overtuigd.

Nu met 128 mb werkt het wel wat vloeiender voor particulier gebruik. Laat de configuratie dus maar zo. Tijd van static html is voorbij, dus het moet wel zo .....

Nogmaals bedankt voor jullie moeite.

Laat ik hier ook maar even op inhaken. Ik ben dus ook met mambo bezig. Mijn server (Apache 1.3.31/PHP4.3.9) heeft de volgende specs:

P3 733 mhz
196 MBRAM

Voorheen zat er 128 mb in, en het ging zo traag als de donder. Dus een reepje van 64 MB erbij gezet, en ik merk echt een verschil van hier tot sint juttemes Wil ik ff kwijt

[Verwijderd]

WiNlUx schreef op 25 oktober 2004 @ 15:18:
[...]

Laat ik hier ook maar even op inhaken. Ik ben dus ook met mambo bezig. Mijn server (Apache 1.3.31/PHP4.3.9) heeft de volgende specs:

P3 733 mhz
196 MBRAM

Voorheen zat er 128 mb in, en het ging zo traag als de donder. Dus een reepje van 64 MB erbij gezet, en ik merk echt een verschil van hier tot sint juttemes Wil ik ff kwijt

Ja dat was dus ook mijn probleem WinIux......Blij dat we allebei de oorzaak hebben achterhaald