HX3 Foren  

  HX3 Foren > Konstruktiv > Software- und Webentwicklung

Software- und Webentwicklung Planung, Programmierung und Administration
UML, JavaScript/DOM, ASP, JSP, PHP, Apache, MySQL, Python, Perl (...)

Antwort
 
Themen-Optionen Ansicht
Alt 13.11.2005, 17:42   #1 (permalink)
Newbie
 
Benutzerbild von pixelbird
 
Registriert seit: 26.07.2005
Alter: 37
Beiträge: 38
Standard Script-Performance-Test? Optimierungsmöglichkeiten?

Hallo,

Ich habe für eigene Projekte und Kunden eine Art Framework oder mini-CMS geschrieben, welches mir aus ein paar Datenbanktabellen mit Inhalt ne Seite "errechnet" und ausgibt.
Das funktioniert wunderbar und eine Seite mit 150 einzelseiten läuft auch bis jetzt ganz gut...
Ich frage mich nur, ob das ganze auch noch so "gut" läuft, wenn dann zum Beispiel mal 100 Benutzer (man ist ja bescheiden ) gleichzeitig darauf zugreifen...
  1. Frage: Gibt es bzw. weis jemand ein Tool, eine Möglichkeit (etc.) dies zu simulieren, zu testen oder irgendwie herauszufinden, bevor ich die Seite für die breite Öffentlichkeit zugänglich mache?
    Was ich schon mache, ist dass ich die Zeit für die Script-Berechnung ausrechne... die liegt eigentlich meistens noch unter 0,1 sekunden... wie zuverlässig ist der wert..? kann der server z.B. seitenaufrufe "cachen" und damit den wert verfälschen? und: kann ich daraus irgendwie auf 100 besucher gleichzeitig schliesen?
  2. Frage: Ganz generell - wenn man das überhaupt sagen kann: Was sind typische "Schlappen" in php-mysql-programmierung?
    Was kann alles den Aufbau einer Seite im Browser verlangsamen...? Natürlich zum einen alles, was mir php berechnet... Was ist mit dem xhtml-parse-vorgang? und css-Stylesheets? (hm: was läuft noch alles zwischen anfrage und fertig aufgebauter seite ab?)
  3. Frage: Was kann man generell verbessern?
    Ist es z.B. besser zwischendurch nochmal Daten aus der Datenbank zu holen, oder sie einfach einmal in ner fürs script global zugänglichen variable zwischenzuspeichern?
    Verlangsamen viele in Variablen gespeicherte Daten das Ganze?
    Schleifen und Konstrukte: sind manche "schneller" als andere?
Zu meinem Script ist mir noch die Möglichkeit des "Seiten Cachens" eingefallen... und die smarty-template-engine soll das ja beherrschen... Aber bringts des?

Ich freu mich auf ein paar aufschlussreiche antworten...!

Grüße, pixelbird
pixelbird ist offline   Mit Zitat antworten
Alt 13.11.2005, 20:20   #2 (permalink)
Administrator 10 Jahre hx3
5000 Beiträge
 
Benutzerbild von Atomic
 
Registriert seit: 21.02.2003
Ort: Köln
Alter: 38
Beiträge: 5.162
Atomic eine Nachricht über Skype™ schicken
Standard AW: Script-Performance-Test? Optimierungsmöglichkeiten?

Das ist mal ein super Thema

Allgemein: Wir leben in einer Zeit in der Entwicklungsgeschwindigkeit (Komfort der Website-Entwicklung) wichtiger geworden ist als Performance.

Achtung, hier geht es nicht nur um den Rechenaufwand (Rechenzeit) sondern auch um den Speicherverbrauch!

Das ist wirklich nur wichtig wenn mit >50000 Seitenaufrufen pro Tag zu rechnen ist.

Deshalb verfolgt jeder gute Programmierer folgenden Grundsatz:

Wir schreiben schnellen Quellcode, aber nehmen nur bedingt Umwege zu gunsten besserer Performance in Kauf.

(Das trifft natürlich nicht auf jede Situation zu.)

===

Zu deinem Framework/miniCMS (JA WAS DENN NUN?):

Erkläre mal bitte etwas genauer was das System macht.

===

Zu den Fragen:

Sicher gibt es so ein Tool, aber ich kenne keines, weil ich keines verwende.

--------------------------

Die Seitenausführungszeit kannst du berechnen. Allerdings darfst du nicht vergessen das PHP selbst auch eine gewisse Startzeit besitzt (wenn als CGI) und das Script erst "parsen" (= PHP Datei verarbeiten) muss bevor die Seitenausführung beginnt.
Ebenso gibt es Bibliotheken wie die von Regex die auch eine Startzeit haben. (Weshalb man Regex nicht für jede Kleinigkeit verwenden sollte.)

Hier etwas Quellcode frich aus unserem Framework:
PHP-Code:
<?php
 
/**
 * time.Timer - timer function
 *
 * @package time
 * @author Herbert Walde aka "Atomic" <atomic@hx3.de>
 * @version 1.0
 * @copyright 2005 www.hx3.de
 */     
 
class time_Timer{
    
/**
     * Returns an info-array of this class
     *
     * @return array
     * @access public
     */
    
static function GetClassInfo(){
        return array(
             
"description"     => "",
             
"required_classes"     => array(),
             
"optional_classes"     => array(),
             
"required_extenions"     => array(),
             
"optional_extenions"     => array()
        );
    }
    
        
    private 
$start;
    private 
$stop;
    function 
__construct() {
        list(
$usec$sec) = explode(" ",microtime()); 
           
$this->start = (float)$usec + (float)$sec
           
$this->stop=0;
    } 
    function 
GetTime($round 3) {
        list(
$usec$sec) = explode(' 'microtime());
        
$this->stop = (float)$usec + (float)$sec;
        return 
round(($this->stop $this->start), $round);
    } 
    
}
// <- End Class

?>
--------------------------

Ebenfalls lässt sich jederzeit der aktuell verwendete Arbeitsspeicher anzeigen.
=> http://de2.php.net/memory_get_usage

Tipp: Bei einem Script das ziemlich lange läuft lohnt es sich Variablen die viel Speicher verbrauchen (UND NUR DIE!) und sich im globelen Namensraum befinden sobald sie nicht mehr verwendet werden mit unset() zu löschen:
=> http://de2.php.net/unset

--------------------------

Thema "Seiten cachen".

Da ist ersteinmal zu unterscheiden zwischen: Html-Quellcode cachen und PHP Seite cachen.
Ausnahme: Sowas wie die Technik hinter Smarty (Smarty erzeugt aus Templates eine PHP Datei, damit das Template nicht bei jedem aufruf übersetzt werden muss und stattdessen die erzeugte PHP Datei ausgeführt werden kann, was natürlich viel schneller ist.)

--------------------------

PHP Seiten zu cachen ist DER PERFORMANCE GEWINN SCHLECHTHIN!

Lasst mich das kurz erklären:

Bei Sprachen wie C wird aus dem Quellcode eine Binarcode Datei erzeugt die der Prozessor ultraschnell ausführen kann.
Bei Sprachen wie Java, .NET oder Python wird zwar keine Binarcode Datei erzeugt, aber immerhin wird, der "Token" der beim "Parsevorgang" (Parsen = Quellcode verarbeiten und in einen Stapel von Befehlen ("Token") umwandeln, welcher nur noch abgearbeitet werden muss) in eine Datei geschrieben und von nunan immer direkt ausgeführt.

Nicht so bei PHP.
Bei PHP wird immer der Quellcode neu eingelesen, verarbeitet ("geparst") und dann der erzeugte "Token" abgearbeitet.
Was für eine Verschwendung von Resourcen!

Und warum das?
Damit Firma Zend (http://zend.com) aka "The php company" Geld mit ihren PHP Beschleunigern machen können.

Selbst verständlich hat sich das die PHP Community nicht gefallen lassen und so entstanden ein paar GPL lizenzierte Produkte.

Unter anderem: http://pecl.php.net/package/APC

Das bringt richtig viel Performance!

--------------------------

So und nun zum Html-Quellcode cachen: Vor ein paar Jahren hat man das gemacht. Dann hat man gemerkt das dynamische Websites den Rechenaufwand wert sind auf statische Seiten zu verzichten. Html-Quellcode cachen ist UNSINN!

--------------------------

Zum Browser:

Viel JavaScript kann Seiten langsammer machen.
Tabellendesign macht Websites langsamer, weil der gesammte Quellcode erst geladen werden muss bevor die Tabelle korrekt dargestellt werden kann.

Was macht websites im Browser schneller?

Schlanker Quellcode! (Den erhält man durch eine fette CSS Datei die auf jeder Seite einfach eingebunden wird => Einmal geladen immer geladen.)

Websiten komprimieren:
=> http://us3.php.net/ob_gzhandler

--------------------------

Zu MySQL:

1. So wenig Querys wie möglich.
2. Möglichst alles auf der Seite des Datenbank Servers berechnen.

Im uralten OFP-Center Version 1 stand mal folgender Quellcode drin:

(Das ist nicht der Originalquellcode!)

$result = mysql_query("select * from news");
$news_count = mysql_num_rows($result);
echo "<h3>Statistiken</h3> Anzahl an News: ".$news_count;

=> Um die Anzahl an News für die Statistiken im rechten Menü (welches auf jeder Seite sichtbar ist) zu berechnen wurde DIE GESAMTE NEWSTABELLE, mit allen Zeilen und allen Spalten heruntergeladen! o_O

Das ist natürlich BULLSHIT³.

3. Gutes Tabellendesign

So und jetzt noch etwas wo ich mir nicht so schlüssig bin:

Das speichern von Einstellungen.
Für mich gehören Einstellungen in PHP Dateien.
Aber mit Blick auf diese Forensoftware hier: Es scheint auch zu gehen wenn man sie in Tabellen ablegt.

--------------------------

Schleifen und Konstrukte

Das hier ist extrem langsam:

for($i=0; $i<count($array); $i++){

//...

}

Das hier ist das Gegenteil:

$y = 0;
$max = count($array);
while($y<$max){

$y++;
}

Einfach etwas genauer bei den schleifen hinschauen und überlegen was da wohl im Hintergrund vor sich geht.
Oder einfach mal einen kleinen Benchmark erstellen mit 1000 Schleifendurchläufen.

SIEHE: Wir schreiben schnellen Quellcode, aber nehmen nur bedingt Umwege zu gunsten besserer Performance in Kauf.

===

Am meisten kann man jedoch sparen in dem man gute Software-Lösungen entwirft.
__________________
https://savetheinternet.info/
Atomic ist offline   Mit Zitat antworten
Alt 15.11.2005, 00:18   #3 (permalink)
Newbie
 
Benutzerbild von pixelbird
 
Registriert seit: 26.07.2005
Alter: 37
Beiträge: 38
Standard AW: Script-Performance-Test? Optimierungsmöglichkeiten?

Danke für die außerordentlich ausführlich antwort.

Zitat:

Zu deinem Framework/miniCMS (JA WAS DENN NUN?):
Erkläre mal bitte etwas genauer was das System macht.

Ist das so wichtig?
Gib mir 2 Kurzdefinitionen, wie du sie verstehst, dann sag ich dir obs reinpasst...

-----------
Script-Ausführungszeit: Schön, so sieht meine Funktion auch aus.
-----------

Zitat:

Ebenfalls lässt sich jederzeit der aktuell verwendete Arbeitsspeicher anzeigen.
=> http://de2.php.net/memory_get_usage

Das muss ich mir mal anguggen.. danke.

Zitat:

Ausnahme: Sowas wie die Technik hinter Smarty (Smarty erzeugt aus Templates eine PHP Datei, damit das Template nicht bei jedem aufruf übersetzt werden muss und stattdessen die erzeugte PHP Datei ausgeführt werden kann, was natürlich viel schneller ist.)

Was genau ist denn schneller? bzw. was verlangsamt bei folgendem vorgang:
1. tpl/html-datei einlesen (load)
2. bestimmte tags ersetzen (str_replace)
3. ausgeben (echo)

Zitat:

So und nun zum Html-Quellcode cachen: Vor ein paar Jahren hat man das gemacht. Dann hat man gemerkt das dynamische Websites den Rechenaufwand wert sind auf statische Seiten zu verzichten. Html-Quellcode cachen ist UNSINN!

davon abgesehen, dass es "unsinn" ist, also wohl nicht den aufwand rechtfertigt... bringts denn ne performanceverbesserung?

Zitat:

Viel JavaScript kann Seiten langsammer machen.

Was ist viel?
Zitat:

Schlanker Quellcode! (Den erhält man durch eine fette CSS Datei die auf jeder Seite einfach eingebunden wird => Einmal geladen immer geladen.)

Und wenn eine fette das ganze so verzögert, dass Herr Seitenbesucher sich verabschiedet? (ja, das muss ein wirklich großes stylesheet sein...)

Zitat:

Websiten komprimieren: => http://us3.php.net/ob_gzhandler

durchs komprimieren rechnet server aber wieder mehr, oder? Wo ist die Waagestellung?

Zitat:

$result = mysql_query("select * from news");
$news_count = mysql_num_rows($result);
echo "<h3>Statistiken</h3> Anzahl an News: ".$news_count;
Das ist natürlich BULLSHIT³.

stimmt.

Zitat:

Das speichern von Einstellungen.
Für mich gehören Einstellungen in PHP Dateien.

warum?
vorteil datei / datenbank?

Zitat:

Das hier ist extrem langsam:
for($i=0; $i<count($array); $i++){

hm.. logisch... aber wieder was dazu gelernt
1000mal das array nachzuzählen ist natürlich langsamer als nur einmal davor.

Zitat:

Am meisten kann man jedoch sparen in dem man gute Software-Lösungen entwirft.

soll heißen?


Noch ein Link von mir, den ich gefunden habe: auf der seite werden verschiedene konstrukte/schleifen getestet... http://www.blueshoes.org/en/developer/php_bench/

gute nacht.
pixelbird ist offline   Mit Zitat antworten
Antwort


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 
Themen-Optionen
Ansicht

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus


Kontakt - HX3.de - Archiv - Nach oben

Angetrieben durch vBulletin, Entwicklung von Philipp Dörner & Tobias



SEO by vBSEO 3.2.0 ©2008, Crawlability, Inc.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119