Du bist nicht angemeldet. Der Zugriff auf einige Boards wurde daher deaktiviert.
Seiten: 1
#1 04. Januar 2013 13:23
- czarnowski
- kennt CMS/ms
- Registriert: 18. Oktober 2012
- Beiträge: 457
Was kosten Fremdlibs eigentlich an Performance ?
Selten macht sich die Gruppe der gelegentlichen Programmierer Gedanken darüber was eigentlich die Nutzung einer Fremdlib an Performance kostet.
Profis denken da ganz anders.
Und Profis machen sich nicht mehr die Mühe und stoppen jeden Kram mit Timern.
Interessant wird ja ein Programmschnipsel oder eine Fremdlib erst im Zusammenhang mit der gesamten Applikation.
Deshalb verwenden Profis zunehmend den Apache Benchmark Test (ab) weil man nur damit einfach und schnell erkennen kann was der Einsatz eines Codes kostet oder auch bringt.
Grundsätzlich gilt die Regel - jede Programmzeile kostet Performance.
Es gibt aber auch Ausnahmen bei denen der Einsatz einer Codezeile zunächst Performance kostet in ihrer Gesamtwirkung aber Performance bringt.
Deswegen ist die Gesamtbetrachtung wichtiger und da gilt als Zielmarke die Request's pro Sekunde , denn das ist die Zahl der Anfragen die das Gesamtsystem bestehend aus Server und Applikation bedienen kann.
1 Sekunde gilt heute als Faustformel - innerhalb der Zeit sollte eine Seite komplett dargestellt werden - da spielt also auch der Browseranteil einer Rolle die mit dem Benchmark aber nicht dargestellt werden kann.
Aber - kann eine Site nur 3, 5 oder 10 Seiten pro Sekunden abliefern, dann hat man für sich auch die Grenze des möglichen Wachstums gefunden. Sind es dann 4,6, oder 11 dann laufen einem bereits die Besucher weg und wenn man die Renderzeit einer Seite berücksichtigt die ausschliesslich vom Browser geliefert wird laufen die bereits bei 3,5 oder 10 Besucher pro Sekunde weg.
Hier mal Werte von cmsms Standardinstallation aktuell auf einem sehr schnellen Server bei dem System.PHP, Mysql von einer SSD Festplatte bedient werden:
Server Software: Apache/2.2.22
Server Hostname: localhost
Server Port: 80
Document Path: /cmsms/
Document Length: 16188 bytes
Concurrency Level: 50
Time taken for tests: 1.937 seconds
Complete requests: 50
Failed requests: 0
Write errors: 0
Total transferred: 832900 bytes
HTML transferred: 809400 bytes
Requests per second: 25.82 [#/sec] (mean)
Time per request: 1936.785 [ms] (mean)
Time per request: 38.736 [ms] (mean, across all concurrent requests)
Transfer rate: 419.96 [Kbytes/sec] received
und hier mal Werte eines anderen Systems auf dem gleichen Server:
Server Software: Apache/2.2.22
Server Hostname: localhost
Server Port: 80
Document Path: /237/
Document Length: 37540 bytes
Concurrency Level: 50
Time taken for tests: 0.055 seconds
Complete requests: 50
Failed requests: 0
Write errors: 0
Total transferred: 1886550 bytes
HTML transferred: 1877000 bytes
Requests per second: 915.58 [#/sec] (mean)
Time per request: 54.610 [ms] (mean)
Time per request: 1.092 [ms] (mean, across all concurrent requests)
Transfer rate: 33736.20 [Kbytes/sec] received
Da liegen also Welten dazwischen.
Aber auch da wird nur mit Wasser gekocht - aber man hat sich in dem zweiten Fall sehr viel mehr Gedanken darüber gemacht was die Performance und damit das Wachstum behindert und diese Dinge beseitigt.
Wie aber geht man vor ?
Zunächst macht man sich eine Testumgebung auf einem lokalen Server und setzt darin eine "leere" index.php
[== php ==]
<?php
$content='Hello world';
?>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title></title>
</head>
<body>
<?php echo $content;?>
</body>
</html>Dann wirft man den Apache Benchmark an und testet das - ergibt z.B.
Requests per second: 2983.29 [#/sec] (mean)
und nun initialisiert man das gewünschte Fremdlib ohne es zu verwenden - hier Smarty 3 aktuell und macht dann erneut einen Benchmark - Test:
Requests per second: 389.75 [#/sec] (mean)
Das Ergebnis zeigt - wir haben einen Performanceverlust von rund 87% nur über das Init und ohne das wir Smarty verwendet haben.
Und nun tauscht man auf gleiche Art Smarty mit anderen Templateengines aus und checkt da den Verlust.
Die beste Alternative bietet da
Requests per second: 1550.44 [#/sec] (mean)
und kann dabei sogar noch erheblich mehr und ist flexibler.
Und so kann man es mit allen Fremdlibs machen.
Nach dem groben Test hat man bereits gefiltert. In der Regel werden die schlechten Leistungen auch nicht besser, aber dennoch sollte man dann dem Lib seiner Wahl dann noch nach dem gleichen Verfahren einem kleinen Praxistest unterziehen um keine Überraschungen zu erleben.
Aber auch ganz klar - jede eingebundene Klasse bzw. Lib. kostet Performance und zwar deutlich.
Und wie bereits Anfangs gesagt - jeder Code kostet ebenfalls im Normalfall Performance, deswegen verbietet sich jeder unnötige Schnipsel.
Klassen sind gut und schön aber man sollte Klassen nicht einsetzen wenn dazu wenige herkömmliche Funktionen universell eingesetzt werden können, denn Klassen kosten richtig Performance und auch RAM und damit ebenfalls wieder Performance.
Noch ein Satz zum memory_limit.
Habe ich da 32 MB eingestellt bekommt jeder Besucher diese 32 MB ob er sie nun wirklich benötigt oder nicht.
Ein kleiner Server mit 8GB hat vielleicht 6 GB netto zur Verfügung das bedeutet rund 188 User können dann gleichzeitig via RAM bedient werden.
Aber 6 GB auf einem shared Webserver mit ein paar hundert Domains drauf sind reine Illusion und das bedeutet man läuft sehr schnell in den Bereich des virtuellen RAM's und das bedeutet Festplatte und das könnte zur Folge haben das die max_execution_time nicht ausreichen wird.
So sollte man sich auch den RAM Bedarf ausgeben lassen:
<?php echo $content;echo memory_get_peak_usage(true)?>
der bei dem Smarty Beispiel 1572864 Bytes beträgt, bei der Alternative 524288 Bytes.
Der Bedarf steigert sich jedoch bei Smarty im realen Betrieb enorm, bei der Alternative nur gering, deshalb immer noch Praxistest's machen.
Wer auf diese Art auch mit seinem eigenen Programcode hantiert kommt dann sehr schnell darauf das man so manche Teillösungen erheblich effizienter gestalten kann und unterm Strich noch eine gewaltige Performance übrig bleibt.
Es muss immer das Ziel sein das memory_limit auf den kleinst möglichen Wert einzustellen der einen sicheren Ablauf ermöglicht.
Offline
Seiten: 1