[PHP] geheugengebruik applicatie

[orf]

Al geruime tijd ben ik bezig met een modulair CMS, oop geschreven.

Het CMS maakt gebruik van Smarty en Formhandler en een set van eigen classes (grote extend op formhandler, database class, gebruiker class en wat kleinere classes en functies)

Omdat alles bij elkaar nogal wat code is, ben ik benieuwd naar het geheugengebruik. Ik wil het proberen zo ver mogelijk te optimaliseren voor productie gebruik.

Om op mijn (windows xp met apache) localhost het geheugen te testen heb ik dit tooltje gedownload: pslist.exe (http://www.sysinternals.com/Utilities/PsTools.html).

In een sessie houd ik het geheugengebruik bij. Ik weet alleen niet wat goed is of wat niet; wat zou een applicatie als deze mogen gebruiken aan geheugen?

Overview table met records in de betreffende module:

code:

[memory_usage] => Array
        (
            [start] => 5088 KB
            [require config.php] => 5076 KB
            [require database.class.php] => 5244 KB
            [require smarty.class.php] => 6040 KB
            [require formhandler.class.php] => 6896 KB
            [require form.class.php] => 7536 KB
            [require gebruiker.class.php] => 7508 KB
            [form class constructor] => 7516 KB
            [formhandler called] => 7496 KB
            [method fOutput called] => 7680 KB
            [template - output] => 7792 KB
        )

formulier weergave nieuw item toevoegen

code:

[memory_usage] => Array
        (
            [start] => 5124 KB
            [require config.php] => 5112 KB
            [require database.class.php] => 5284 KB
            [require smarty.class.php] => 6068 KB
            [require formhandler.class.php] => 6940 KB
            [require form.class.php] => 7500 KB
            [require gebruiker.class.php] => 7544 KB
            [form class constructor] => 7552 KB
            [formhandler called] => 7536 KB
            [method fOutput called] => 7720 KB
            [template output] => 7828 KB
        )

formulier post (met een afbeelding upload)

code:

[memory_usage] => Array
        (
            [start] => 5112 KB
            [require config.php] => 5104 KB
            [require database.class.php] => 5244 KB
            [require smarty.class.php] => 6052 KB
            [require formhandler.class.php] => 6912 KB
            [require form.class.php] => 7568 KB
            [require gebruiker.class.php] => 7576 KB
            [form class constructor] => 7532 KB
            [formhandler called] => 7524 KB
            [image crop function started image filesize: (5476.45 KB)] => 7556 KB
            [image crop function end] => 7600 KB
            [method fOutput called] => 7732 KB
            [done] => 7768 KB
        )

Is er uit bovenstaande staatjes iets zinnigs te halen, of kan ik dit beter op een andere manier testen?
Als er al iets zinnigs uit te halen is, waar zou dan de meeste winst te behalen zijn?

(ik zie bijvoorbeeld dat het geheugengebruik vooral oploopt bij het includen van classes, die pas op een later tijdstip aangeroepen worden)

Bedankt voor eventuele inzichten!

[Verwijderd]

je zou het kunnen vergelijken met soort gelijke programma's van andere programeurs. Als je dan grote uitwijkingen ziet kan je het probleem op zoeken en aan de hand van deze punten je programma optimaliseren.

[EdwinV]

(ik zie bijvoorbeeld dat het geheugengebruik vooral oploopt bij het includen van classes, die pas op een later tijdstip aangeroepen worden)

Dat kan je oplossen door de __autoload functie te gebruiken binnen PHP5. Zoiezo ben je dan van de verantwoordelijkheid af van het includen van de klassen, maar worden de klassen ook alleen maar geinclude als je ze in je script echt gebruikt. Wellicht dat dat op bepaalde plaatsen enigzins kan schelen.

[orf]

Bedankt voor jullie antwoorden

je zou het kunnen vergelijken met soort gelijke programma's van andere programeurs. Als je dan grote uitwijkingen ziet kan je het probleem op zoeken en aan de hand van deze punten je programma optimaliseren.

Ik heb geen vergelijkingsmateriaal. Het systeem valt niet te vergelijken met de bekende open-source systemen. Commercieel zal er misshien een vergelijkbaar systeem verkrijgbaar zijn, maar ik voel er weinig voor om een systeem te kopen ter vergelijking.

Dat kan je oplossen door de __autoload functie te gebruiken binnen PHP5.

Deze functie kende ik niet.
Ik heb het systeem geschreven voor PHP4, ik denk echter dat het in de nabije toekomst geport wordt naar php5.

[4VAlien]

In hoeverre loopt het geheugen gebruik op bij 10 requests tegelijk? Denk niet dat je in php geheugengebruik moet gaan optimaliseren omdat als dat echt een issue is je beter C++ oid had kunnen kiezen. Tevens, als die pagina's in 10ms geladen zijn kan je met 8MB vrij RAM nog steeds 10 requests per seconde aan.

Verder zie ik dat je weinig kan doen, stel dat je het gebruik zelf terug kan brengen met 25% (lijkt me veel). Dan heb je dus 5MB start + 3MB * 75% is 7,25 ipv 8MB. Oftewel dat maakt geen drol uit.

[orf]

Pagina's worden geparsed in gemiddeld 6ms.
Het systeem is voor het MKB, er zullen niet veel mensen tegelijk gebruik maken van dit systeem (de back-end).

Het geheugen gebruik is geen issue, maar ben op dit moment gewoon aan het kijken op welke punten het systeem verbeterd kan worden door middel van kleine aanpassingen. Datamodel en databasegebruik lijken in ieder geval goed te zijn.

Ik ga sowieso kijken wat de performance winst is bij gebruik van bijvoorbeeld Zend Accelerator.

[Clock]

Het lijkt me eigenlijk een stuk belangrijker hoe de performance is voor de bezoekers (de gewone website dus). Ik neem aan dat er niet 100 mensen tegelijk in een CMS backend zitten te wroeten, maar 100 bezoekers tegelijkertijd is niet zo heel veel.
Ik denk dat daar meer winst te behalen valt dan aan het (nu al snel genoege) backend te sleutelen

[orf]

Het systeem levert alleen tools voor de front-end (smarty / database class). De snelheid van de voorkant hangt dus vooral af van de complexiteit van de betreffende website. Het op deze wijze ontwikkelen doe ik al een aantal jaar en daar ben ik ook erg tevreden over, maar nu is het back-end systeem vele malen krachtiger en complexer geworden. En voordat ik dit volop ga gebruiken in productie-omgeving wil ik het zo ver als mogelijk optimaliseren.