9
Webserver sehr langsam
Hallo,
Ich versuche gerade einen internen Webserver etwas zu beschleunigen.
Der Webserver ist ein IIS, die Seite ist in php geschrieben und die Datenbank ist MSSQL Express auf einem dezidierten Server. Das ganze wurde von einem ehemaligen Kollegen zusammengebaut und jetzt fehlt uns leider das Know-How.
Grundsätzlich funktioniert die Seite gut, manchmal sind die Abfragen etwas langsam, es werden aber sehr viele Datensätze abgefragt und das zum Teil aus mehrern Tabellen oder Datenbanken. Hier müsste "einfach" der Code optimiert werden.
Mir ist aber aufgefallen dass bei einem der Formulare beim Speichern sehr viele Felder per HTTP Post übermittelt werden und in der Datenbank aktualisiert werden. Das kann dann schon mehrere Minuten dauern und evtl. auch mit einem Http 500 Fehler enden.
Ich weiß ehrlich gesagt nicht wo ich suchen soll. Überlastet kann der Server kaum sein, da es genauso lange dauert wenn dies die einzige Verbindung ist.
Im php error Log werden bei dem Vorgang massenhaft Fehler vom Typ
und auch einige
Also gibt es genügend Fehler im Code die behoben werden wollen.
Aber kann das hier wirklich der Flaschenhals sein?
Wenn mehr Informationen oder Log Files benötigt werden um hierzu was sagen zu können, kann ich damit gerne dienen. Ich weiß wie gesagt nicht wo ich hier ansetzen soll.
LG, axcro
Ich versuche gerade einen internen Webserver etwas zu beschleunigen.
Der Webserver ist ein IIS, die Seite ist in php geschrieben und die Datenbank ist MSSQL Express auf einem dezidierten Server. Das ganze wurde von einem ehemaligen Kollegen zusammengebaut und jetzt fehlt uns leider das Know-How.
Grundsätzlich funktioniert die Seite gut, manchmal sind die Abfragen etwas langsam, es werden aber sehr viele Datensätze abgefragt und das zum Teil aus mehrern Tabellen oder Datenbanken. Hier müsste "einfach" der Code optimiert werden.
Mir ist aber aufgefallen dass bei einem der Formulare beim Speichern sehr viele Felder per HTTP Post übermittelt werden und in der Datenbank aktualisiert werden. Das kann dann schon mehrere Minuten dauern und evtl. auch mit einem Http 500 Fehler enden.
Ich weiß ehrlich gesagt nicht wo ich suchen soll. Überlastet kann der Server kaum sein, da es genauso lange dauert wenn dies die einzige Verbindung ist.
Im php error Log werden bei dem Vorgang massenhaft Fehler vom Typ
'Undefined index'
'Use of undefined constant'
'Undefined variable' 'Invalid argument supplied for foreach()'
'include(../blabla.php): failed to open stream'
'include(): Failed opening'
'utf8_decode() expects parameter 1 to be string, array given' Aber kann das hier wirklich der Flaschenhals sein?
Wenn mehr Informationen oder Log Files benötigt werden um hierzu was sagen zu können, kann ich damit gerne dienen. Ich weiß wie gesagt nicht wo ich hier ansetzen soll.
LG, axcro
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 611570
Url: https://administrator.de/contentid/611570
Printed on: April 24, 2024 at 02:04 o'clock
9 Comments
Latest comment
Welche Windows Version?
Welche MSSQl Version?
Wie viel RAM ?
Cpu?
Worauf läuft der Server? Als VM? HDD oder SSD?
Welche MSSQl Version?
Wie viel RAM ?
Cpu?
Worauf läuft der Server? Als VM? HDD oder SSD?
Naja - da steht ja schon mal so einiges.... du packst dem nen array dahin wo er nen string (einfacher text) erwartet, uncool... es scheint das deine "blabla.php" fehlt - und du hast in irgendeinem foreach auch noch nen fehler ...
Ich mein, mehr als so deutlich kann dir der php-interpreter die Fehler nich sagen...
Ich mein, mehr als so deutlich kann dir der php-interpreter die Fehler nich sagen...
Hallo,
du kannst auch mal den SQL Server Profiler vom Management Studio auf deine Datenbank loslassen.
Dann sieht du ja mal wie lange die Abfragen dauern
du kannst auch mal den SQL Server Profiler vom Management Studio auf deine Datenbank loslassen.
Dann sieht du ja mal wie lange die Abfragen dauern
Hallo,
Du hast eine üble Kombination erwischt.
IIS + PHP + MSQL
Die mögen sich selten.
Zur Lösung deines Problems, hold dir einen Programmierer zur Analyse der Software ins Haus,
als nächste setz dir ein Linux in einer VM auf und schmeiß den IIS raus für diese Applikation
Du hast eine üble Kombination erwischt.
IIS + PHP + MSQL
Die mögen sich selten.
Zur Lösung deines Problems, hold dir einen Programmierer zur Analyse der Software ins Haus,
als nächste setz dir ein Linux in einer VM auf und schmeiß den IIS raus für diese Applikation
1
Cool - deine Glaskugel war wieder heile? Denn aus den paar Infos oben abzuleiten das der ganze WEBSERVER getauscht werden muss is schon ne gute Aussage. Du weisst nicht mal was die Applikation macht - nur das die irgendeine (nicht vorhandene) PHP-Datei u.a. einlesen will -> ich bin mir ziemlich sicher das auch unter Apache eine nicht vorhandene Datei (bzw. eine Datei ohne das der Webserver Zugriff drauf hat) nicht gelesen werden kann...
Noch viel weniger weisst du über die Datenbank selbst. Auch da kann es noch einiges an Problemen geben. Wenn ich z.B. hier bei mir eine Funktion aufrufe dann rennt mein Server erst mal los und sucht - leider muss ich da in der DB auf String-Vergleiche gehen was dann auch mal 2-3 Minuten braucht bis die Datensätze durch sind. Die Tabelle füllt sich automatisch - d.h. zu Anfang ist die Funktion natürlich super schnell gewesen (weil nur ne Handvoll Geräte drin war), mittlerweile sind da einige 10.000 Einträge drin und das dauert kurz. Da is es egal ob davor nen Tomcat, IIS oder nen Perl-Script läuft.
Du weisst auch nix über die Funktion die aufgerufen wird. Ich kann mit nem einfachen Aufruf meinen Server erst mal für locker 30-40 Minuten komplett auslasten (Load von 12 bis über 20). Da rennt der einfach über einige 100 GB an Daten und indiziert die - und bildet für jede Datei eine eigene MD5-Summe um rauszufinden ob die Datei schon durch nen Verteilsystem gelaufen ist. Auch da is es völlig egal welcher Server da läuft - da es einfach an den Plattenzugriffen liegt die da dauern und es eben auch einen moment dauert ne MD5-Summe über ne 5GB Datei zu erzeugen.
Von daher stellt sich mir die Frage wie du darauf kommst das die Kombination da ein Problem sein soll ohne IRGENDWAS über die Anwendung zu wissen... Das gehört für mich in den Bereich "Ich hab zwar keine Ahnung aber irgendwo mal gelesen das es irgendwie irgendein Problem mit IIS + PHP gab ...also is es jetzt generell immer schlecht". Der einzige Punkt dem ich allerdings auch zustimmen würde - ohne Programmierer wird das schwer rauszufinden da eben hier keiner den Quellcode kennen wird und/oder eben überhaupt weiss was ihr da vorhabt.
Was jedoch generell schwer ist: Den Code zu "optimieren" wenn du nicht genau weisst was der macht. Auch da wäre es natürlich ein Ansatz zu schauen WO du die Zeit verbläst -> z.B. indem du schaust ob du in dem Code einfach entweder nen logging erzeugen kannst ODER du erzeugst einfach beim Aufruf nen paar leere Files in nem temp.-Ordner und schaust da die Erstellzeit an (ist dann halt nich so genau, sollte aber reichen). NORMALERWEISE verbringst du in nem Code den grossteil der Zeit in irgendwelchen Schleifen (z.B. dein foreach) - entsprechend wäre da auch der höchste Gewinn zu erwarten. Auch dafür muss man aber wissen WAS da gemacht wird - wenn das Foreach nur beigeht und fröhlich nen internen Counter hochzählt wäre es sinnlos aber schnell... Wenn du in dem Foreach aber z.B. 10.000 Durchläufe hast, in jedem Durchlauf baust du die Verbindung zur DB auf (connect), machst ein Statement und schließt dann die Verbindung wieder sieht das anders aus -> da das Connect schon Zeit braucht UND man da gucken könnte ob das Statement sich ggf. so optimieren lässt das du nur EINEN durchlauf brauchst bzw. falls mehrere Statements da sind ob man das Zusammenfassen kann (z.B. statt "select id from xyz where feld=...; update xyz set abc=... where id = $id könnte man ja ggf. sagen "update xyz set xyz where feld = ..." - wobei es eher selten SO einfach ist ;)). Da kommt es dann auch noch drauf an wie viel Zeit der ehemalige Kollege hatte - wenns schnell gehen muss kommen halt auch oft die Optimierungen zu kurz ;).
Noch viel weniger weisst du über die Datenbank selbst. Auch da kann es noch einiges an Problemen geben. Wenn ich z.B. hier bei mir eine Funktion aufrufe dann rennt mein Server erst mal los und sucht - leider muss ich da in der DB auf String-Vergleiche gehen was dann auch mal 2-3 Minuten braucht bis die Datensätze durch sind. Die Tabelle füllt sich automatisch - d.h. zu Anfang ist die Funktion natürlich super schnell gewesen (weil nur ne Handvoll Geräte drin war), mittlerweile sind da einige 10.000 Einträge drin und das dauert kurz. Da is es egal ob davor nen Tomcat, IIS oder nen Perl-Script läuft.
Du weisst auch nix über die Funktion die aufgerufen wird. Ich kann mit nem einfachen Aufruf meinen Server erst mal für locker 30-40 Minuten komplett auslasten (Load von 12 bis über 20). Da rennt der einfach über einige 100 GB an Daten und indiziert die - und bildet für jede Datei eine eigene MD5-Summe um rauszufinden ob die Datei schon durch nen Verteilsystem gelaufen ist. Auch da is es völlig egal welcher Server da läuft - da es einfach an den Plattenzugriffen liegt die da dauern und es eben auch einen moment dauert ne MD5-Summe über ne 5GB Datei zu erzeugen.
Von daher stellt sich mir die Frage wie du darauf kommst das die Kombination da ein Problem sein soll ohne IRGENDWAS über die Anwendung zu wissen... Das gehört für mich in den Bereich "Ich hab zwar keine Ahnung aber irgendwo mal gelesen das es irgendwie irgendein Problem mit IIS + PHP gab ...also is es jetzt generell immer schlecht". Der einzige Punkt dem ich allerdings auch zustimmen würde - ohne Programmierer wird das schwer rauszufinden da eben hier keiner den Quellcode kennen wird und/oder eben überhaupt weiss was ihr da vorhabt.
Was jedoch generell schwer ist: Den Code zu "optimieren" wenn du nicht genau weisst was der macht. Auch da wäre es natürlich ein Ansatz zu schauen WO du die Zeit verbläst -> z.B. indem du schaust ob du in dem Code einfach entweder nen logging erzeugen kannst ODER du erzeugst einfach beim Aufruf nen paar leere Files in nem temp.-Ordner und schaust da die Erstellzeit an (ist dann halt nich so genau, sollte aber reichen). NORMALERWEISE verbringst du in nem Code den grossteil der Zeit in irgendwelchen Schleifen (z.B. dein foreach) - entsprechend wäre da auch der höchste Gewinn zu erwarten. Auch dafür muss man aber wissen WAS da gemacht wird - wenn das Foreach nur beigeht und fröhlich nen internen Counter hochzählt wäre es sinnlos aber schnell... Wenn du in dem Foreach aber z.B. 10.000 Durchläufe hast, in jedem Durchlauf baust du die Verbindung zur DB auf (connect), machst ein Statement und schließt dann die Verbindung wieder sieht das anders aus -> da das Connect schon Zeit braucht UND man da gucken könnte ob das Statement sich ggf. so optimieren lässt das du nur EINEN durchlauf brauchst bzw. falls mehrere Statements da sind ob man das Zusammenfassen kann (z.B. statt "select id from xyz where feld=...; update xyz set abc=... where id = $id könnte man ja ggf. sagen "update xyz set xyz where feld = ..." - wobei es eher selten SO einfach ist ;)). Da kommt es dann auch noch drauf an wie viel Zeit der ehemalige Kollege hatte - wenns schnell gehen muss kommen halt auch oft die Optimierungen zu kurz ;).
Zitat von @godlie:
Hallo,
Du hast eine üble Kombination erwischt.
IIS + PHP + MSQL
Die mögen sich selten.
Zur Lösung deines Problems, hold dir einen Programmierer zur Analyse der Software ins Haus,
als nächste setz dir ein Linux in einer VM auf und schmeiß den IIS raus für diese Applikation
Hallo,
Du hast eine üble Kombination erwischt.
IIS + PHP + MSQL
Die mögen sich selten.
Zur Lösung deines Problems, hold dir einen Programmierer zur Analyse der Software ins Haus,
als nächste setz dir ein Linux in einer VM auf und schmeiß den IIS raus für diese Applikation
Interessant. Die läuft hier bei uns im Haus mit tausenden Zugriffen problemlos.
moin...
wo hast du das gelesen?
Frank
wo hast du das gelesen?
IIS + PHP + MSQL
ist ein Klassiker...(auf Windows Basis)Die mögen sich selten.
seit wann?Zur Lösung deines Problems, hold dir einen Programmierer zur Analyse der Software ins Haus,
darf ich anehmen, das du nach deiner Expertise zeit dafür hättest?als nächste setz dir ein Linux in einer VM auf und schmeiß den IIS raus für diese Applikation
hihi... der IIS wüde ja auch nicht unter Linux laufen, da braucht keiner was rauszuwerfen....Frank
Zitat von @maretz:
Von daher stellt sich mir die Frage wie du darauf kommst das die Kombination da ein Problem sein soll ohne IRGENDWAS über die Anwendung zu wissen... Das gehört für mich in den Bereich "Ich hab zwar keine Ahnung aber irgendwo mal gelesen das es irgendwie irgendein Problem mit IIS + PHP gab ...also is es jetzt generell immer schlecht".
Von daher stellt sich mir die Frage wie du darauf kommst das die Kombination da ein Problem sein soll ohne IRGENDWAS über die Anwendung zu wissen... Das gehört für mich in den Bereich "Ich hab zwar keine Ahnung aber irgendwo mal gelesen das es irgendwie irgendein Problem mit IIS + PHP gab ...also is es jetzt generell immer schlecht".
Nein. Ich bestätige seine Aussage weil ich es für jemanden mit einer mittelgroßen Anwendung gemacht habe. Es ist ein Gefrickel und läuft performancemäßig deutlich schlechter als Linux. Anschließend die gleiche Anwendung auf Nginx unter Linux, anschließend waren die Ladezeiten direkt um 1/3 geringer. Und das war eine 0815 Vanilla-Installation auf Linux, ohne Optimierungen. Selbst bei großen Codebasen wie Wordpress die auch nicht unbedingt so sehr auf Performance optimiert sind, hat Linux die Nase vorne.
Ist auch kein Wunder, schließlich wurde das für Linux entwickelt. Es gibt wenig Gründe warum man so was auf Win hosten sollte. Später wurde das mal portiert, aber schon immer stiefmütterlich weil die meisten Webserver unter Linux gefahren werden.
Dazu kommt, dass der IIS ein sehr mächtiger Webserver ist. Man kann vieles damit machen aber sich eben auch Probleme schaffen. Den nur dafür zu nehmen um per CGI PHP auszuliefern ist overkill.
Natürlich ist das jetzt ein konkreter Anwendungsfall. Je nachdem was für eine Applikation er hat, was die macht, welche PHP-Version er einsetzt usw. wird das mehr oder weniger als 30% sein. Aber tendenziell läuft so was unter Windows schlechter.
Zitat von @tech-flare:
Interessant. Die läuft hier bei uns im Haus mit tausenden Zugriffen problemlos.
Interessant. Die läuft hier bei uns im Haus mit tausenden Zugriffen problemlos.
Uninteressant. Grade bei Kleinkram macht sich das wenig bis gar nicht bemerkbar. Ob so ein Skript in 100 oder 200ms gerendert ist, merkt der normale Nutzer kaum. Da kannst du einen uralten Windows Server 2008 mit PHP 4 haben (habe ich schon gesehen bei Leuten die z.B. hauptsächlich ASP.NET historisch bedingt auf Win machen und für eine PHP-Anwendung kein Linux-Know How aufbauen wollen). Von dem her ist die alleinige Aussage "Das läuft aber bei uns toll!!!111einself" nichts wert.
Kann, wenn z.B. die Warnungen in einer Schleife oder durch viele Zugriffe gehäuft auftreten. Muss aber nicht. In deiner ersten Box sind nur Warnungen. Das kann sich aber trotzdem auf die Anwendung (und deren Logik!) auswirken. Wenn die Anwendung z.B. irgendwas mit einem Array-Element macht das es nicht gibt (Undefined index), bekommt die an der Stelle ja keine Daten. Genau das Gleiche mit Konstanten. Wenn die Anwendung das aber braucht (z.B. Konstante mit Basis-URL) kann etwas schief laufen.
Die zweite Box sind fatale Fehler, also eine Stufe kritischer. Da bricht das Skript dann in der Regel auch ab. Je nach Serverconfig können die 500er verursachen.
Abgesehen von dem was schon gesagt wurde kann man dazu aber nicht viel sagen. Entweder kennst du dich mit PHP aus, kannst den Code selbst re-factorn (zumindest so weit, dass du konkrete Fragen stellen kannst) oder du beauftragst jemanden der das macht. Ohne zu wissen was das konkret für eine Umgebung ist, was die Applikation konkret macht und wie die Codebasis dazu aussieht, kann man dazu nur sagen: Wenn solche Fehler im Log stehen, ist die Codebasis wahrscheinlich nicht die Beste und man kann mit einem Re-factoring sicher was rausholen.
Hallo @all
und danke erstmal für die rege Beteiligung. Ich muss mir eure Beiträge erst noch im Detail durchlesen und liefere euch dann Antworten.
Ich muss die Woche noch einige dringende Arbeitspakete erledigen bevor ich mich wieder diesem Webserver widmen kann ...
Nur dass es nicht heißt der TO wäre abgehauen ;)
LG
und danke erstmal für die rege Beteiligung. Ich muss mir eure Beiträge erst noch im Detail durchlesen und liefere euch dann Antworten.
Ich muss die Woche noch einige dringende Arbeitspakete erledigen bevor ich mich wieder diesem Webserver widmen kann ...
Nur dass es nicht heißt der TO wäre abgehauen ;)
LG
