Server Systemauslastung Normalwerte

[Simone]

Hi,

Wie sind die "Normalwerte" für eine Serverauslastung?

cat /proc/loadavg
sagt bei mir
"10.46 10.38 10.54 6/135 27146"

Hintergrund ist eine Steigerung massiver http Seitenzugriffe. Ich habe keine Idee mehr, wie ich den Server noch stabil halten kann.

cut -d. -f1 /proc/uptime
This server has been up 15 day(s) 5 hour(s) 44 minute(s) and 55 second(s)

Angaben zum Server

4.3.10,
12.22 Distrib 4.0.23,
Apache/2.0.52,
i686,Linux,,2,
Intel(R) Pentium(R) D CPU 3.00GHz,
2250.000,
2048,
KB,
GenuineIntel

top - 19:36:44 up 15 days,  5:59,  2 users,  load average: 14.21, 12.20, 11.31
Tasks: 123 total,  13 running, 110 sleeping,   0 stopped,   0 zombie
 Cpu0 : 62.5% us, 37.5% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
 Cpu1 : 83.8% us, 16.2% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   2065372k total,  1276604k used,   788768k free,   119388k buffers
Swap:  1967952k total,    55576k used,  1912376k free,   532976k cached

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
29820 nobody    15   0  144m  10m 7124 S  0.0  0.5   0:04.70  0 /usr/sbin/httpd -k restart
usw...

Die Abfragen vom Mysql sind schon optimiert worden

+-------+-----------+-----------+-----------+-------+-----+------+-------------------+
| 17132 | db8489143 | localhost | db8489143 | Sleep | 284 |      |              NULL |
| 18160 | db1102289 | localhost | db1102289 | Sleep |   4 |      |              NULL |
| 18168 | db1102289 | localhost | db1102289 | Sleep |   3 |      |              NULL |
| 18170 | db6006779 | localhost | db6006779 | Sleep |   2 |      |              NULL |
| 18172 | db8613533 | localhost | db8613533 | Sleep |   1 |      |              NULL |
| 18173 | root      | localhost | NULL      | Query |   0 | NULL | SHOW  PROCESSLIST |
| 18174 | db9608358 | localhost | db9608358 | Sleep |   1 |      |              NULL |
| 18175 | db1824927 | localhost | db1824927 | Sleep |   1 |      |              NULL |
+-------+-----------+-----------+-----------+-------+-----+------+-------------------+

Gibt es eine pauschale Möglichkeit die Maximale Auslastung eines Webservers zu bestimmen?

Nachdem der Server fest steht hilft mir nur noch
killall -9 httpd
bzw. apachectl restart , mysql

Grüße Simone

[Alexander (HH)]

Moin Moin!

Wie sind die "Normalwerte" für eine Serverauslastung?

cat /proc/loadavg
sagt bei mir
"10.46 10.38 10.54 6/135 27146"

Die ersten drei Zahlen sollten deutlich niedriger sein.

Hintergrund ist eine Steigerung massiver http Seitenzugriffe.

Angriff?

Dann blockiere die Angriffe vor dem Webserver, sofern sie von einem bestimmten IP-Range (oder einigen wenigen) kommen.

Ich habe keine Idee mehr, wie ich den Server noch stabil halten kann.

Bring die Anwendung dazu, Angriffe möglichst schnell zu erkennen und möglichst früh abzuwürgen.

Oder läuft Deine Anwendung von sich aus Amok? (Endlos-Schleife?)

Alexander

[Simone]

HI, Alexander

Angriff?

Nein es sind Nutzer meiner Seiten....

Ich habe ca. 20 000 Besucher am Tag auf diesen Server mit allen Domains

Auszug eine Domain:
12.102 Personen besuchten diese Website.
13.435 Besuche
12.102 Absolut eindeutige Besucher
76.625 Seitenzugriffe
5,70 Durchschnittliche Anzahl an Seitenzugriffen
00:05:14 Besuchszeit auf der Website
48,22 % Absprungrate
75,47 % Neue Besuche

Bring die Anwendung dazu, Angriffe möglichst schnell zu erkennen und möglichst früh abzuwürgen.

Ja, das mache ich schon! Im Shared Memory Bereich schreibe ich Seitenzugriffe mit... usw.

Oder läuft Deine Anwendung von sich aus Amok? (Endlos-Schleife?)

Nein es sind http bzw. Mysql Zugriffe die den Server zum erliegen bringen

Simone

[Alexander (HH)]

Moin Moin!

HI, Alexander

Angriff?

Nein es sind Nutzer meiner Seiten....

Wie viele Domains gibt es insgesamt auf der Maschine? Exklusive Maschine oder shared?

76.625 Seitenzugriffe

am Tag?

Das sollte einen Webserver völlig kalt lassen. Das ist noch nicht einmal einer pro Sekunde.

Ja, das mache ich schon! Im Shared Memory Bereich schreibe ich Seitenzugriffe mit... usw.

Machst Du Dir bzw. dem Server da zu viel Arbeit?

Nein es sind http bzw. Mysql Zugriffe die den Server zum erliegen bringen

Finde den Bottleneck.

Hast Du passende Indices in der DB angelegt?

Werden statische Resourcen schnell ausgeliefert? Dann ist der Apache aus der Nummer raus, und das Problem ist deine Anwendung.

Nutzt Du Caching-Funktionen in Deiner Anwendung? Cachst Du die Sachen, die lange dauern, oder was Dir gerade einfiel? Übertreibst Du es mit dem Caching?

Was außer Apache und MySQL benutzt Du? PHP, Perl, Ruby, Java? Frameworks?

Alexander

[Simone]

HI,Alexander
 Wie viele Domains gibt es insgesamt auf der Maschine? Exklusive Maschine oder shared?

Insgesamt ca. 12 Domains auf Miet-Server Ich bin allein auf der Maschine ;o)

412,749 GB Traffic 12/2008

Das sollte einen Webserver völlig kalt lassen. Das ist noch nicht einmal einer pro Sekunde.

Naja, die Probleme haben mit der Steigerung der Besucherzahlen erst angefangen. Ca. 3 Jahre ging auch alles super..

Ja, das mache ich schon! Im Shared Memory Bereich schreibe ich Seitenzugriffe mit... usw.

Machst Du Dir bzw. dem Server da zu viel Arbeit?

... denke nicht das Segment ist nicht Groß

Finde den Bottleneck.

JA ABER WO??? Oder besser gesagt wie??

Der Server läuft immer im Roten Bereich sobald User auf meine Seiten kommen.

Hast Du passende Indices in der DB angelegt? Ich denke schon. Die Prozessliste sieht gut aus.

Mysql liegt bei 65% von der CPU.
Speicherfresser (Counter usw.) habe ich vernichtet.
Ich dachte erst das es daran liegt.

Werden statische Resourcen schnell ausgeliefert? Dann ist der Apache aus der Nummer raus, und das Problem ist deine Anwendung.

Evtl. kann es an mod_rewrite liegen. PHP > *.html

Nutzt Du Caching-Funktionen in Deiner Anwendung? Cachst Du die Sachen, die lange dauern, oder was Dir gerade einfiel? Übertreibst Du es mit dem Caching?

Ja! ca. 24 Stunden als *.zip File. Mysql Cache ist on. Hauptdatenbänke im Cache ohne upload und co.

Was außer Apache und MySQL benutzt Du?
PHP

Simone

[Alexander (HH)]

Moin Moin!

Das sollte einen Webserver völlig kalt lassen. Das ist noch nicht einmal einer pro Sekunde.

Naja, die Probleme haben mit der Steigerung der Besucherzahlen erst angefangen. Ca. 3 Jahre ging auch alles super..

Das spricht für eine organisch gewachsene Anwendung ("Krebsgeschwür"), die jetzt plötzlich attraktiv geworden ist.

Du brauchst jemanden, der sich WIRKLICH damit auskennt.

Ja, das mache ich schon! Im Shared Memory Bereich schreibe ich Seitenzugriffe mit... usw.

Machst Du Dir bzw. dem Server da zu viel Arbeit?

... denke nicht das Segment ist nicht Groß

Es geht nicht um Größe, es geht um Geschwindigkeit. Wenn Deine Anwendung 80% der Zeit mit dem Shared Memory rumfummelt, obwohl es nur 10KByte groß ist, ist es Dein Problem.

Finde den Bottleneck.

JA ABER WO??? Oder besser gesagt wie??

Messen, messen, messen, und nochmal messen.

Der Server läuft immer im Roten Bereich sobald User auf meine Seiten kommen.

Dann schmeiß die User raus! ;-)

Hast Du passende Indices in der DB angelegt? Ich denke schon.

Hast Du oder hast Du nicht? Nicht raten, prüfen!

Die Prozessliste sieht gut aus.

Das ist der falsche Meßwert. Die Prozessliste zeigt Dir bestenfalls kumulierte Symptome.

Hast Du je eine Liste der am häufigsten und am längsten laufenden SQL-Queries? Wenn nein, warum nicht?

Hast Du überprüft, auf welchen Spalten und Spaltenkombinationen die Queries laufen? Und das für diese schweren Fälle passende Indices vorhanden sind?

Mysql liegt bei 65% von der CPU.

Das bestätigt meine Vorurteile. ;-)
Ich halte das für wesentlich zu viel.

Speicherfresser (Counter usw.) habe ich vernichtet.
Ich dachte erst das es daran liegt.

Definitiv nicht. Deine Load ist um 500% bis 1000% zu hoch, weil zu viele Prozesse gleichzeitig laufen müssen, was darauf zurückzuführen ist, dass Du die Requests nicht SCHNELL genug abarbeitst.

Werden statische Resourcen schnell ausgeliefert? Dann ist der Apache aus der Nummer raus, und das Problem ist deine Anwendung.

Evtl. kann es an mod_rewrite liegen. PHP > *.html

Nichr raten, messen, messen, messen.

Je komplexer deine Rewrite Rules sind, desto mehr Zeit muß der Apache dort verbrennen. Wenn Du nur ein oder zwei einfache Regeln hast, ist es nicht mod_rewrite.

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.

Nutzt Du Caching-Funktionen in Deiner Anwendung? Cachst Du die Sachen, die lange dauern, oder was Dir gerade einfiel? Übertreibst Du es mit dem Caching?

Ja! ca. 24 Stunden als *.zip File. Mysql Cache ist on. Hauptdatenbänke im Cache ohne upload und co.

Du hast keine Ahnung, wovon ich rede, oder?

Wenn Du 20x eine Liste aller Uploads eines Users brauchst, machst Du dann 20x "SELECT FROM UPLOADS WHERE userid=x"? Oder machst Du den SELECT nur beim ersten Mal und merkst Dir das Ergebnis für die nächsten 19 Mal?

Was außer Apache und MySQL benutzt Du?
PHP

Version? Libraries? Frameworks?

Noch eine Überlegung:

(D)ein Webserver hat genau dann alle Hände voll zu tun, wenn ein Request kommt: Request verarbeiten, PHP-Interpreter starten, PHP Interpretieren, Datenbank-Abfragen machen, Ergebnis ausrechnen, Ergebnis zurückschreiben, Logs schreiben. Und all das passiert, grob betrachtet, gleichzeitig. In dem Moment, in dem Deine Anwendung die CPU braucht, will auch die DB reichlich CPU haben. Und um RAM und Festplatte streiten sich auch beide.

Daraus folgt: Du könntest die Datenbank auf eine separate Maschine packen, so dass sich DB und Applikation bei CPU, RAM und HDD nicht gegenseitig im Weg stehen. Dann wird allerdings die Netzwerkverbindung u.U. ein Bottleneck. Ein Patch-Kabel direkt zwischen den Servern wäre optimal, aber eine gewitchte Umgebung tut's meistens auch. Je schneller das Netzwerk ist, um so besser. 100 MBit/s sollten es schon sein, 1 GByte/s wäre schöner. Und die Absicherung wird natürlich extrem wichtig. Ein dediziertes Kabel zwischen Web- und DB-Server mit IP-Adressen aus dem privaten bereich (z.B. 192.168.42.1 und 192.168.42.2) wäre optimal und absolut dicht, wenn Du auf einen zweiten Mietserver gehst, muß die DB sich selbst schützen, damit nur der Webserver Zugriff hat.

Es gibt natürlich auch andere Optimierungsmöglichkeiten: Es wäre blöd, den PHP-Code Deiner Anwendung für jeden Request komplett neu zu parsen und zu interpretieren, obwohl sich der Code nicht ändert. Deswegen gibt es gerade für PHP einiges an Software, um PHP zu beschleunigen, in der Regel dadurch, dass ein permanent laufender Prozess den Code einmal einliest und den geparsten Code im Speicher hält, um so pro Request das Parsen einzusparen. Google ist Dein Freund, http://en.wikipedia.org/wiki/PHP_accelerator ist ein brauchbarer Anfang.

Und dann bleibt natürlich noch Deine Anwendung. Überlege, was Du jedes Mal neu berechnen mußt und was Du vorberechnen kannst. Vermeide, ALLE Resourcen per PHP auszuliefern. Dateien auf dem Webserver durch PHP zu schleusen ist in den meisten Fällen unsinnig. Javascripte und Stylesheets sowie die meisten (alle) Bilder kann der Webserver ohne PHP wesentlich schneller ausliefern. Passen Deine Datenformate zu Deiner Anwendung? Wenn Du für jeden Request erst einmal ein 20 MByte großes XML-File durchkauen mußt, hast Du Deine Daten falsch abgelegt. Berechnet Deine Anwendung irgendwelche Sachen auf Verdacht bzw. auf Vorrat? Raus damit, wenn die Berechnung in den meisten Fällen nicht benötigt wird.

Alexander

[simone]

HI, Alexander

Das spricht für eine organisch gewachsene Anwendung ("Krebsgeschwür"), die jetzt plötzlich attraktiv geworden ist.

So plötzlich ist es nicht gewachsen. Google mag meine Inhalte...

Du brauchst jemanden, der sich WIRKLICH damit auskennt.

Hab keinen ;O) und mit Linux kenne ich mich nur oberflächlich aus.

Es geht nicht um Größe, es geht um Geschwindigkeit. Wenn Deine Anwendung 80% der Zeit mit dem Shared Memory rumfummelt, obwohl es nur 10KByte groß ist, ist es Dein Problem.

1 mal lesen + 1 mal schreiben pro Zugriff im Ram das sollte den Server nicht plattmachen.

Finde den Bottleneck.

JA ABER WO??? Oder besser gesagt wie??

Messen, messen, messen, und nochmal messen.

Kannst Du mir bitte sagen wie! Programme die sowas unter Linux das machen sind mir nicht bekannt.

Hast Du passende Indices in der DB angelegt? Ich denke schon.

Hast Du oder hast Du nicht? Nicht raten, prüfen!

Die Prozessliste sieht gut aus.

Das ist der falsche Meßwert. Die Prozessliste zeigt Dir bestenfalls kumulierte Symptome.

Hast Du je eine Liste der am häufigsten und am längsten laufenden SQL-Queries? Wenn nein, warum nicht?

Nein, das habe ich mir auch schon überlegt. Gibt es zum Auswerten der Mysql Querie logs Programme. Bzw. wiekann ich das bewerkstelligen?

Hast Du überprüft, auf welchen Spalten und Spaltenkombinationen die Queries laufen? Und das für diese schweren Fälle passende Indices vorhanden sind?

Zumindest das was mir bekannt ist Explain Select .......... usw.

Mysql liegt bei 65% von der CPU.

Das bestätigt meine Vorurteile. ;-) Ich halte das für wesentlich zu viel.

Meine Vermutung ist auch das es an Mysql liegen kann. Mir fehlen einfach Vergleichswerte.

Laufzeit-Informationen Dieser MySQL-Server läuft bereits 0 Tage, 14 Stunden, 14 Minuten und 15 Sekunden. Er wurde am 12. Januar 2009 um 20:49 gestartet.

Abfragestatistik: Seit seinem Start wurden 1.608.278 Abfragen an diesen MySQL-Server gesandt.  Insgesamt   ø pro Stunde   ø pro Minute   ø pro Sekunde  1.608.278   112.960,70       1.882,68      31,38

Abfrageart   ø pro Stunde   %  admin commands   186   13,06   0,01 %  alter table   0   0,00   0,00 %  analyze   0   0,00   0,00 %  backup table   0   0,00   0,00 %  begin   0   0,00   0,00 %  change db   155.905   10.950,31   10,69 %  change master   0   0,00   0,00 %  check   470   33,01   0,03 %  commit   0   0,00   0,00 %  create db   0   0,00   0,00 %  create function   0   0,00   0,00 %  create index   0   0,00   0,00 %  create table   0   0,00   0,00 %  delete   69.747   4.898,82   4,78 %  delete multi   0   0,00   0,00 %  drop db   0   0,00   0,00 %  drop function   0   0,00   0,00 %  drop index   0   0,00   0,00 %  drop table   0   0,00   0,00 %  flush   0   0,00   0,00 %  grant   0   0,00   0,00 %  ha close   0   0,00   0,00 %  ha open   0   0,00   0,00 %  ha read   0   0,00   0,00 %  insert   356.186   25.017,45   24,43 %  insert select   0   0,00   0,00 %  kill   0   0,00   0,00 %  load   0   0,00   0,00 %  load master data   0   0,00   0,00 %  load master table   0   0,00   0,00 %  lock tables   0   0,00   0,00 %  optimize   20.824   1.462,62   1,43 %  purge   0   0,00   0,00 %  rename table   0   0,00   0,00 %   Abfrageart   ø pro Stunde   %  repair   0   0,00   0,00 %  replace   0   0,00   0,00 %  replace select   0   0,00   0,00 %  reset   0   0,00   0,00 %  restore table   0   0,00   0,00 %  revoke   0   0,00   0,00 %  rollback   0   0,00   0,00 %  savepoint   0   0,00   0,00 %  select   398.842   28.013,49   27,35 %  set option   0   0,00   0,00 %  show binlog events   0   0,00   0,00 %  show binlogs   2   0,14   0,00 %  show create   0   0,00   0,00 %  show databases   4   0,28   0,00 %  show fields   0   0,00   0,00 %  show grants   0   0,00   0,00 %  show keys   0   0,00   0,00 %  show logs   0   0,00   0,00 %  show master status   0   0,00   0,00 %  show new master   0   0,00   0,00 %  show open tables   0   0,00   0,00 %  show processlist   1   0,07   0,00 %  show slave hosts   0   0,00   0,00 %  show slave status   0   0,00   0,00 %  show status   3   0,21   0,00 %  show innodb status   0   0,00   0,00 %  show tables   60   4,21   0,00 %  show variables   1   0,07   0,00 %  slave start   0   0,00   0,00 %  slave stop   0   0,00   0,00 %  truncate   0   0,00   0,00 %  unlock tables   0   0,00   0,00 %  update   109.894   7.718,63   7,54 %

Weitere Statusvariablen  Variable   Wert  Created tmp disk tables   99375  Created tmp tables   129594  Created tmp files   9  Delayed insert threads   0  Delayed writes   0  Delayed errors   0  Flush commands   1  Handler commit   0  Handler delete   1550  Handler read first   2543  Handler read key   1978625  Handler read next   635034987  Handler read prev   71805  Handler read rnd   4532770  Handler read rnd next   2701195363  Handler rollback   0  Handler update   437814  Handler write   3654345495  Key blocks used   124690  Key read requests   529305367   Variable   Wert  Key reads   244033  Key write requests   297290  Key writes   202698  Max used connections   46  Not flushed key blocks   0  Not flushed delayed rows   0  Open tables   541  Open files   1006  Open streams   0  Opened tables   548  Qcache queries in cache   46987  Qcache inserts   244529  Qcache hits   347917  Qcache lowmem prunes   117797  Qcache not cached   145059  Qcache free memory   30957920  Qcache free blocks   9253  Qcache total blocks   107411  Rpl status   NULL   Variable   Wert  Select full join   289  Select full range join   0  Select range   127462  Select range check   0  Select scan   132134  Slave open temp tables   0  Slave running   OFF  Slow launch threads   0  Slow queries   184  Sort merge passes   3  Sort range   117899  Sort rows   4594592  Sort scan   147808  Table locks immediate   607781  Table locks waited   2376  Threads cached   17  Threads created   95  Threads connected   9  Threads running   6

Speicherfresser (Counter usw.) habe ich vernichtet. Ich dachte erst das es daran liegt.

Definitiv nicht. Deine Load ist um 500% bis 1000% zu hoch, weil zu viele Prozesse gleichzeitig laufen müssen, was darauf zurückzuführen ist, dass Du die Requests nicht SCHNELL genug abarbeitst.

Werden statische Resourcen schnell ausgeliefert? Dann ist der Apache aus der Nummer raus, und das Problem ist deine Anwendung.

Evtl. kann es an mod_rewrite liegen. PHP > *.html

Nichr raten, messen, messen, messen.

Ja womit und wie?

Je komplexer deine Rewrite Rules sind, desto mehr Zeit muß der Apache dort verbrennen. Wenn Du nur ein oder zwei einfache Regeln hast, ist es nicht mod_rewrite.

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

Nutzt Du Caching-Funktionen in Deiner Anwendung? Cachst Du die Sachen, die lange dauern, oder was Dir gerade einfiel? Übertreibst Du es mit dem Caching?

Ja! ca. 24 Stunden als *.zip File. Mysql Cache ist on. Hauptdatenbänke im Cache ohne upload und co.

Du hast keine Ahnung, wovon ich rede, oder?

Kann schon sein. 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.

Wenn Du 20x eine Liste aller Uploads eines Users brauchst, machst Du dann 20x "SELECT FROM UPLOADS WHERE userid=x"? Oder machst Du den SELECT nur beim ersten Mal und merkst Dir das Ergebnis für die nächsten 19 Mal?

Das macht der Mysql Cache

Was außer Apache und MySQL benutzt Du? PHP

Version? Libraries? Frameworks?

Da habe ich keine Ahnung was Du meinst. Ich nutze so gut wie keine fertigen Programme.

MySQL Version 4.0.23_Debian-7 Php Version  4.3.10,

Ein Update möchte ich nicht weil ich nicht weis ob dann noch alles läuft!

Noch eine Überlegung:

(D)ein Webserver hat genau dann alle Hände voll zu tun, wenn ein Request kommt: Request verarbeiten, PHP-Interpreter starten, PHP Interpretieren, Datenbank-Abfragen machen, Ergebnis ausrechnen, Ergebnis zurückschreiben, Logs schreiben. Und all das passiert, grob betrachtet, gleichzeitig. In dem Moment, in dem Deine Anwendung die CPU braucht, will auch die DB reichlich CPU haben. Und um RAM und Festplatte streiten sich auch beide.

Daraus folgt: Du könntest die Datenbank auf eine separate Maschine packen, so dass sich DB und Applikation bei CPU, RAM und HDD nicht gegenseitig im Weg stehen. Dann wird allerdings die Netzwerkverbindung u.U. ein Bottleneck.

Ich habe einen managed Server weil ich kein Linux Mensch bin.

Ein Patch-Kabel direkt zwischen den Servern wäre optimal, aber eine gewitchte Umgebung tut's meistens auch. Je schneller das Netzwerk ist, um so besser. 100 MBit/s sollten es schon sein, 1 GByte/s wäre schöner. Und die Absicherung wird natürlich extrem wichtig. Ein dediziertes Kabel zwischen Web- und DB-Server mit IP-Adressen aus dem privaten bereich (z.B. 192.168.42.1 und 192.168.42.2) wäre optimal und absolut dicht, wenn Du auf einen zweiten Mietserver gehst, muß die DB sich selbst schützen, damit nur der Webserver Zugriff hat.

Es gibt natürlich auch andere Optimierungsmöglichkeiten: Es wäre blöd, den PHP-Code Deiner Anwendung für jeden Request komplett neu zu parsen und zu interpretieren, obwohl sich der Code nicht ändert. Deswegen gibt es gerade für PHP einiges an Software, um PHP zu beschleunigen, in der Regel dadurch, dass ein permanent laufender Prozess den Code einmal einliest und den geparsten Code im Speicher hält, um so pro Request das Parsen einzusparen. Google ist Dein Freund, http://en.wikipedia.org/wiki/PHP_accelerator ist ein brauchbarer Anfang.

»» Habe ich mir mal vor längerer Zeit angesehen. Aber irgendwie sind damals nur die kostenpflichtigen Versionen stabil gewesen.

Und dann bleibt natürlich noch Deine Anwendung. Überlege, was Du jedes Mal neu berechnen mußt und was Du vorberechnen kannst. Vermeide, ALLE Resourcen per PHP auszuliefern. Dateien auf dem Webserver durch PHP zu schleusen ist in den meisten Fällen unsinnig. Javascripte und Stylesheets sowie die meisten (alle) Bilder kann der Webserver ohne PHP wesentlich schneller ausliefern.

Passen Deine Datenformate zu Deiner Anwendung? Wenn Du für jeden Request erst einmal ein 20 MByte großes XML-File durchkauen mußt, hast Du Deine Daten falsch abgelegt. Berechnet Deine Anwendung irgendwelche Sachen auf Verdacht bzw. auf Vorrat? Raus damit, wenn die Berechnung in den meisten Fällen nicht benötigt wird.

Das ist nicht soeinfach umzusetzen. Bei den Anwendungen kann kein reines  Filesystem aus statischen Seiten Anwendung finden.

Danke für Deine Ausführungen.

Und nochmals eine Frage welche Programme / Befehle eignen sich unter Linux / Php zum finden von Laufzeitintensiven Prozessen.

Also eine Auswertung / Überwachung von:

top

1546 nobody    16   0  143m 4912 3540 R 19.1  0.2   0:00.50  0 /usr/sbin/httpd -k restart

Simone

[Alexander (HH)]

Moin Moin!

Du brauchst jemanden, der sich WIRKLICH damit auskennt.

Hab keinen ;O) und mit Linux kenne ich mich nur oberflächlich aus.

Du hast einen Managed Server. Greif Dir den Manager und laß den seinen Job machen. Und wenn der keinen Plan hat, sollte er wenigstens jemanden kennen, der Dir weiterhelfen kann -- notfalls gegen Geld. Oder jemand aus dem Forum. Hier gibt es ein paar Leute, die gegen Geld genau das machen, was Du brauchst -- eine gründliche Analyse Deiner Anwendung.

Es geht nicht um Größe, es geht um Geschwindigkeit. Wenn Deine Anwendung 80% der Zeit mit dem Shared Memory rumfummelt, obwohl es nur 10KByte groß ist, ist es Dein Problem.

1 mal lesen + 1 mal schreiben pro Zugriff im Ram das sollte den Server nicht plattmachen.

Es wird vermutlich nicht bei einem Zugriff bleiben.

Finde den Bottleneck.

JA ABER WO??? Oder besser gesagt wie??

Messen, messen, messen, und nochmal messen.

Kannst Du mir bitte sagen wie! Programme die sowas unter Linux das machen sind mir nicht bekannt.

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.

Also brauchst Du keine großartigen Linux-Kenntnisse, um herauszufinden, was so lange dauert. Nehmen wir mal an, Deine Anwendung würde aus folgendem (Pseudo-)Code bestehen:

function main(request) {   var config=read_config();   var db=connect_db_cached(config->db);   var data=validate_input(request);   var output=calculate_output(db,data,config)   var html=fill_template(output);   return html; }

Wie bekommst Du jetzt raus, wo es klemmt? Natürlich mit dem guten alten printf-Debugger, sprich: Du fügst Diagnose-Ausgaben ein. Damit das einfacher geht, baust Du Dir erstmal einen kleinen Helfer:

function log_debug(msg) {   var now=hires_time_string();   printf(stderr,"%s: %s\n",now,msg); }

Und den rufst Du dann vor und nach kritischen Bereichen auf und berechnest anschließend aus dem generierten Log die Laufzeiten der jeweiligen Funktionen:

function main(request) {   log_debug('anfang');   var config=read_config();   log_debug('config gelesen');   var db=connect_db_cached(config->db);   log_debug('db connected');   var data=validate_input(request);   log_debug('input validated');   var output=calculate_output(db,data,config)   log_debug('output calculated');   var html=fill_template(output);   log_debug('html generated');   return html; }

Das ergibt dann ungefähr so eine Ausgabe:

Tue Jan 13 17:00:42.123 2008 anfang Tue Jan 13 17:00:42.227 2008 config gelesen Tue Jan 13 17:00:45.875 2008 db connected Tue Jan 13 17:00:45.925 2008 input validated Tue Jan 13 17:01:58.456 2008 output calculated Tue Jan 13 17:01:59.001 2008 html generated

In diesem Beispiel fällt auf, das connect_db_cached() und calculate_output() extrem langsam sind (3,5 bzw. 12,5 Sekunden), während der Rest in Sekundenbruchteilen durchläuft.

Also baust Du die log_debug-Aufrufe entsprechend in connect_db_cached() und calculate_output() ein, die anderen Aufrufe in main() bleiben erstmal drin! Das wiederholst Du notfalls so lange, bis Du an eingebauten Funktionen von PHP ankommst.

Irgendwann hast Du die kritischen Stellen eingekreist und kannst dort dir Geschwindigkeit optimieren. Das kann in diesem Beispiel z.B. ein SELECT mit mehreren JOINs und WHERE über nicht indizierte Spalten sein, das auch noch größere Datenmengen aus der DB in die Anwendung schaufelt.

Hast Du je eine Liste der am häufigsten und am längsten laufenden SQL-Queries? Wenn nein, warum nicht?

Nein, das habe ich mir auch schon überlegt. Gibt es zum Auswerten der Mysql Querie logs Programme. Bzw. wiekann ich das bewerkstelligen?

Das sollte im MySQL-Handbuch stehen. MySQL ist zwar IMHO eine katastrophale Datenbank, aber wenigstens ist fast alles dokumentiert.

Im dümmsten Fall ersetzt Du die Funktion, die ein SQL-Statement an die DB überreicht, durch eine eigene Funktion, die die SQL-Statements loggt.

function prepare_sql_debug(db,command) {   log_debug(command);   return prepare_sql(db,command); }

Hast Du überprüft, auf welchen Spalten und Spaltenkombinationen die Queries laufen? Und das für diese schweren Fälle passende Indices vorhanden sind?

Zumindest das was mir bekannt ist Explain Select .......... usw.

Und passen die Indices zu den Queries?

MySQL sollte bei explain select eigentlich einen abstrakten Kostenfaktor ausgeben, den Du möglichst klein halten solltest. (Oops, nee, tut MySQL natürlich NICHT!)

Meine Vermutung ist auch das es an Mysql liegen kann.

MySQL ist zwar s..., aber nicht so s..., dass es sich auf Kosten der CPU nur mit sich selbst beschäftigt. MySQL sollte im Leerlauf keine CPU brauchen, die CPU-Last kommt dann "nur" von Deinen SQL-Statements und Deiner DB-Struktur. Es liegt also sehr wahrscheinlich an Deinem SQL in Kombination mit Deiner DB-Struktur.

Mir fehlen einfach Vergleichswerte.

Brauchst Du nicht unbedingt. Die gängigen Daumenwerte sagen, dass Du eine Seite innerhalb von 2 bis 3 Sekunden vollstädig ausgeliefert haben solltest. Und eine load averge von mehr als 100% pro CPU ist für ein Unix-System auch nicht gut, sprich: Ein Single-Core-Prozessor sollte mit der Load deutlich unter 100% bleiben, ein Dual-Core-Prozessor bzw. zwei einzelne CPUs sollten insgesamt nicht über 200% load average gehen.

Laufzeit-Informationen Dieser MySQL-Server läuft bereits 0 Tage, 14 Stunden, 14 Minuten und 15 Sekunden. Er wurde am 12. Januar 2009 um 20:49 gestartet.

Abfragestatistik: Seit seinem Start wurden 1.608.278 Abfragen an diesen MySQL-Server gesandt. Insgesamt   ø pro Stunde   ø pro Minute   ø pro Sekunde 1.608.278   112.960,70       1.882,68      31,38

30 Abfragen pro Sekunde, mit einer Nacht dazwischen? Deine Anwendung ist sehr DB-intensiv. Versuche, daran zu drehen.

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 %

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.

Über 14 Stunden ist das natürlich eine sehr wackelige Statistik.

Weitere Statusvariablen Variable   Wert Created tmp disk tables   99375 Created tmp tables   129594

Warum so viele temporäre Tabellen?

Ist Dein DB-Schema kaputt? Nicht normalisiert?

Open tables   541

Über 500 offene(!) Tabellen? Was machst Du mit so einem riesigen DB-Schema?

Nichr raten, messen, messen, messen.

Ja womit und wie?

Siehe oben.

Wie lange ein HTTP-Request dauert, kannst Du u.a. mit firebug herausfinden.

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.

Caching?

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 RIESIGE 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.

Wenn Du 20x eine Liste aller Uploads eines Users brauchst, machst Du dann 20x "SELECT FROM UPLOADS WHERE userid=x"? Oder machst Du den SELECT nur beim ersten Mal und merkst Dir das Ergebnis für die nächsten 19 Mal?

Das macht der Mysql Cache

Das ist die falsche Stelle! MySQL muß Dein SQL-Statement 20x parsen, 20x seinen Cache prüfen, und 20x Daten ausliefern, die Du schon in der Anwendung hast. Und im schlimmsten Fall baust Du 20x eine TCP-Verbindung zu MySQL auf, um jeweils das selbe Statement ausführen zu lassen, inklusive DNS-Abfrage für localhost. Frag die DB nur einmal pro Request nach Daten, die sich innerhalb eines Requests sehr wahrscheinlich nicht ändern. Und benutze die Verbindung zu MySQL mehr als einmal, möglichst für den gesamten Request.

Packe die SQL-Statements in Funktionen, die bevorzugt das jeweils letzte Ergebnis zurückliefern, statt die DB zu befragen.

memcached könnte da hilfreich sein.

PHP Version? Libraries? Frameworks?

Da habe ich keine Ahnung was Du meinst. Ich nutze so gut wie keine fertigen Programme.

MySQL Version 4.0.23_Debian-7 Php Version  4.3.10,

Beides nicht mehr so ganz frisch. Debian macht zwar Backports von Bugfixes, aber PHP 4 ist TOT. (Müffelte ja auch schon eine ganze Weile recht unappetitlich.)

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.

Ich habe einen managed Server weil ich kein Linux Mensch bin.

Du solltest aber in der Lage sein, mit deinen Werkzeugen zu arbeiten. Wenn Du es nicht kannst, lerne es.

Google ist Dein Freund, http://en.wikipedia.org/wiki/PHP_accelerator ist ein brauchbarer Anfang. »» Habe ich mir mal vor längerer Zeit angesehen. Aber irgendwie sind damals nur die kostenpflichtigen Versionen stabil gewesen.

You get what you paid for. Entweder setzt Du Dich mal ein paar Tage hin und suchst die unperformanten Stellen, oder Du nimmst Geld in die Hand und hoffst, das diese Software schnell genug ist, um Deine Fehler auszubügeln.

Vermeide, ALLE Resourcen per PHP auszuliefern. Das ist nicht soeinfach umzusetzen. Bei den Anwendungen kann kein reines  Filesystem aus statischen Seiten Anwendung finden.

Erzähl mir was neues. Ich baue seit 10 Jahren Web-Anwendungen und verdiene damit mein Geld. Aber statische Resourcen nur um der URL willen durch PHP zu prügeln ist schlicht und ergreifend dämliche CPU-Quälerei.

Und nochmals eine Frage welche Programme / Befehle eignen sich unter Linux / Php zum finden von Laufzeitintensiven Prozessen.

Die graue Pampe zwischen Deinen Ohren.

Also eine Auswertung / Überwachung von:

top

1546 nobody    16   0  143m 4912 3540 R 19.1  0.2   0:00.50  0 /usr/sbin/httpd -k restart

Das ist viel zu grob, damit siehst Du nur von außen auf den Webserver. Du mußt das innere der Anwendung betrachten.

Alexander

[Simone]

HI, Alexander

Ich bedanke mich für Deine Antworten.

Deine Ausführungen muss ich mir in Ruhe nochmal durchlesen.

Eigentlich teste ich meine Anwendungen immer auf ein Uralt Linux Server und wenn es dort läuft gehts erst bzw. auch online.

Ich habe heute erst einmal eine query Logfile für Mysql angelegt und konnte schon einige Sachen optimieren. Ich denke es liegt wirklich am Mysql.

long_query_time = 5  <- ist dieser Wert ist ok ?
log_slow_queries

1.)
SELECT SQL_NO_CACHE * FROM db WHERE  Ausdruck  AND  Ausdruck
AND Ausdruck

2.)
SELECT SQL_NO_CACHE * FROM db WHERE  Ausdruck  AND  Ausdruck
HAVING Ausdruck

1. ist erstaunlicher weise langsammer als 2.)
obwohl die Spaltenanzahl des Index bei gleicher Abfrage größer ist.

Simone

[Alexander (HH)]

Moin Moin!

Eigentlich teste ich meine Anwendungen immer auf ein Uralt Linux Server und wenn es dort läuft gehts erst bzw. auch online.

Natürlich. Mit wie vielen Usern testest Du auf dem Testserver? Mit einem? Zwei?

Mit zwei Usern läuft mein aktueller Job auch locker auf einem 486er, ohne dass irgendetwas klemmt.

Laß mal 50 bis 200 (simulierte) User gleichzeitig auf deinen Testserver los und fang dann an, Deine Bottlenecks zu suchen. Und wenn das nicht reicht, leg noch 500 oder 1000 User nach.

long_query_time = 5  <- ist dieser Wert ist ok ?

Deine Frage ist sinngemäß gleich zu "Sind 100 PS gut?"

Für einen PKW mit knapp einer Tonne Leergewicht sind 100 PS mehr als gut (hehehe), für einen haushaltsüblichen Rasenmäher eher tödlicher Wahnsinn, für die Queen Mary II reichen 100 PS wahrscheinlich nichtmal als Anlasser. Und als EINZIGES Kaufkriterium für eines der drei Dinger sind "100 PS"  absolut ungeeignet.

Der Engländer pflegt in diesem Fall mit "it depends" zu antworten.

1.)
SELECT SQL_NO_CACHE * FROM db WHERE  Ausdruck  AND  Ausdruck
AND Ausdruck

2.)
SELECT SQL_NO_CACHE * FROM db WHERE  Ausdruck  AND  Ausdruck
HAVING Ausdruck

<ironie>Ich liebe MySQL.</ironie> Das sowas als SQL durchgeht, will mir nicht in den Kopf. Ich hab wohl zu lange mit Oracle und PostgreSQL gearbeitet.

1. ist erstaunlicher weise langsammer als 2.)
   obwohl die Spaltenanzahl des Index bei gleicher Abfrage größer ist.

Bei MySQL wundert mich gar nichts mehr. Vielleicht hat der Query Optimizer gemerkt, dass es cleverer ist, den HAVING-Ausdruck mit ins WHERE zu ziehen, und optimiert dann noch etwas weiter, was beim ersten Statement aus irgendwelchen Gründen (Tidestand in Emden, Luftfeuchtigkeit in Stockholm, Anzahl der in den letzten 10 Minuten umgefallenen Reissäcke, ...) nicht passiert.

Oder Du hast einfach MIST gemessen.

Wenn Du jedes Statement nur einmal laufen läßt, mißt Du auch die Startup-Zeiten (z.B. Tabelle von Platte ins RAM laden). Wenn die beiden Statements sich nur in HAVING vs. AND unterscheiden, und die Ausdrücke nicht zu kompliziert sind, dann hast Du bei der ersten Messung hauptsächlich die Startup-Zeiten gemessen, die vermutlich weit über der Execute-Zeit liegen. Deswegen ist das zweite Statement dann auch deutlich schneller, weil dann die Tabelle schon/noch im RAM liegt, da fällt das HAVING kaum ins Gewicht, sofern es der Optimizer nicht ohnehin ins WHERE gezogen hat.

Laß jedes einzelne Statement ein paar Mal (100 bis 1000) in einer Schleife laufen und vergleiche dann nochmal die Zeiten für die gesamte Schleife. Die Startup-Zeiten verteilen sich dann viel besser und fallen nicht mehr so ins Gewicht. Vergiß nicht, die Daten auch aus der DB zu lesen (und sei es nur, um sie gleich zu vergessen). Pseudocode:

var db=connect_db();
  var start=now();
  for (var i=0; i<1000; i++) {
    var sth=db->prepare('SELECT ...');
    sth->execute();
    while (sth->fetch()) {
      /* nix */
    }
    sth->finish();
  }
  var stop=now();
  printf("%f Sekunden\n",(stop-start)/1000.0);

Wahllos alle SQL-Statements auf diese Art zu testen ist allerdings Zeitverschwendung und schlimmstenfalls Optimierung für die Mülltonne, weil Du nur Statements optimierst, die kaum Einfluß auf die Geschwindigkeit oder CPU-Last haben. Finde (mit dem Printf-Debugger) die Stellen in Deiner Anwendung, die langsam sind. Optimiere dort zuerst, z.B. durch anwendungsinternes Caching, z.B. durch memcached, usw. Dazu habe ich bereits einiges geschrieben.

Und um noch eine Ungenauigkeit zu korrigieren:

Ich denke es liegt wirklich am Mysql.

Nein, definitiv nicht. MySQL ist zwar nicht gerade mein Lieblings-RDBMS (unterstelle ich gerade, MySQL sei ein RDBMS?), aber es ist enorm auf Geschwindigkeit getrimmt, besonders beim Lesen.

Das Problem ist das, was Du ins MySQL reinstopfst: Deine SQL-Abfragen, die unnötige Häufung von SQL-Abfragen, und vermutlich Dein Datenbank-Schema.

Mit einem kaputten DB-Schema kann man jeden Server in die Knie zwingen. Ich hab mal aus Versehen auf einem wirklich fetten Oracle-Server eine Tabelle ohne Index (genauer: ohne Primary Key) angelegt. Ergebnis: Die Anwendung hat ein einem primitiven SELECT ... WHERE column=value mehrere Minuten geknabbert, weil Oracle einen FULL TABLE SCAN machen mußte: Jede einzelne Tabellenzeile durchkauen. Bei ein paar Mio. Datensätzen dauert das schonmal etwas. Fehler behoben, Laufzeit im Bereich von Sekundenbruchteilen, Oracle weil seinen Index für diese Spalte nutzen konnte.

Von den Reports, die einige Ex-Kollegen über andere Datenbanken (bevorzugt Microsofts Karrikatur eines RDBMS) laufen lassen/ließen, will ich jetzt besser nicht anfangen. Nur so viel: Die Laufzeiten lagen im zwei- bis dreistelligen Minutenbereich ...

Alexander

[Vinzenz Mai]

Hallo,

MySQL Version 4.0.23_Debian-7
Php Version  4.3.10,

Beides nicht mehr so ganz frisch. Debian macht zwar Backports von Bugfixes, aber PHP 4 ist TOT. (Müffelte ja auch schon eine ganze Weile recht unappetitlich.)

MySQL 4.0 auch.

Ein Update möchte ich nicht weil ich nicht weis ob dann noch alles läuft!

Es wird mit Sicherheit nicht laufen :-) [1]
Dennoch empfehle ich den Umstieg. So schnell wie möglich.

Freundliche Grüße

Vinzenz

[1] Murphys Gesetz

[Alexander (HH)]

Moin Moin!

Dennoch empfehle ich den Umstieg. So schnell wie möglich.

Dem kann ich mich nur voll und ganz anschließen. Ist auch eine gute Gelegenheit, mal gründlich aufzuräumen.

Alexander

[Sven Rautenberg]

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