erste Verbindung langsam (httpd)

    Hi,


    ich nutze CentOS 64bit mit Apache/2.2.3, PHP 5.3.4, MySQL 5.5 auf einem v(olks)Server 1000 und bin (eigentlich) recht zufrieden. Sofern die erste Verbindung vorbei ist, laden alle Elemente recht flott.


    Jedoch ärgert mich diese Erstverbindungs-Verzögerung. Wie sieht diese aus? ca. 2-3 sek vergehen, bevor der Browser anfängt etwas zu parsen/laden.


    Ich habe die selbe Seite mit selber Konfiguration etc. mal auf bei einem Webspace-Anbieter laufen lassen und deren Response-Time ist um einiges besser... < 1 sek.


    Wisst ihr vielleicht wo das Bottleneck ist? Braucht ihr ggf. die httpd.conf ?



    Gruß,
    Jan

    Spontan fallen mir folgende Punkte ein:

    • Keep-Alive beim Apache
    • PHP-Cache wie z.B. eAccelerator, APC, ...
    • Persistente Verbindungen zur DB o.ä.
    • usw.


    Ohne Konfigurationsdetails oder einer Beschreibung, welche Seiten Probleme machen (Scripts, auch Grafiken o.ä.?) wird dir kaum jemand helfen können.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    ok dann fangen wir mal an.. zur nächst die httpd.conf - ich nutze den prefork



    PHP aus YUM-Repo. mit nachinstalliertem APC


    ...und ein Teil der MySQL-Config



    Am Kernel schraub ich nicht, geht ja auch gar nicht :)

    Zitat von IanFrey;29087

    das vermute ich langsam auch - Schade, dass Netcup das Problem nicht in den Griff bekommt. (Hatte ich damals bei einem VP4000 auch..)


    Es gibt seitens der Virtualisierung keine Probleme. Schließlich gibt es genügend Kunden wo es funktioniert, so auch bei unseren managed vServern.

    Code
    [I]Immer diese Probleme echt eine Sauerrei, dass mein Vserver immer Mails nicht annimmt wenn die Festplatte voll ist :mad:[/I]


    Zitat

    Das kann nur an der Virtualisierung liegen :D ;)


    Wenn es ihr nicht seid, ist es immer der Anbieter, bekennt euch doch mal selber für schuldig!


    Und wenn ihr es immer nicht glaubt dann lasst es Netcup machen.Ihr gebt dann zwar Geld aus aber dies ist wiederum gut angelegtes
    Lehr-beziehungsweise Leergeld



    Euch werden sogar Lösungsansätze gegeben einfach mal abwarten wenn es nicht sofort klappt:


    Zitat von killerbees19;29079

    Spontan fallen mir folgende Punkte ein:

    • Keep-Alive beim Apache
    • PHP-Cache wie z.B. eAccelerator, APC, ...
    • Persistente Verbindungen zur DB o.ä.
    • usw.
    Zitat von Proyx;29114

    Wenn es ihr nicht seid, ist es immer der Anbieter, bekennt euch doch mal selber für schuldig!


    Nein natürlich nicht, aber das ist wie mein Problem damals, dass nach einigen Stunden bei mir immer Java-Applikationen einfach verschwunden sind, nach einem Kernel-Update war auf einmal alles wieder normal...


    Neija wie gesagt habe ich eben 3 verschiedene Lösungen am laufen, davon auch selbstgeschriebene, die weder PHP benötigen, noch auf externe Zugreifen usw.


    aber ist mir auch egal, ich habe das Problem nun einfach gelöst indem ein Cronjob alle 60 Sekunden einen Request auf den Webserver macht.

    Das ist wohl eher ein Problem der eingesetzten Software und dem Caching-Algorithmus gängiger Linux-Kernel. Jede Software benötigt Zeit, wenn sie von der Festplatte in den RAM geladen wird. netcup ist auch nicht dafür verantwortlich, dass man Beschleunigungsarbeit aufbringen muss, um ein stehendes Auto ins Rollen zu bringen...

    Hallo Felix,
    ja ich weiß genau, was du meinst und dummerweise ist es eben mal nicht einer der gängigen Problemursachen, zumindest mein Webserver den ich testweise geschrieben habe läuft dauerhaft im Ram und greift auf keinerlei externe Ressourcen zu (Festplatte, Webservices).


    Aber wie gesagt, ich kann mich damit abfinden, es ist nur ein Entwicklungssystem.

    das ist eben leider nicht feststellbar.
    Das war der Grund warum ich es eben auf die Virtualisierung schob* (wobei ich auch nicht wüsste wieso), es tritt aber eben nur das erste Mal auf, wenn der Dienst länger nicht genutzt wurde.
    Der vServer swapped jedoch zu keinster Zeit (90% des Rams frei), es ist wie als ob der Host den Prozess swappen würde, was ich mir aber eben nicht vorstellen kann, jedoch auch nicht ausschließen würde, denn eigentlich hätte er ja denke ich keinen Grund dafür.



    * wie mein Problem mit einfach verschwindenden Java-Prozessen (ohne dass sie abstürzten usw) welches niemand nachvollziehen konnte, nach einem Neustart des Host-Systems oder Kernel-Update - eines von beiden - einige Wochen später aber nie wieder auftrat.

    ice-breaker, wie genau mißt du die Verzögerung? Um wieviel größer ist die Verzögerung zu anderen Seiten? Kannst du bitte ein paar Vergleichswerte hier in das Forum schreiben.

    "Security is like an onion - the more you dig in the more you want to cry"

    Zitat

    Das war der Grund warum ich es eben auf die Virtualisierung schob*


    Wenn Sie einen Webserver programmieren können, sollten Sie doch auch in der Lage sein den Fehler der Verzögerung zu finden, oder nicht?


    Fakt ist, wir haben über 3500 vServer in Betrieb. Auf fast jedem rennt ein gängiger Webserver wie Apache, ohne das uns Probleme gemeldet werden. Zu dem haben wir selber etliche vServer in unserer Verwaltung. Das man seine persönlichen Probleme dann auf die Virtualisierung schiebt und man hier zu lesen bekommt "hade, dass Netcup das Problem nicht in den Griff bekommt", halte ich nicht für richtig.


    Zitat

    wie mein Problem mit einfach verschwindenden Java-Prozessen (ohne dass sie abstürzten usw) welches niemand nachvollziehen konnte, nach einem Neustart des Host-Systems oder Kernel-Update - eines von beiden - einige Wochen später aber nie wieder auftrat.


    Eventuell lag es an dem Zusammenspiel des eingesetzten Kernels und Ihrer Software. Da der Kernel vorgegeben ist, können Sie in dem Fall nur Ihre Software korrigieren. Java lief bislang auf jedem Kernel den wir eingesetzt haben, sprich es lag kein wesentliches Problem im Kernel vor.

    Verzögerung wird gemessen von dem Beginn der HTTP-Anfrage (Socket öffnen) bis alle Daten da sind (Response da).


    Genaue Messwerte habe ich jetzt nicht mehr hier stehen, die Messreihe ist schon zu alt, es bewegt sich im Bereich um die 2 Sekunden, wurde das erste Mal der Webserver von irgendeinem PC aufgerufen funktioniert auch der Aufruf von einem anderen PC innerhalb von wenigen Millisekunden, also es hat nichts mit dem eigentlichen starten einer Socket-Verbindung zu tun, sonst müsste jeder PC die 2 Sekunden Verzögerung haben.


    Den genauen Grund zu finden ist eben schwer, denn wenn von irgendeinem PC einmal die 2 Sekunden gewartet wurden funktioniert alles wieder wie es sollte und es dauert wieder lange bis man einen erneuten Test durchführen kann, es hat eben haargenau die Swapping-Merkmale nur dass ich in meinem vServer kein Swapping habe, daher kam eben die nicht begründbare Idee des Swappings auf dem Hostsystem, beweisen kann ich es natürlich nicht, ich wüsste auch nicht warum es so sein sollte, es ist nur eben die einzige Erklärung, die ich habe, die genau zu dem Verhalten passt.


    Zitat von [netcup] Felix;29152

    Wenn Sie einen Webserver programmieren können, sollten Sie doch auch in der Lage sein den Fehler der Verzögerung zu finden, oder nicht?


    leider nein, ich sehe in meinem Webserver, dass das rendern nur einen Bruchteil der Wartezeit benötigt (gemessen von eingehender Socket-Verbindung bis Ende) - nur so lange wie auch jeder der weiteren Zugriffe benötigt - es passiert also irgendwo transparent.


    Zitat von [netcup] Felix;29152

    Fakt ist, wir haben über 3500 vServer in Betrieb. Auf fast jedem rennt ein gängiger Webserver wie Apache, ohne das uns Probleme gemeldet werden. Zu dem haben wir selber etliche vServer in unserer Verwaltung.


    natürlich, ich will da auch niemandem einen Strick drehen, aber wie es eben so ist gibt es ja Probleme, die nur unter bestimmten Vorraussetzungen auftreten und dann kommt eben noch dazu, dass ich das Problem auch nur feststellen kann, wenn auf den Webserver lange nicht zugegriffen wurde.


    Zitat von [netcup] Felix;29152

    Das man seine persönlichen Probleme dann auf die Virtualisierung schiebt und man hier zu lesen bekommt "hade, dass Netcup das Problem nicht in den Griff bekommt", halte ich nicht für richtig.


    wie gesagt will ich nicht sagen, dass es ein Problem eurer Virtualisierung ist und ihr das beheben sollt, ich habe es ja auch nie gemeldet, es ist mir eben egal, es wird also aus diesem Grund nur als Entwicklungssystem genutzt.
    Ich sagte eben nur, dass es für mich am wahrscheinlichsten scheint, dass es das Host-System ist, weil es eben genau die Merkmale eines Swapping aufweist, ohne dass mein vServer meldet, dass er swappt und er auch nicht swappen dürfte (400MB Ram frei).


    Zitat von [netcup] Felix;29152

    Eventuell lag es an dem Zusammenspiel des eingesetzten Kernels und Ihrer Software. Da der Kernel vorgegeben ist, können Sie in dem Fall nur Ihre Software korrigieren. Java lief bislang auf jedem Kernel den wir eingesetzt haben, sprich es lag kein wesentliches Problem im Kernel vor.


    das was ich an Java-Software getestet hatte waren voll ausgereifte Java-Anwendungen (Jetty, Tomcat, Hudson) usw, selbst ein Java-Prozess der nur alle 60 Sekunden eine Meldung ausgab verschwand einfach, das liegt dann denke ich eher weniger an der eigenen Software oder? ;) (zumal ich diese Minimalsoftware auch auf dutzenden anderen Systemen ohne Probleme mehrere Tage laufen ließ)
    Es gab keine Crashlogs, kein nichts gab, der Prozess verschwand einfach.
    Da man bei solchen Problemen vom Support eben nur hört, dass man selbst Schuld ist - was sicherlich auf 99% der Probleme zutrifft - habe ich eben auch keine Mühe unternommen das Problem zu melden, die Antwort hätte ich ja eh gekannt.
    Da nach dem genannten Neustart bzw. Kernel-Update haargenau die gleiche Software unter immernoch einem unveränderten System ohne jegliche Probleme dann für Monate lief, sah ich mich eben sehr bestätigt in meiner Vermutung, dass es einfach ein Problem zwischen dem Kernel und Java war.




    Wie gesagt, mir ist das Problem aber eben auch egal, ich nutze aus diesem Grunde meinen vServer nur als Entwicklungssystem, ich wollte eben dem Threadersteller nur sagen, dass er nicht der einzige ist, der das Problem hat und ich auch bei mir Apache ausschließen konnte und viele weitere potentielle Probleme

    Ohne das Thema jetzt unnötig zu pushen, aber bei meinem MySQL Problem vor einem Jahr war es ähnlich. Dann gab es ein Kernel Update und alles lief wieder. Eine bestimmte Inkompatibilität mit einigen Kernel Versionen und bestimmten Softwareprodukten oder Systemaufrufen könnte ich mir also auch durchaus vorstellen. Da man auf den Kernel aber keinen "Zugriff" hat wird man das schwer bis gar nicht nachvollziehen oder bestätigen können. Interessant wären trotzdem die Versionen der verwendeten Programme und die Kernel Version auf deinem vServer. Oder in deinem Fall - wenn du den Webserver selbst geschrieben hast - welche speziellen Systemaufrufe du verwendest. Daten über deine Systemauslastung wären auch interessant. Außerdem solltest du beachten, dass sehr viele Programme immer etwas von der Festplatte lesen oder darauf schreiben, das könnte im Zusammenhang mit dem Scheduling dann zu Verzögerungen führen, wenn nicht genügend Ressourcen vorhanden sind.


    Meine Webserver auf den netcup vServern laufen übrigens seit Monaten problemlos.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Zitat von killerbees19;29156

    Ohne das Thema jetzt unnötig zu pushen, aber bei meinem MySQL Problem vor einem Jahr war es ähnlich. Dann gab es ein Kernel Update und alles lief wieder.


    ah stimmt, ich erinner mich ;)
    Du hattest mich dadurch erst auf die Idee gebracht, dass es genau der gleiche Grund sein könnte, warum mein Java (Problem von damals) auf einmal ohne jegliche Probleme lief.


    Zitat von killerbees19;29156

    Eine bestimmte Inkompatibilität mit einigen Kernel Versionen und bestimmten Softwareprodukten oder Systemaufrufen könnte ich mir also auch durchaus vorstellen.


    das ist ausgeschlossen, auf hunderten Servern läuft alles ohne Probleme.
    (tut mir leid, konnte ich mir nicht verkneifen :D das man einmal nicht für den absolut dummen gehalten wird ist angenehm *kiss*)



    Zitat von killerbees19;29156

    Interessant wären trotzdem die Versionen der verwendeten Programme und die Kernel Version auf deinem vServer. Oder in deinem Fall - wenn du den Webserver selbst geschrieben hast - welche speziellen Systemaufrufe du verwendest. Daten über deine Systemauslastung wären auch interessant. Außerdem solltest du beachten, dass sehr viele Programme immer etwas von der Festplatte lesen oder darauf schreiben, das könnte im Zusammenhang mit dem Scheduling dann zu Verzögerungen führen, wenn nicht genügend Ressourcen vorhanden sind.


    Kernel: 2.6.35.8-vs2.3.0.36.33
    Java-Version: 1.6.0_22 (aktuellste Debianversion)
    Systemauslastung: kompletter Host absolut idle (3%)
    Ramauslastung: 36/500MB belegt
    Festplattenzugriffe: ausgeschlossen, mein eigener Test-Webserver operierte rein im Ram.



    ich will da auch nicht drauf rumreiten, Netcup kann sich die Daten notieren, wenn sie wollen, falls noch mehr irgendwann das Problem vermelden sollten, aber mir ist es schnuppe