RootForum Community

Hallo Rooters ;)

Lang ist's her, da habe ich mal was gefragt und jetzt bin ich mal wieder da, um eure Hilfe in Anspruch zu nehmen.

Es geht um folgendes: Wir betreiben ein Online-System zur Verwaltung von Partylocations. Derzeit sind bei uns ca. 30 solcher Locations gelistet.
Zu jeder Location werden ca. 40 SQL-Statements ausgeführt, sodass pro Seitenaufruf exakt 1200 SQL-Statements ausgeführt werden müssen.

Bis dato war das ja gar kein Problem - die Seiten haben relativ fix geladen (so 3-4 Sekunden), doch seitdem das Ding eine Nutzerverwaltung hat und fast den ganzen Tag 5-10 Personen gleichzeitig unterwegs sind auf dem Ding geht die Performance ganz arg in die Knie.

Das System ist folgendes:

Gehostet bei Hosteurope, 2 x 2,8 GHz, 2 GB Ram, 4*36 GB SCSI-Raid-10 - und das ganze auf SuSE 8.2

Programmiert ist das ganze Teil in php 4.3.10 und wird die Tage auf php 5 hochgestuft.
Im Hintergrund läuft - ganz klar - ein Apache 2 Webserver (2.0.48) und als Datenbank benutzen wir die SAP DB 7.4.

Gibt es eine Möglichkeit für uns die Performance des Servers zu monitoren? Die HTTP-Anfragen kommen alle nur sehr schleppend durch (egal von wo aus wir auf den Server zugreifen!) und das Laden der Seiten dauert ca. 20 Sekunden. Als ob der Server an siene Leistungsgrenze stößt - das kann ja aber doch gar nicht sein bei der Ausstattung.

Also, Frage: Wie kann ich das ganze System monitoren bzw. herausfinden, wo der Bottleneck sitzt.

Danke schon einmal im Vorraus,

Cupra

CupraR wrote:Zu jeder Location werden ca. 40 SQL-Statements ausgeführt, sodass pro Seitenaufruf exakt 1200 SQL-Statements ausgeführt werden müssen.

Wenn Ihr die Ergebnisse der 40 Queries in Arrays packen würdet, könntet Ihr Euch 1160 Queries sparen... Oder habe ich Dich flachs verstanden?

Ich verstehe dich gerade irgendwie nicht :(

Deiner Beschreibung nach werden die 30 Locations auf einer Seite angezeigt und für jede Location werden die gleichen 40 Queries ausgeführt (30*40=1200), richtig? Wenn Ihr die 40 Queries nicht auf jeweils eine Location begrenzt, sondern auf alle Locations gleichzeitig anwendet und die Ergebnisse in Arrays packt, bleiben nur noch 40 von 1200 Queries übrig.

Verständlicher?

Moin nochmal,

ja so hab ich das besser verstanden. Leider sind einige der Statements kausal zusammengesetzt und können auf diese Art & Weise nicht abgearbeitet werden :-(

Hi...

trotzdem sollte sich dein Code um einiges verkürzen lassen. Nimm Joe Users Vorschlag mal auf und schau, ob du die ein oder andere Query nicht zusammenfassen kannst.

1200 Queries pro Seite bei letztendlich 30 Datenquellen sind zu viel.

:roll:

Ich wollte den Vorschlag ja gar nicht komplett abtun, allerdings sind diese Seiten bereits SQL-Optimiert (auch wenns sich nicht so anhört...).
Eigentlich sind 1200 Statements (egal auf wieviele Grunddatensätze wir kommen) nicht die Welt - da kenne ich schlimmere Skripte (und die bauen auf MySQL auf) und da läufts auch ohne Probleme durch.

Nach einem sehr flüchtigen Blick ins Manual, sollte Euch Folgendes (insbesondere die Comments) weiterhelfen:

http://www.php.net/manual/en/function.o ... -array.php
http://www.php.net/manual/en/function.o ... h-into.php

HTH

Wie bereits erwähnt ist dies nicht der ausschlaggebende Punkt.
Auf einem vollkommen identischen System schafft es die Datenbank innerhalb von ca. 1 Sekunde knapp 230 Datenbankabfragen gleicher größe abzufragen.
Auf diesem System sind maximal 90 Datensätze genau derselben Größe drin. Da kann ja irgendwas nicht stimmen - da bin ich echt ratlos :(

Poste mal die Systemauslastung beider Systeme im Vergleich. Sind die Konfigurationsdateien identisch?

CupraR wrote:Ich wollte den Vorschlag ja gar nicht komplett abtun, allerdings sind diese Seiten bereits SQL-Optimiert (auch wenns sich nicht so anhört...).
Eigentlich sind 1200 Statements (egal auf wieviele Grunddatensätze wir kommen) nicht die Welt - da kenne ich schlimmere Skripte (und die bauen auf MySQL auf) und da läufts auch ohne Probleme durch.

Doch, 1200 Queries "pro Request" deuten meiner Meinung nach entweder auf ein schlechtes DB-Design oder zu simple Queries hin. Dass die "SQL-Optimiert" sind kann ja sein, was aber im Umkehrschluss nicht heißen muss, dass bereits die optimale Lösung gefunden wurde.

Und warum setzt Ihr SAPDB ein? Braucht Ihr irgendwelche Features davon? Gerade für solche Sachen - solange keine Transaktionen benötigt werden - gibt es nichts effizienteres als MySQL. Verwendet Ihr die MaxDB Extension in PECL?

Wie groß ist die DB denn?
Und wie oft (und von wem) werden die Daten verändert?

Wie gesagt, ich kann mir nicht vorstellen, dass man wirklich 1200 DB-Abfragen braucht, das meiste was ich mal gebraucht habe war irgendwas um 40 Queries bei einem System mit über 100 Tabellen. Mit fortschrittlicheren DB-Features wie Joins, Subqueries, Views, Stored Procedures und Triggers kann man eine Datenbank sehr effizient abfragen (gegenüber "SQL-Abfragen in einer Schleife in einer Schleife...").

Darüber hinaus würde ich versuchen so viel zu cachen wie möglich. Das effizienteste wäre wohl Caching auf HTTP-Ebene. Wäre es schlimm für die Anwender wenn die Daten maximal 1 Minute, 10 Minuten oder 60 Minuten... alt wären? Und sind die HTML-Seiten nicht personalisiert? Dann könnte man einen cachenden Reverse Proxy wie Squid davor stellen, der bei Cache-Hit die Ausführung des PHP-Scriptes komplett vermeidet.

Dann könnte man PECL::APC oder PECL::memcache einsetzen, um sehr oft benötigte Daten aus der DB als PHP-Datenstruktur im Shared Memory zu cachen, um sich so eben einige der Abfragen zu sparen.

Ã?brigens würde ich beim Umstieg auf PHP 5 direkt auf PHP 5.1 umsteigen, denn PHP 5.0 ist erheblich langsamer als PHP 4.x, dafür ist PHP 5.1 deutlich schneller als 4.x.

Benchmark:
http://www.sebastian-bergmann.de/blog/a ... mance.html

Zum PHP 5.1 Release Prozess:
http://news.php.net/php.internals/19664
http://news.php.net/php.qa/26156

Und dann gibt es da noch so nette Sachen wie lighttpd, der mit seiner CML (Cache Meta Language) sogar relativ intelligente Cache-Entscheidungen treffen kann, bei einer Performance die fast so gut ist wie bei statischen Request. Ein CML Cache kann mit memcached oder über das Dateisystem mit PHP "kommunizieren". Abgesehen davon arbeitet lighttpd erheblich resourcenschonender als Apache.

PS: Wenn Du mal einen link posten/schicken könntest, könnte man vielleicht sehen/verstehen ob die 1200 Queries nötig sind oder nicht

ich würde mich hier mal joeuser anschließen ... aber auch 40 SQLs finde ich noch ne nummer zu hart... Ich würde mal versuche alle Daten die du brauchst mit einem Statement zu holen und das dann möglichst weit zu optimieren... dann sollte das ganze auch besser laufen. Ich würde jetzt net versuchen an der DB rumzuschrauben wenn die Fehler ganz eindeutig im Design der Application oder der Datenbank liegen.

CupraR wrote:Ich wollte den Vorschlag ja gar nicht komplett abtun, allerdings sind diese Seiten bereits SQL-Optimiert (auch wenns sich nicht so anhört...).
Eigentlich sind 1200 Statements (egal auf wieviele Grunddatensätze wir kommen) nicht die Welt - da kenne ich schlimmere Skripte (und die bauen auf MySQL auf) und da läufts auch ohne Probleme durch.

Doch ist es. Das ist ungefähr 100x mehr als eine normale Website im Stil von phpbb, wordpress oß hat. Wenn du die Querys nicht optimieren kannst, werf das Datenbank Layout weg.