• Registrieren
  • Anmelden
  • Dokumentation
  • Hilfe

Geschlecht: Männlich

Wohnort: Düsseldorf

1

Sonntag, 8. Februar 2009, 21:42

Internes Debugging: Server extrem langsam

Hallo!

Nachdem das interne Debugging bei mir nun prinzipiell funktioniert, muss ich leider feststellen, dass der Server dort unglaublich langsam läuft. Teilweise reagiert er auch gar nicht (wenn ich einen Link anklicke, wartet der Browser bis in alle Ewigkeiten auf eine Antwort).

Woran kann das liegen?

Grüße
Christian Stelzmann

//edit: Ach ja, und immer mal wieder meldet Windows "CGI / FastCGI has stoppen working".

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Christian S.« (8. Februar 2009, 21:47)


Thomas Schaaf

Administrator

Geschlecht: Männlich

Wohnort: Braunschweig

2

Montag, 9. Februar 2009, 18:08

Ich mache heute oder morgen ein Video wie man einen externen Apache installieren kann. Da man dieses selbst besser konfigurieren kann und auch nur Sachen einschaltet die man benötigt sollte das dann auch deutlich schneller gehen.

Ich hoffe, dass das eine Lösung sein wird.

Grüße aus Braunschweig
Thomas Schaaf

Geschlecht: Männlich

Wohnort: Düsseldorf

3

Montag, 9. Februar 2009, 18:36

Ich habe gestern sehr lange daran gesessen, den Fehler zu finden, warum mein externen Apache absürzt. Sie können mir glauben, dass das mit einem einfachen Video nicht getan sein wird ;-)

Ich möchte auch nicht beliebig viel Zeit damit verbringen, einen Apache zu konfigurieren. Sie bieten internes Debugging als Teil des Produktes an, also muss das doch anständig funktionieren.

Thomas Schaaf

Administrator

Geschlecht: Männlich

Wohnort: Braunschweig

4

Montag, 9. Februar 2009, 18:40

Der Apache hat nur absolut jede Funktion von Apache angeschaltet was dazuführt, dass das starten das Apaches alleine sehr viel Zeit kostet. Wir gucken mal, ob man das weiter optimieren kann.

Thomas Schaaf

Administrator

Geschlecht: Männlich

Wohnort: Braunschweig

5

Montag, 9. Februar 2009, 18:59

Ich müsste nochmal genau wissen was genau langsam ist. Könnten Sie ganz oben im PHP Skript ein $start = microtime(true); und ans ende ein echo (microtime(true) - $start) * 1000; machen und mir sagen wie viele ms die Anfrage von PHP bearbeitet wurde? Können Sie das mit einem dedizierten Webserver vergleichen? Können Sie mit Firebug sagen wie lange es gedauert hat die Seite komplett auf dem lokalen Webserver und auf dem Webserver zu laden? Haben vielleicht viele kleine Dateien die Schuld (Standardmäßig erlaubt der integrierte Webserver nur 3 Downloads gleichzeitig, evtl wollen Sie das in der .conf verändern?

Mit diesen Daten kann ich hoffentlich weiter arbeiten und das Problem analysieren.

Danke
Thomas Schaaf

Geschlecht: Männlich

Wohnort: Düsseldorf

6

Montag, 9. Februar 2009, 19:58

Hallo!

Die größten Wartezeiten kommen zustande, wenn eine Anfrage für eine neue Seite gesndet wird. Beispiel: Ich klicke einen Link an. Die aktuelle Seite verschwindet nicht (es wird die neue Seite also nicht geladen), sondern es kommt nur der Warten-Cursor. Teilweise bis in alle Ewigkeit. Die Software selber läuft sonst reibunsglos und schnell: http://www.c-sharp-forum.de

Das Erhöhen der ThreadsPerChild auf 50 in der .conf-Datei verbesserte die Situation schonmal erheblich. Die Fehlermeldung von Windows, dass CGI / FastCGI nicht mehr arbeitet, kommt leider weiterhin. Wäre es nicht eh schnell, Apache-Module zu verwenden? Wenn ich mich recht entsinne, ist CGI / FastCGI nicht gerade für seine Performance bekannt.


zum externen Debugging:

Ich habe es inzwischen geschafft, DBG ans Laufen zu bekommen. Meine Recherche hat ergeben, dass XDebug in Kombination mit XAMPP und Vista einen Bug hat, der zu den von mir beobachteten Crashes führt. Bei DBG war die Hürde, dass das Teil nicht lief, wenn man bei extension=... einen Pfad mit angeben will (ja, die Slashes waren in die richtige Richtung ;-)). Aber das läuft jetzt und auch schnell :-)

Für Tests bezgl. der Performance des internen Apache stehe ich trotzdem gerne zur Verfügung.


Grüße
Christian Stelzmann