Erster Aufruf extrem langsam seit update auf 3.0l7

[deta]

Hallo!

Ich habe vor ein paar Tagen auch ein update auf 3.0.7 gemacht und seither
ein Problemchen..

Beim ersten Aufruf, dauert es ewig, bis die Seite geladen ist.
Danach gehts ruckzuck...

Ihr könnt auch selber mal schauen! http://www.wobchat.de

Hat jemand ne Idee..

cu Deta

[Smoker]

Geht bei mir auch beim ersten klick recht schnell.

bye
Smoker

[deta]

Geht bei mir auch beim ersten klick recht schnell.

bye
Smoker

Dann war das purer Zufall.

Ich habs gerade wieder probiert und hier die Zahlen:

Page generated in 109.26364207 seconds (0,60% PHP - 99,40% MySQL) with 30 queries
DEBUG Mode OFF | GZIP ON (level 1) | 0,02 : 0,04 : 0,04 |

Wie gesagt es ist immer nur beim ersten Aufruf..
Danach gehts wie gewohnt schnell..

Page generated in 0.94363809 seconds (77,48% PHP - 22,52% MySQL) with 29 queries
DEBUG Mode OFF | GZIP ON (level 1) | 0,00 : 0,02 : 0,03 |

cu Deta

[StGaensler]

Bei mir geht es auch auf den ersten Aufruf schnell, selbst mit den 30 Queries:

Page generated in 0.83794093 seconds (76,08% PHP - 23,92% MySQL) with 30 queries

[Smoker]

Auch jetzt schnell.


Page generated in 0.87573290 seconds (72,76% PHP - 27,24% MySQL) with 29 queries


bye
Smoker

[deta]

Auch jetzt schnell.



bye
Smoker

Warte mal ne weile..
Dann ist der erste Aufruf extrem langsamm..

Ne weile meine ich so ca. 30 Minuten oder so..

Frag mich nicht warum wieso...

cu Deta

[Substanz]

Bei mir ist er auffällig langsam.
Hat nun 3 Minuten gebraucht. Ist es eventuell ein Indiz das es bei den Usern unterschiedlich ist? Hat es eventuell mit der momentanen Serverlast zu tun?
Gzipkomprimierung angeschaltet?

[dlutt]

Dann war das purer Zufall.

Ich habs gerade wieder probiert und hier die Zahlen:

Page generated in 109.26364207 seconds (0,60% PHP - 99,40% MySQL) with 30 queries
DEBUG Mode OFF | GZIP ON (level 1) | 0,02 : 0,04 : 0,04 |


Habe es auch mehrfach probiert. Im Durchschnitt recht gut...
Page generated in 1.27265310 seconds (86,02% PHP - 13,98% MySQL) with 25 queries
Das längste waren knapp zwei Sekunden. Also durchaus erträglich.

Die Zeiten für die SQL- Abfragen waren aber schon mal sehr hoch (99,40%). Könnte evtl. daran liegen.

[Mystics]

Erstelle einen neuen Style ohne Oberstyle - teste es damit.

Baue alle Hacks aus (lade also alle Original-Dateien hoch), entferne v.a. den Statistik-Hack und teste es dann erneut.

[microdur]

Page generated in 0.84520006 seconds (77,16% PHP - 22,84% MySQL) with 29 queries

Page generated in 0.78554010 seconds (75,52% PHP - 24,48% MySQL) with 25 queries

Page generated in 0.84710908 seconds (72,27% PHP - 27,73% MySQL) with 25 queries

bei dsl

[Smoker]

Auch jetzt ...


Page generated in 1.05751610 seconds (82,39% PHP - 17,61% MySQL) with 30 queries


bye
Smoker

[patbrandy]

Jo, dann passt mein Problem vermutlich hier auch ganz gut rein.
Grund: Mein Board bleibt demnächst stehen! Es läuft auf einem ordentlichen dedizierten Server mit schneller Anbindung. Die PHP-Geschichte des Forums treibt den Server an die Auslastungsgrenze. Eine Lösung ist momentan nicht in Sicht und würde laut Aussage der Rechenzentrum-Cracks auch mit einem Dual-Xeon-Rechner nicht besser! Das Board hat ca. 1500 User und ca. 3000 Themen/ 40.000 Beiträge die ich allerdings um die Hälfte gecuttet habe (ohne Erfolg bei der Geschwindigkeit). Als Hacks sind im Grossen und Ganzen nur der Usermap-Hack existent.

Habt ihr ähnliche Probleme mit der 3.0.7? Oder gibt es ev. irgendwelche Möglichkeiten das Ding wieder in Schwung zu bringen....?
Hab auch das Problem mit den neuen 4er und 5er PHP-Versionen gelesen und werde parallel dazu mit den Admins das mal erörtern...


Grüße!

P.S.: Hier dazu auch noch ein paar Texte:


--------
Guten Tag Herr xxx,

momentan sollten wir zunächst abwarten, ob die Probleme durch die Limit-Erhöhung beseitigt sind. Bitte geben Sie uns eine Rückmeldung, wie sich die Performance-Messungen darstellen.

Weiterhin können Sie fuer die Präsenz 900r gar nicht genug Leistung haben. Sie sehen ja unter top, dass einzelne PHP-Prozesse von 900r bis 30% CPU-Leistung benötigen.

Sie wissen aus der Vergangenheit, wie oft wir selbst auf Dual-Xeon Hochleistungsservern kritische Betriebszustände beobachten konnten. Das Problem löst man allerdings nicht wirklich mit noch mehr Leistung sondern mit einer Optimierung der Datenbankstrukturen.

Wir haben aktuell alle Indexe repariert. Ihr Kunde sollte die aktuellste Version des Boards installieren. Angesichts der aktuellen Zugriffszahlen u. der Grösse der Datenbankinhalte ist dieses Board nur wenig performant. Ggf. gibt es hier Professional-Versionen. Gute Erfahrung konnten wir auch bei grossen Zugriffszahlen mit dem "xxx Board" machen.

Weiterhin sollte Ihr Kunde prüfen, ob alte Datenbankinhalte ggf. glöscht oder archiviert werden können und prüfen welche Möglichkeiten bestehen Selects u. Queries sowie Feld-Typen zu optimieren.
--------
900r.de ist mehrfach in die nproc-Limits des Kernels gelaufen. Wir haben die Limits deutlich erhöht. Bitte testen Sie erneut. Ein RAM-Upgrade hilft hier nicht weiter, da es sich um ein CPU-Problem mit der CPU-Last durch PHP handelt. Die RAM Auslastung liegt bei Linux nach laengerer Laufzeit grundsaetzlich bei 95% (s. Kontexthilfe), da das System Prozesse cached. Auch bei einer Verdoppelung oder Verviefachung wuerden Sie in kurzer Zeit erneut bei 95% liegen.
--------
Die freien CPU-Ressourcen (idle) gehen dabei temporär immer wieder auf bis
zu 0%, d.h. Ihr System ist in diesem Moment bzgl. seiner Rechenleistung VOLL
ausgelastet.

top - 20:58:32 up 3 days, 9:20, 1 user, load average: 1.36, 1.56, 1.20
Tasks: 87 total, 3 running, 84 sleeping, 0 stopped, 0 zombie
Cpu(s): 12.3% user, 6.4% system, 81.3% nice, 0.0% idle
Mem: 513160k total, 468208k used, 44952k free, 36676k buffers
Swap: 1028152k total, 0k used, 1028152k free, 180304k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29962 900rde 19 19 6208 6208 2928 R 32.4 1.2 0:00.78 php
22347 900rde 19 19 6636 6636 2936 R 32.0 1.3 0:00.97 php
30015 900rdepa 13 5 1808 1804 1280 S 10.4 0.4 0:00.25 ipop3d

Auch wir hatten im Hosting der Präsenz immer wieder diese extremen
Auslastungen auf Maschinen beobachtet, die um ein vielfaches
leistungsfaehiger waren.
-------

[deta]

Kannst du mal ne URL zu deinen Board posten bitte..

cu Deta

[patbrandy]

900r.de/forum/

Werd aber erstmal hier ansetzen:

(Performance-Einbruch seit PHP 4.3.10 / 5.0.3)
http://www.vbulletin-germany.com/forum/showthread.php?t=15370

[deta]

Schau mal nach ob du nicht was drauf hast, was die die Perform.. klaut..
Ich hatte mal ein Tool installiert von meinen Games, das hier extrem die Perform. in die Knie gezwungen hat.

Hatte mir damals den Wolf danach gesucht.

cu Deta

[patbrandy]

Hab eigentlich nur das Board, die Usermap und einen FlashChat. Ist halt reichlich schwer an Informationen zu kommen wenn man nicht mit Linux auf die Welt gekommen ist... ;)

[patbrandy]

So, nachdem alles gecheckt wurde, hier der abschliessende Text:

----
Guten Tag Herr xxx,

Die PHP-Bugs sind bekannt. Allerdings läuft PHP 4.3.10 auf Ihrem System seit Einführung und ist nicht der Grund für die aktuellen Performance Einbussen. Das beschriebene Problem resultierte wie gesagt aus dem Erreichen eines Prozesslimits im aktuellen GRSEC-Kernel.

Ein php-Dowgrade wäre zudem aus Sicherheitsgründen keinesfalls zu empfehlen. Neue PHP-Versionen werden von uns zeitnah nach Erscheinen und ausfuehrlichen Tests zur Verfuegung gestellt.

Um das Problem dauerhaft zu beseitigen hilft nur eine Optimierung der DB-Strukturen. Eine Löschung alter Datenbestände und ein Hardware-Upgrade.

Sie sehen hier eine Prozessuebersicht vom heutigen Vormittag. Das gleiche Verhalten konnten wir bei uns schon lange vor PHP 4.3.10 auf deutlich leistungsfaehigeren Maschinen beobachten:

top - 09:53:21 up 5 days, 22:14, 1 user, load average: 3.21, 5.58, 6.12
Tasks: 107 total, 10 running, 97 sleeping, 0 stopped, 0 zombie
Cpu(s): 31.7% user, 5.3% system, 63.0% nice, 0.0% idle
Mem: 513160k total, 457852k used, 55308k free, 19424k buffers
Swap: 1028152k total, 0k used, 1028152k free, 161020k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6739 900rde 19 19 3380 3376 2244 R 16.0 0.7 0:00.41 php5
26284 900rde 19 19 7452 7452 3092 R 14.1 1.5 0:02.41 php5
28952 900rde 19 19 8360 8360 3092 R 14.1 1.6 0:01.35 php5
24241 900rde 19 19 7456 7456 3056 R 14.1 1.5 0:01.12 php5

Das verwendete Board ist fuer die Masse der Anfragen und den Umfang an Datenbankinhalten einfach wenig geeignet und sehr inperformant.
---------

Noch irgendwelche Lösungsvorschläge???

[deta]

Installiere das mal

http://www.vbulletin.org/forum/showthread.php?t=59700&highlight=Page+generated

Gibt dir ein paar Infos raus..

cu Deta

[Stussi]

Das liegt am Server...

der Satz von deinem Hoster ist echt nur lächerlich....

Das verwendete Board ist fuer die Masse der Anfragen und den Umfang an Datenbankinhalten einfach wenig geeignet und sehr inperformant.

Ich hab nen Serverload von 0,30 0,19 0,11.... (Dual P3 1GHz| 3 Gig Ram..) Da laufen im Übrigen 3 vBs mit jeweils ca. 130000 Posts drauf....

Tret dem mal innen A**** ;)

Es kann auch an deiner Membermap liegen... lösch mal den Cronjob...

[patbrandy]

Naja, ganz so schnell ist meiner nicht:
Serverload im Schnitt 4,48 4,22 3,55 auf einem 2400er Celeron / 512MB / 2x40GB
Die Membermap aktualisiere ich von Hand, kein Cronjob...

Was hast du für PHP-Versionen?

[Stussi]

4.3.11

Vorher auch mit 4.3.10 keine Probs gehabt...

Starte den Server mal neu.

Kann sein, dass da was hängt...

Für dein Forum ist der Server eigentlich voll ausreichend.

Bist eigentlich nur du auf dem Server?

[Smoker]

Also mein Board hat ...

Themen: 29.083
Beiträge: 250.195
Benutzer: 13.089

Und es läuft auf einem AMD XP 2600+ mit 512 MB ram und ich habe Serverloads von 0,3 bis 1 ... Ausgenommen gerade eben wo ich einen Newsletter versende und viele Dragon Knight spielen :D

Deswegen bin ich der Meinung das dein Server für dein Board reichen sollte.
Wie oben schon geschrieben ... starte ihn mal neu.
Ich hatte sowas auch mal, das sich x httpd prozesse aufgehangen haben und da hatte ich auch nen Load von 4 bis 7

bye
Smoker

[patbrandy]

@Stussi: Sind nur noch ein paar nicht erwähnenswerte Kunden drauf. Mein Traffic liegt derzeit bei ca. 40GB. Dein Board läuft anfürsich ja recht hurtig.

Mal sehn, schrittweise vorgehen halt...

Bis vor kurzem hat ich noch 260 rum Speed bei http://forum.webhostlist.de/show/whl/speedtest.php. Jetzt teilweise 0.1 -1.x

[patbrandy]

Könnte es auch an sowas liegen, bzw. sind die Datenbankeinträge defekt?

[Mystics]

Könnte es auch an sowas liegen, bzw. sind die Datenbankeinträge defekt?Nein, das sind die ganz normalen Binärdaten der Grafiken.

[patbrandy]

Vielen Dank!