Performance in PHP

[McMaiers]

Hi Leute,

ich hab ne kleine Community mit 2400 reg. Usern.

Am Tag besuchen die Seite ca. 3000 - 5000 Leute!

Es sind ca immer 5 - 20 Leute gleichzeitig auf der Seite!

Wenn die Onlineuserzahl aber über 15 geht, dann wird die Seite echt etwas langsam!!

Kann mir jemand Tipps geben wie man optimieren kann, wo kann man Resourcen sparen?!

Z.b. bringt das was wenn man ne DB-Verbingung aufbaut und die dann wieder closed oder ist das egal ?!

Bin für alle Tipps offen

Die Seite:

www.bayern-am-feiern.de

Danke mcmaiers

[baba007]

Die DB verbindungen sollte man immer schliessen...

bei mehreren Usern vielleicht auch 2 Server nehmen zur entlastung oder besseren Anbieter ...

[Jaraz]

Moin,

oder überhaupt erstmal einen eigenen Server!

Und dann am besten bei der Datenbank zu optimieren anfangen.

Also müssen alle Statements sein, werden überall Indexe benutzt. Reicht der Speicher für die Datenbank aus oder wird zwischendurch unnötig geswapt.

Wenn das alles passt, kannste dir dann Gedanken machen ob du Sachen cachen kannst. usw usw

Gruß Jaraz

[McMaiers]

Also nen eigene Server hab ich! Allerdings n Vserver!

CPU 1.400 MHz

512 MB DDR-RAM

40.000 MB Festplatte

Suse 9.3

Apache und solche sachenn sind immer aktuell!

Ich weiss zwar was cachen ist, aber wie kann ich das in PHP anwenden ?

[perdian]

Die DB verbindungen sollte man immer schliessen...

Immer? Das sehe ich anders, und werfe da mal das Stichwort ConnectionPool ein, der genau den entgegengesetzeten Weg geht

[Aiun]

*kopfkratz*

ich weis nicht ob es das ist was er wissen wollte.

Letztlich ist es egal ob ich allein auf nem Server hänge oder nicht, wenn dieser leistungsfähig genug ist. Da könnte man auch Fragen ob PHP als CGI oder imapi läuft etz.

Ich vermute mal eher er bezieht sich auf PHP Code / Design Patterns die einfluss auf Performance haben.

Beispiel:

SQL Abfrage durchführen, alle Daten in PHP Variablen Speichern (Array z.B.)

und erst "hinterher" auslesen, führt schnell zu performanceeinbrüchen. Soweit möglich also den Verweis auf die SQL-Ressource verwenden und nicht die DAten im PHP rumtragen.

Nur die nötigsten Daten laden (select * from ... ist ganz böse wenn Langtext-Felder drinsind und z.B. ein Group By o.ä.)

vielleicht wäre sinnvoll zu sagen um was für eine Seite es sich handelt, damit man Datenmänge und Struktur grob überblicken kann (Forum ?, Cms ?)

Sind dateien als Blobs gespeichert ? (meiner meinung nach auch böse ^^ )

....gibts vieles

[McMaiers]

HI Aiun , genau sowas hab ich gemeint!

Nun select * mach ich generell nie (nicht mehr) blobs hab ich auch keine!

es ist ne Community seite mit Forum Cms Gildergalerie und was hald dazugehört!

www.bayern-am-feiern.de <-- das ist die Seite!

ich hab über 120 Tabellen!

Datenmenge: Hmm 20 GB Traffik im monat , die Datenbank ist 110 MB groß! Aber sowas wolltest ned wissen oder ?!

Ne Frage:

Wenn ich das mache:

ALTER TABLE user ADD INDEX (id)

Bekomm ich die Meldung:

Die Index-Typen INDEX und PRIMARY sollten nicht gleichzeitig für die Spalte id gesetzt sein

Warum ist das so ?!

[etreu]

Ne Frage:

Wenn ich das mache:

ALTER TABLE user ADD INDEX (id)

Bekomm ich die Meldung:

Die Index-Typen INDEX und PRIMARY sollten nicht gleichzeitig für die Spalte id gesetzt sein

Warum ist das so ?!

Primary ist doch bereits eine Art Index. Du kannst ja mal deine Abfrage mittels EXPLAIN etwas genauer untersuchen. Da siehst du dann auch, wo du ggf. noch indizieren kannst. (ich denke mal du hast ne MySql-DB)

[Aiun]

gut...

so schrecklich es klingt, auch Redudanzen oder unnötiger Datenbestand kann die Performance verbessern. So verwenden einige Foren ein Datenfeld "Postanzahl" in der Forums-Tabelle, damit sie keine SQL-Abfragen auf Topics und Posts durchführen müssen und ergo performanter sind.

Problem dabei, bei jeder Änderung innerhalb dieser Datenstruktur (verschieben eines Posts / Topics, löschen...etz) muss auch dieser Wert verändert werden.

Allerdings, anders als in dynamischer ermittlung des wertes, sind das einmalige Aktionen die den Server belasten, keine abfragen die bei jedem Seitenaufruf durchgeführt werden und daher immernoch performant.

Demnach die Frage: wie gut kennst du dich mit eurem System aus / kannst es verändern. Könnten solche (ich nenne es mal so) Redundanz-Felder helfen ?

hmmm ... was kenne ich noch *die virtuelle denkglatze auf seinem kopf bewundert*

Manuelles Variablen-Killen. Klar, PHp löscht Variablen spätestens nach Ende der Verarbeitung, schneller 'dürfte' es gehen wenn du Variablen manuell entfernst, sobald sie nicht mehr gebraucht werden (nie ausprobiert). Natürlich ist auch das nur sinnvoll, wenn es sich um ein längeres Script / ne längere Funktion handelt, der die Variablen sonst noch viele Verarbeitungsschritte weitergetragen würden, ohne das man sie noch braucht.

hmmmm welche PHP Version benutzt du ?

zwischen 4 und 5 gibt es einen großen Unterschied in der Zeigerbehandlung (php4 meist übergabe by value, 5 by Reference) ... könnte sein das da noch was rauszuholen ist.

[McMaiers]

Hi. ich nehm PHP 4.3.6 her !

ICh kenn mich sehr gut mit dem system aus , denn ich habs selber geschrieben!

Da mir der server gehört hab ich auch komplettzugriff!

Ja is ne MySQL Tabelle ....

Hmm schon ganz gute Tipps .... danke schon mal ... gibts noch vorschläge

[Webbi1305]

Nur mal so im Vergleich:

1200Mhz

256MB RAM

Kiste mit mindestens 100-150 Leuten ohne Probleme... liegt also definitiv an der Programmierung!

Normalisiere die Datenbanken dann solltest du keine probleme mehr haben!

[Aiun]

*hust* *keuch*

Normalisierung ist normalerweise Feind der Performance ^^

es ist weit schneller Attribute in eine Tabelle zu packen, als ein join oder ähnliches Konstrukt.

Also eher Datenbank "weise" prüfen, als blind irgendwelchen Konzepten folgen.

[geloescht_JesterDay]

Ne Frage:

Wenn ich das mache:

ALTER TABLE user ADD INDEX (id)

wurde ja schonmal geschrieben, Primary = Primary Index, also schon selbst ein Index. Ausserdem solltest du einen Index nicht nur auf die ID setzen, sondern auf alles, wonach du die Daten selectieren kannst.

z.B. SELECT * FROM TERMINE WHERE MONAT = 10

ist der primary auf ID ok, aber zusätzlich sollte ein Index auf Monat da sein.

Auch die Kombination von Feldern ist wichtig. Wenn du also eine Abfrage hast wie z.B.

SELECT * FROM TERMINE WHERE MONAT = 10 AND TAG < 20

dann muss dein Index dafür als erstes Feld das Feld Monat und als zweites Feld das Feld Tag haben. Wenn du die Reihenfolge in der Abfrage dann änderst, greift der Index schon wieder nicht. Eine Abfrage nur auf Monat hingegen würde durch diesen Index erfüllt (nur auf den Tag dagegen nicht).

Je nach Abfragen, Tabellen und Anzahl Datensätzen kann das einen enormen Einfluss auf die Geschwindigkeit haben.

EDIT:

Um herauszufinden, ob es an den DB-Abfragen liegt und an welchen da genau, könntest du z.B. die Zeit messen, die diese Abfragen brauchen. Das geht am leichtesten, wenn du nicht in jeder Datei die mysql-Funktionen aufrufst, sondern das über eine eigene DB-Klasse (o.ä.) machst. Dann kannst du wie hier beschrieben die Zeit messen und das ganze dann incl. der Abfrage in eine Tabelle schreiben. Somit könntest du nach kurzer Zeit feststellen, wie es mit dem Abfrageverhalten aussieht und welche davon bersonders betroffen sind.

[McMaiers]

Hi noch ne Frage, hab von sawas gehört ... das soll php files "compilieren" ?!

zumindest solange sie nicht verändert werden .... und somit die Page 4- 10 x schneller machen .... meint ihr das das geht ?

http://eaccelerator.net/BinaryInstallationUk

da bin ich skeptisch ....

mfg

mcmaiers

[Amstelchen]

es gibt ungefähr ein dutzend solcher (guter und weniger guter) php-beschleuniger, z.b. turck, APC, etc etc. bevor du sowas einsetzt, würde das problem beim datenbank- und scriptdesign suchen.

s'Amstel

[McMaiers]

Alles klar ... aber generell können die echt was bringen oder wie ?!

[geloescht_JesterDay]

Alles klar ... aber generell können die echt was bringen oder wie ?!

Etwas bringen die bestimmt, ein compiliertes Programm ist gegenüber einem interpretierten eben schonmal optimiert (beim compilieren). 4-10 fache Geschwindigkeit... weiss nicht. Kommt halt auf deine Skripte an, aber denke das ist schon ein absoluter "Idealfall", wenn es um den Faktior 10 erhöht wird. Ein skript wird im Normalfall ja eh nie sehrviel länger als 1-2 Sekunden laufen (also für eine dyn. Webseite). Wenn es bei dir so viel länger dauert, liegt das wohl eher an einer langsamen DB-Anbindung bzw. einer schlechten Struktur. Da kann man enormviel rausholen.

Bsp. hier bei mir: Eine große Abfrage mit vielen Tabellen und Verknüpfungen und Bedingungen hat ohne gescheite Indexierung (also eigentlich ganz ohne) so ca. 1 min gedauert, mit den richtigen Indexen nur 1-2 Sekunden.

[McMaiers]

Wie ist das mit so Optimierer von PHP ... ändert sich dann was für mich als Programmier ?

Oder kann ich die Dateien wie gewohnt bearbeiten ?

[geloescht_JesterDay]

Wie ist das mit so Optimierer von PHP ... ändert sich dann was für mich als Programmier ?

Oder kann ich die Dateien wie gewohnt bearbeiten ?

Ich hab damit noch nichts zu tun gehabt, aber klar ändert sich für dich als Programmierer erstmal was. Die php-Seite auf dem Server ist für dich nicht mehr lesbar. Du kannst also nicht einfach mal schnell da ne Änderung machen, sondern brauchst eine 2te Entwicklungsseite, wo du Änderungen und Erweiterungen programmierst. Die Seiten da musst du dann Kompilieren und kannst sie dann wieder auf den Hauptserver spielen.

Hab auch keine Ahnung, ob du dazu einen spezielle PHP-"Interpreter" brauchst oder ob die Dateien dann Nativ-Code enthalten und praktisch wie executables ausgeführt werden. Dann sollte allerdings eine Änderung in der Apache-conf nötig sein.

[bmg4ever]

Hab auch keine Ahnung, ob du dazu einen spezielle PHP-"Interpreter" brauchst oder ob die Dateien dann Nativ-Code enthalten und praktisch wie executables ausgeführt werden. Dann sollte allerdings eine Änderung in der Apache-conf nötig sein.

Richtig in diesem Fall müsstest du dem apache sagen, dass er in jedem Verzeichnis CGI-Anwendungen ausführen darf. Und du musst dann die Endung der Compilierten Dateien beim Apache intragen. Ihm also sagen, dass die Dateien mit der Endung .bphp (für binaryPHP - oder wie auch immer du willst) CGI Anwendungen sind.

Ich selber hab aber auch noch keine Erfahrungen mit PHP-Compilern gemacht. Desweiteren macht das auch erst Sinn, wenn du deine Anwendung richtig fertig hast und der Code nurnoch minimal gewartet werden musst, was ja nicht der Fall ist, wenn es zu langsam ist

[geloescht_JesterDay]

Ihm also sagen, dass die Dateien mit der Endung .bphp (für binaryPHP - oder wie auch immer du willst) CGI Anwendungen sind.

Nun sind CGIs ja auch nicht gerade Performance-bringer. Gerade wenn der Server ausgelastet ist, ist ein PHP-Interpreter als Library geladen doch bestimmt performanter als x(Anzahl der zugreifenden Clients)-ausgeführte CGIs. Der Vorteil der Library ist ja der, dass eben mehrere Threads laufen können, ohne dass das Ding mehrfach gestartet werden muss, wie es bei CGIs der Fall ist.

Ein CGI ist ein executable, was für jede Anfrage extra gestartet werden muss und entspr. Resourcen verbraucht.

[McMaiers]

da hast recht ...ok das ist mir etwas zu riskant das ganze .... da opimier ich lieder die DB Struktur

Danke an alle .... für weiter optimierungstipps bin ich immer offen