Lokaler Webserver Apache 500ms Verzögerung

c4y

New Member
Hallo,

ich habe einen lokalen (Web-) Server (Atom 2x1,86 Ghz, 4 GB Ram) mit Debian 6, angebunden per Gbit-LAN. Genutzt werden soll der Server vornehmlich für Webentwicklung. Clients sind Macs.

Problem:
Die Webseiten meines CMS werden mit 500ms Verzögerung ausgeliefert. Das ist deutlich zu lange in meinen Augen.

ab contao.dev = 500ms (LAN)
ab t-online.de = 35ms (Internet)

Folgende Einstellungen habe ich vorgenommen:
  • einen vHost mit VirtualDocumentRoot eingerichtet
  • dnsmasq mit *.dev als Wildcard
  • die Clients haben alle den Server als einzigen DNS-Server eingetragen
  • kein FCGID, Apache läuft unter dem gleichen Benutzer wie /var/www

Ich habe ein paar ab Tests laufen lassen.
  • php echo läuft schnell
  • phpMySQL läuft schnell
  • html läuft schnell
  • PHP mit einem DB Zugriff läuft schnell
  • CMS 500ms langsam

Ok, jetzt könnte man ja meinen, es liegt am CMS. Aber das kann es definitiv nicht sein.

Hier mal ein einfacher PHP DB Test mit ab:
Code:
Server Software:        Apache/2.2.16
Server Hostname:        dbtest.dev
Server Port:            80

Document Path:          /
Document Length:        10 bytes

Concurrency Level:      1
Time taken for tests:   0.005 seconds
Complete requests:      1
Failed requests:        0
Write errors:           0
Total transferred:      222 bytes
HTML transferred:       10 bytes
Requests per second:    210.48 [#/sec] (mean)
Time per request:       4.751 [ms] (mean)
Time per request:       4.751 [ms] (mean, across all concurrent requests)
Transfer rate:          45.63 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    1   0.0      1       1
Processing:     3    3   0.0      3       3
Waiting:        3    3   0.0      3       3
Total:          5    5   0.0      5       5

Und jetzt das ganze mit Contao (dem CMS):
Code:
Server Software:        Apache/2.2.16
Server Hostname:        contaotest.dev
Server Port:            80

Document Path:          /
Document Length:        12957 bytes

Concurrency Level:      1
Time taken for tests:   0.527 seconds
Complete requests:      1
Failed requests:        0
Write errors:           0
Total transferred:      13426 bytes
HTML transferred:       12957 bytes
Requests per second:    1.90 [#/sec] (mean)
Time per request:       527.309 [ms] (mean)
Time per request:       527.309 [ms] (mean, across all concurrent requests)
Transfer rate:          24.86 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      504  504   0.0    504     504
Processing:    24   24   0.0     24      24
Waiting:        0    0   0.0      0       0
Total:        527  527   0.0    527     527


Und hier mein vHost:
Code:
<VirtualHost 192.168.1.10>
   VirtualDocumentRoot /var/www/%1
</VirtualHost>


Hat jemand eine Idee für mich?
 
Vielleicht versucht das CMS für irgendwelche Statistiken den PTR der zugreifenden IP aufzulösen. Da das im LAN nachvollziehbarerweise bei dir vermutlich nicht geht, könnte das durchaus die Verzögerungen erklären.
 
Statistiken werden durch Contao nicht erhoben.
Es gibt zwei Sachen, die vielleicht in diese Richtung gehen:

1) IP-Prüfung - Benutzersitzungan an IP binden
2) Token bei Formularen

Beides habe ich deaktiviert. Es bleibt bei 500ms Time per Request.

Zu PTR kann ich nicht viel sagen. Auf dem Server läuft aber ein DNS-Server (dnsmasq).
 
Hast du des CMS mal komplett ohne irgendwelchen Plugins/Modulen und Designs getestet?

Generell kann des auch am Design selber liegen, je nachdem, wieviele Bilder, Sylesheets und Javascripts dort genutzt werden kann die auslieferung des hauptdocumentes verzögert werden, bis alle anderen daten geladen haben. Deswegen nutzt man auch hier meist Minified Files.

500ms sind zwar "noch" relativ kurz, finde aber auch des viel zu lang. Ich hab meine Seite auch auf 20-50ms bekommen, nur allein durch optimierungen.

Was vielleicht ab er auch sein kann: Auflösung zum Host.
Schon mal mit der IP probiert?
 
Last edited by a moderator:
HostnameLookups hatte ich schon deaktiviert.

Der Profiler ist jetzt aktiviert. Habe mir das Ergebnis mit webgrind angeschaut. So richtig schlau werde ich nicht draus. Ein herausragenden Wert finde ich nicht.
 
Javascripts und CSS werden jeweils zusammengefasst. Der Quellcode wird minifiert. Bilder gibt es so gut wie keine. Ist die Standard-Demo-Installation.

Alleine die generierte HTML-Seite braucht schon >600ms. Siehe Grafik.

Kann es ggfls am installierten xdebug liegen? Habe es gerade mal deinstalliert, aber dann läuft php komischerweise nicht mehr. Das Gleiche Ergebnis hatte ich, als ich vorher die xdebug.ini in der conf.d auskommentiert hatte.

An der Auflösung zum Host hatte ich auch schon nachgedacht. Wie mache ich das mit der IP? Wie muss ich den vHost dann einrichten?

Aktuell:
Code:
NameVirtualHost 192.168.1.10
UseCanonicalName Off
<VirtualHost 192.168.1.10>
   VirtualDocumentRoot /var/www/%1
</VirtualHost>
 

Attachments

  • Bildschirmfoto 2013-04-13 um 15.39.59.png
    Bildschirmfoto 2013-04-13 um 15.39.59.png
    163.2 KB · Views: 133
Wie sieht denn die CPU-Auslastung bei einem Seitenaufruf auf?

Meine Erfahrung mit einem Intel Atom und einem Woltlab Forum waren bei einem Seitenaufruf katastrophal.
 
Einfach mal tcpdump auf dem Server laufen lassen. Dann kannst du dir ansehen, ob und wen ja welche Daten aus dem Netz gezogen werden. Wenn da nichts ist, dann ist es die Anwendung / der Server selbst.
 
Ich sehe gerade deine Network-Grafik.
Da ist ersichtlich, dass bei den jeweiligen Ressourcen ein Waiting bzw. Blocking entsteht und dann erst die Dateien ausgeliefert werden.

Ich hab dir des mal in der Grafik veranschaulicht:
MOD: Bilder bitte immer als Anhang!

Der Linke Bereich ist ein Waiting bzw. Blocking (rot), rechts die Auslieferung (grün).
Meistens Wartet bzw. Blockt der bei folgenden Problemen:
- Dahinter steckt ein Script was Urlange benötigt (Beispielsweise wenn Ressourcen über einer PHP Datei zusätzlich bearbeitet werden)
- Auflösung dauert zu lange
- Hauptdokument blockt/wartet bis andere Dokumente wie Scripts & Co geladen sind
- Ggf. Redirects innerhalb des Requests vorhanden
 

Attachments

  • 12Nk9.png
    12Nk9.png
    126 KB · Views: 113
Last edited by a moderator:
Back
Top