nicht angemeldet
Moin!
Der Thread ist zwar schon seit ein paar Tagen scheinbar ausdiskutiert, dennoch will ich aus Vollständigkeitsgründen nochmal einhaken und ein paar Dinge herausstreichen, die nach meiner Ansicht in der gesamten Diskussion bislang zu unbeachtet geblieben sind.
Finde den Bottleneck.
JA ABER WO??? Oder besser gesagt wie??
Messen, messen, messen, und nochmal messen.
Und zwar die verbrauchte Zeit in einer geeigneten Einheit. Sekunden sind zu grob, Millisekunden eventuell auch, Mikrosekunden sollten es sein.
Das Suchwort für vorbereitete Software, die sowas macht, lautet "Profiler".
Du hast kein Linux-Problem (das schließe ich einfach mal so aus, eben weil Du einen *managed* Server hast), sondern Performance-Probleme in Deiner PHP-Anwendung und evtl. auch in Deinem MySQL-Server.
Der Auszug von "top" ist nach meiner Ansicht sehr eindeutig:
12065 mysql 15 0 851m 238m 3292 S 36.9 11.8 42:31.61 1 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --u
3143 bind 23 0 63340 21m 920 S 0.0 1.1 7:40.86 1 /usr/sbin/named -u bind
30132 nobody 18 0 145m 10m 6964 R 0.0 0.5 0:03.91 0 /usr/sbin/httpd -k restart
Position 1: MySQL mit 36.9% CPU
Position 2: named mit 0% CPU
Positionen 3, 4: Apache mit 0% CPU
Wer wartet hier wohl auf wen? An PHP liegt das Problem mit Sicherheit nicht - wenn überhaupt, werden Probleme mit PHP erst sichtbar, wenn die Probleme mit MySQL gelöst sind. Also ist es unsinnig, an PHP herumzudoktoren, das aktuelle Problem ist einzig und allein der DB-Zugriff.
Laufzeit-Informationen
Abfrageart ø pro Stunde %
delete 69.747 4.898,82 4,78 %Warum löschst Du so viel aus der DB?
insert 356.186 25.017,45 24,43 %
select 398.842 28.013,49 27,35 %
update 109.894 7.718,63 7,54 %
Du hast eine wichtige Zeile übersehen:
change db 155.905 10.950,31 10,69 %
Die Applikation ändert wie wild an der Datenbankstruktur herum! Sowas sollte man unbedingt unterlassen, es kann keinen vernünftigen Sinn haben.
Das Verhältnis von Insert und Select kommt mir seltsam vor. Mir scheint, alles was Du schreibst, liest Du nur ein einziges Mal wieder, danach wird es nicht mehr gebraucht.
Wenn in die DB jeder Zugriff geloggt wird, und jeder Seitenabruf nur ein einziges SELECT erfordert, wäre dieses Verhältnis erklärlich.
Über 14 Stunden ist das natürlich eine sehr wackelige Statistik.
Angesichts der Menge an Queries aber auch wieder verlässlich.
Warum willst Du Deine Anwendung unbedingt mit einem ".html" am Ende der URL ausliefern? Dem Browser ist das Ende der URL vollkommen egal, umd dem Server macht es weniger Arbeit, wenn Du auf so einen Unsinn verzichtest.
Geht nicht bin auch ein wenig SEO
Scheiße Endet Oben?
Glaubst Du wirklich, irgendeine Suchmaschine würde sich für das Ende Deiner URL interessieren? MIME-Types vielleicht, aber nicht irgendwelche URL-Bruchstücke.
mod_rewrite ist hier nicht das Problem, die DB-Queries sind es.
Ja! ca. 24 Stunden als *.zip File. Mysql Cache ist on. Hauptdatenbänke im Cache ohne upload und co.
Bei der Entwicklung der Seite habe ich mir überlegt wenn ich Datenbankabfragen der letzten 24h als File bzw. fertiges *.html im Cache Ordner lege gewinne ich Zeit und entlaste den MysqlServer.Hast Du überlegt, wie oft die selbe Abfrage innerhalb 24h kommt?
Schalte diese Logik mal komplett ab. Insbesondere, wenn Du die Dateien in ein ZIP-File packst, das bei jedem Request aktualisiert wird, hast Du eine *R*I*E*S*I*G*E* Performance-Bremse. File-I/O ist langsam, aber wenn Du File-I/O auf ein komprimiertes Archiv machst, verbrennst Du auch noch jede Menge RAM und CPU für das Komprimieren und Dekomprimieren.
Ich bin ganz bei dir, was die Elimination dieser anlasslos erfundenen Pseudo-Optimierung angeht. Wenn tatsächlich sich häufig wiederholende Queries ein Problem wären, würde man das ja feststellen und durch Caching abmildern können. Es ist aber so gut wie unmöglich, im Vorraus vorherzusagen, welcher Query problematisch wird, und welcher nicht. Also kann man auch nicht im Vorraus optimieren.
Andererseits glaube ich eher nicht, dass das Zippen aktuell ein Teil des Problems ist... - unnötige Optimierungen zu entfernen und zu sehen, ob sie nicht Ursache des Problems sind, in jedem Fall aber dadurch das System zu vereinfachen, ist allerdings keine komplett falsche Idee.
MySQL Version 4.0.23_Debian-7
Php Version 4.3.10,
Ein uraltes MySQL, ein uraltes PHP. Nicht mal innerhalb der 4er-Serie auf 4.4 aktualisiert. Grausam! Diese Uralt-Software wird über kurz oder lang unwartbar werden.
Ein Update möchte ich nicht weil ich nicht weis ob dann noch alles läuft!
Ich verkneife mir den Kommentar mal, trotz der guten Vorlage.
Es ist doch nichts einfacher, als das: Neuen Server installieren, aktuelle Softwarekomponenten drauf, und die Backups von Datenbank und Skripten dort installieren und gucken, ob alles funktioniert. Falls nicht: Reparieren und so ändern, dass es funktioniert.
Wenn es an einem fertig installierbaren Backup mangelt: Gute Nacht! Dann wird's höchste Zeit, sich drum zu kümmern - denn ein gut ausgelasteter Server wird ja wohl nicht zum Spaß betrieben, sondern weil er Geld verdienen soll.
Ich habe einen managed Server weil ich kein Linux Mensch bin.
Der Server wird aber nicht gemanaged! Sonst wäre dort keine uralte PHP-4.3-Version drauf, sondern mindestens PHP 4.4.4, und ebenfalls kein uraltes MySQL 4.0, sondern mindestens 4.1, eher 5.0.
- Sven Rautenberg