54
Zugriff intern auf Https Seite sehr langam
Hallo,
ich habe ein massives Performanceproblem auf einem internen Server sobald ich auf den mit https zugreife.
Auf dem Server läuft eine mysql Datenbank.
Ich habe mittlerweile schon eine ganze Menge versucht zb habe ich MySql performance Tuning so lange angepasst bis
diverse testingtools sich vor Freude überschlagen haben, wenn ich meine SqlDatenbank getestet habe, dann habe ich
eine interne DNS Zone eingerichtet damit der Name auch ja im internen Netz aufgelöst wird und niemand nach extern rausgehen muss um zu resolven.
Das hat alles 0 gebracht.
Mittlerweile bin ich etwas ratlos und vermute fast ein Netzwerkproblem.
Der Netzwerkzugriff ansonsten ist prima, nur wenn ich die Webseite dieses Servers aufrufen und auch nur über https
habe ich Ladezeiten von 10 Sekunden und mehr pro Seitenwechsel.
Hat irgendwer eine Idee was das sein kann?
PS:http://support.microsoft.com/kb/929868/de#letmefixit
das kenne ich leider auch schon, hat auch nix gebracht
ich habe ein massives Performanceproblem auf einem internen Server sobald ich auf den mit https zugreife.
Auf dem Server läuft eine mysql Datenbank.
Ich habe mittlerweile schon eine ganze Menge versucht zb habe ich MySql performance Tuning so lange angepasst bis
diverse testingtools sich vor Freude überschlagen haben, wenn ich meine SqlDatenbank getestet habe, dann habe ich
eine interne DNS Zone eingerichtet damit der Name auch ja im internen Netz aufgelöst wird und niemand nach extern rausgehen muss um zu resolven.
Das hat alles 0 gebracht.
Mittlerweile bin ich etwas ratlos und vermute fast ein Netzwerkproblem.
Der Netzwerkzugriff ansonsten ist prima, nur wenn ich die Webseite dieses Servers aufrufen und auch nur über https
habe ich Ladezeiten von 10 Sekunden und mehr pro Seitenwechsel.
Hat irgendwer eine Idee was das sein kann?
PS:http://support.microsoft.com/kb/929868/de#letmefixit
das kenne ich leider auch schon, hat auch nix gebracht
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 157207
Url: https://administrator.de/forum/zugriff-intern-auf-https-seite-sehr-langam-157207.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
54 Kommentare
Neuester Kommentar
Ist das so bei statischen oder auch bei dynamischen Seiten?
Ist die URL der im Zertifikat angegebenen CRL erreichbar?
Ist die URL der im Zertifikat angegebenen CRL erreichbar?
Hallo,
es handelt sich dabei fast nur um dynamische Seiten (die Seite zieht sich Sachen aus der MysqlDB die dahinterklemmt)
Ich weiß nicht ob ich Dich bei der URL richtig verstehe.
Aussteller ist meine www-domäne und die ist auch aufrufbar im Browser.
Trotzdem meldet der Browser bei jedem laden einen vermeintlichen Täuschungsversuch (rote Firefoxurlbar)
PS: irgendwie bin ich zu doof hier Screenshots einzufügen.
Wo geht das denn?
es handelt sich dabei fast nur um dynamische Seiten (die Seite zieht sich Sachen aus der MysqlDB die dahinterklemmt)
Ich weiß nicht ob ich Dich bei der URL richtig verstehe.
Aussteller ist meine www-domäne und die ist auch aufrufbar im Browser.
Trotzdem meldet der Browser bei jedem laden einen vermeintlichen Täuschungsversuch (rote Firefoxurlbar)
PS: irgendwie bin ich zu doof hier Screenshots einzufügen.
Wo geht das denn?
es handelt sich dabei fast nur um dynamische Seiten
Das beantwortet nicht die Frage, ob es bei statischen Inhalten auch passiert.
Wo geht das denn?
Im Originalbeitrag hochladen und Text irgendwo einfügen.
Ich weiß nicht ob ich Dich bei der URL richtig verstehe.
Die CRL-URL ist Teil der Zertifikat-Attribute (und damit meine ich nicht den Namen des Zertifikats).
Such die raus und guck, ob sie aufrufbar ist.
Zitat von @dog:
> es handelt sich dabei fast nur um dynamische Seiten
Das beantwortet nicht die Frage, ob es bei statischen Inhalten auch passiert.
> es handelt sich dabei fast nur um dynamische Seiten
Das beantwortet nicht die Frage, ob es bei statischen Inhalten auch passiert.
Das ist halt jetzt sehr subjektiv weil die statischen Seiten auch nicht wirklich viel darstellen müssen, aber gefühlt sind die statischen Seiten sehr viel schneller als die dynamischen.
> Ich weiß nicht ob ich Dich bei der URL richtig verstehe.
Die CRL-URL ist Teil der Zertifikat-Attribute (und damit meine ich nicht den Namen des Zertifikats).
Such die raus und guck, ob sie aufrufbar ist.
Die CRL-URL ist Teil der Zertifikat-Attribute (und damit meine ich nicht den Namen des Zertifikats).
Such die raus und guck, ob sie aufrufbar ist.
Ok ich hab nun mal versucht das zu finden.
Dafür bin ich in den Browser gegangen und habe auf den Button "Zertifikatsfehler geklickt"
Dort konnte ich weiter zu "Zertifikat anzeigen"
Dort kann ich dann unter Details:
#Version
#Seriennummer
#Signaturalgorithmus
#Signaturhashalgorithmus
#Austeller
#Gültig ab
#Gültig bis
#Antragssteller
#Öffentlicher Schlüssel
#Fingerabdruckalgorithmus
#Fingerabdruck
einsehen
Dort steht nur immer meine domäne drin (www.domäne.de) und nichts was mir sonst irgendie helfen könnte
Dort steht nur immer meine domäne drin (www.domäne.de) und nichts was mir sonst irgendie helfen könnte
In Firefox unter Details >Layout > ...> Erweitert > CRL-Verteilungspunkte
Das ist halt jetzt sehr subjektiv weil die statischen Seiten auch nicht wirklich viel darstellen müssen,
Dann speicher dir von einer dynamisch generierten Seite das HTML und lad es hoch und ruf es auf...
Also ich versuche echt mich nicht völlig dämlich anzustellen aber in meinem Firefox gibt es die von dir beschriebenen Punkte nicht
Mit viel Fantasie interpretiere ich die "Details" als "Extras" -> "Erweitert" und komme irgendwann zum zum Punkt "Zertifikate anzeigen" aber dort habe ich noch nichts entdeckt was hilft.
Das mit dem Speichern der HTML Seite hat geklappt.
Das Ergebnis bestätigt meinen ersten Eindruck; statische Seiten sind ok nur dynamische machen Probleme.
PS: Vielleicht ist das nicht unwichtig.
Wenn ich die dynamische Seite speichere und dann statisch aufrufe von lokal sagt er sowas wie "das Anzeigen von Elementen mit Zertifikatsfehlern wurde aus Sicherheitsgründen geblockt"
Das mit dem Speichern der HTML Seite hat geklappt.
Das Ergebnis bestätigt meinen ersten Eindruck; statische Seiten sind ok nur dynamische machen Probleme.
PS: Vielleicht ist das nicht unwichtig.
Wenn ich die dynamische Seite speichere und dann statisch aufrufe von lokal sagt er sowas wie "das Anzeigen von Elementen mit Zertifikatsfehlern wurde aus Sicherheitsgründen geblockt"
Tante Google hat mir den Link hier offenbart
"http://www.rz.rwth-aachen.de/aw/cms/rz/Themen/unsere_dienste/kommunikation/sicherheit/zertifizierungsstelle/global/~sho/rwth_ca_-_global_policy_-_zertifikatsper/?lang=de"
Dem zu Folge kann es sich bei dem von Der von Dir erwähnten CRL-Url eigentlich nur um das hier handeln
und da ist bei mir gar nichts drin :/
"http://www.rz.rwth-aachen.de/aw/cms/rz/Themen/unsere_dienste/kommunikation/sicherheit/zertifizierungsstelle/global/~sho/rwth_ca_-_global_policy_-_zertifikatsper/?lang=de"
Dem zu Folge kann es sich bei dem von Der von Dir erwähnten CRL-Url eigentlich nur um das hier handeln
Mit Details meinte ich die Details vom Zertifikat.
Dafür klickst du auf den blauen Knubbel > Weitere Informationen > Sicherheit > Zertifikat anzeigen
Dafür klickst du auf den blauen Knubbel > Weitere Informationen > Sicherheit > Zertifikat anzeigen
Hallo,
so ins "blaue" erinnert mich das an eine Sache in der ....
Also die Webseite wurde aufgerufen um Daten anzuzeigen, bei der Anzeige im IE wurde für jedes Element eine DNS abfrage erzeugt, und die Elemente der Seite waren irgendwie mit dem TAG nicht Cachen versehen. Die Ladezeiten waren auch sehr extrem. Nachdem das umprogrammiert und im Apache/Tomcat angepasst wurde wars gut.
gruss ulti
so ins "blaue" erinnert mich das an eine Sache in der ....
Also die Webseite wurde aufgerufen um Daten anzuzeigen, bei der Anzeige im IE wurde für jedes Element eine DNS abfrage erzeugt, und die Elemente der Seite waren irgendwie mit dem TAG nicht Cachen versehen. Die Ladezeiten waren auch sehr extrem. Nachdem das umprogrammiert und im Apache/Tomcat angepasst wurde wars gut.
gruss ulti
Zitat von @dog:
Mit Details meinte ich die Details vom Zertifikat.
Dafür klickst du auf den blauen Knubbel > Weitere Informationen > Sicherheit > Zertifikat anzeigen
Mit Details meinte ich die Details vom Zertifikat.
Dafür klickst du auf den blauen Knubbel > Weitere Informationen > Sicherheit > Zertifikat anzeigen
wir kommen der Sache näher :P
Nach "Zertifikat anzeigen" bekomme ich einen Reiter "Allgemein" oder "Details"
Unter "Details" gibt es auch einen Punkt "Zertifikatslayout"
Dort habe ich dann :
www.domän.de
-Zertifikat
--Version
--Seriennummer
--Zertifikatsunterzeichnungs-Algorithmus
--Aussteller
Validität
--nicht vor
--nicht nach
Inhaber
Angaben zum öffentlichen Schlüssel des Inhabers
Public Key algorithmus des Inhabers
Öffentlicher Schlüssel des Inhabers
Zertifikatsunterzeichnus-Algorithmus
Signaturwert des Zertifikats
-Zertifikat
--Version
--Seriennummer
--Zertifikatsunterzeichnungs-Algorithmus
--Aussteller
Validität
--nicht vor
--nicht nach
Inhaber
Angaben zum öffentlichen Schlüssel des Inhabers
Public Key algorithmus des Inhabers
Öffentlicher Schlüssel des Inhabers
Zertifikatsunterzeichnus-Algorithmus
Signaturwert des Zertifikats
Kein "Erweitert" dort und keine "CRL-Verteilungspunkte"
Vielleicht hilfts ja trotzdem - dort wo eine Url drinsteht zB im Feld "Aussteller" taucht immer nur die Url meiner Domän auf und die ist natürlich erreichbar.
Etwas komisch ist allerdings das er mir bei dem Zertifikat im Reiter allgemein gleich sagt "Dieses Zertifikat konnte nicht verifiziert werden da dem Aussteller nicht vertaut wird"
Zitat von @ultiman:
Hallo,
so ins "blaue" erinnert mich das an eine Sache in der ....
Also die Webseite wurde aufgerufen um Daten anzuzeigen, bei der Anzeige im IE wurde für jedes Element eine DNS abfrage
erzeugt, und die Elemente der Seite waren irgendwie mit dem TAG nicht Cachen versehen. Die Ladezeiten waren auch sehr extrem.
Nachdem das umprogrammiert und im Apache/Tomcat angepasst wurde wars gut.
gruss ulti
Hallo,
so ins "blaue" erinnert mich das an eine Sache in der ....
Also die Webseite wurde aufgerufen um Daten anzuzeigen, bei der Anzeige im IE wurde für jedes Element eine DNS abfrage
erzeugt, und die Elemente der Seite waren irgendwie mit dem TAG nicht Cachen versehen. Die Ladezeiten waren auch sehr extrem.
Nachdem das umprogrammiert und im Apache/Tomcat angepasst wurde wars gut.
gruss ulti
Wie habt ihr das damals festgestellt mit den Dns queries?
Wie kann ich das bei mir prüfen?
Gut, dann haben wir jetzt mal die CRL ausgeschlossen.
Dann baust du jetzt mal an das statische HTML-Dokument von vorhin einen minimal dynamischen Teil dran (bei PHP z.B.
Wie verändert sich dann die Zeit?
Dann baust du jetzt mal an das statische HTML-Dokument von vorhin einen minimal dynamischen Teil dran (bei PHP z.B.
<?php echo "Hallo"; ?> und führst es aus.Wie verändert sich dann die Zeit?
Sollte das "Hallo" dann irgendwo auf der Seite auftauchen?
Wenn "Ja" dann habe ich was falsch gemacht (ich hab einfach <?php echo "Hallo"; ?> unten dran gehängt)
Wenn nein hat sich die Ladegeschwindigkeit der Seite lokal von meinem Rechner dadurch nicht verändert.
Wenn "Ja" dann habe ich was falsch gemacht (ich hab einfach <?php echo "Hallo"; ?> unten dran gehängt)
Wenn nein hat sich die Ladegeschwindigkeit der Seite lokal von meinem Rechner dadurch nicht verändert.
Welche Scriptsprache verwendst du für die dynamischen Seiten?
Was meinst du mit lokal?
Du musst die Datei natürlich (wie vorhin auch schon) in den Webordner packen und über die URL aufrufen.
Was meinst du mit lokal?
Du musst die Datei natürlich (wie vorhin auch schon) in den Webordner packen und über die URL aufrufen.
Zitat von @dog:
Welche Scriptsprache verwendst du für die dynamischen Seiten?
Was meinst du mit lokal?
Du musst die Datei natürlich (wie vorhin auch schon) in den Webordner packen und über die URL aufrufen.
Welche Scriptsprache verwendst du für die dynamischen Seiten?
Was meinst du mit lokal?
Du musst die Datei natürlich (wie vorhin auch schon) in den Webordner packen und über die URL aufrufen.
Da hängt Mantis dahinter, also ist das sogar PHP
Ja unglücklich formuliert . Ich hab die Seite ja vorhin lokal gespeichert und habe Sie natürlich im Browser aufgerufen.
Das kommt dabei raus wenn ich die Seitenaufrufe tracen lasse
0.2198 SQL Queries Total Time
13.3485 Page Request Total Time
daher bin ich mir eigentlich ziemlich sicher das die Problem definitv nicht von der DB kommen können.13.3485 Page Request Total Time
Sql ist nach 0,2 Minuten fertig mit allem.
0,2 Minuten
Sekunden.
Du könntest alle SQL-Abfragen mal mitloggen und die von Hand ausführen, dann siehst du ob es stimmt.
Ansonsten musst du jetzt einen Profiler auspacken, um zu gucken ob es an einer Funktion hängt.
Ich habe ja gerade Spotlight/Quest versucht, aber vom Hocker reißt es mich bis jetzt noch nicht.
Kannst du irgendeinen Profiler empfehlen für MySql?
Eigentlich ist es auch ziemlich wahrscheinlich das die DB ok ist, einfach weil da nicht genug passiert meiner Erfahrung nach was eine Datenbank schocken könnte (50 Mantisuser auf einer Datenbank sind für gewöhnlich nichts wildes) aber ich schau mal nach und dann kann ich das schon mal komplett ausschließen.
Wenn es nicht an https und nicht an der Datenbank liegt, werden die Punkte an denen man ansetzen kann langsam rar oder? ;{
Kannst du irgendeinen Profiler empfehlen für MySql?
Eigentlich ist es auch ziemlich wahrscheinlich das die DB ok ist, einfach weil da nicht genug passiert meiner Erfahrung nach was eine Datenbank schocken könnte (50 Mantisuser auf einer Datenbank sind für gewöhnlich nichts wildes) aber ich schau mal nach und dann kann ich das schon mal komplett ausschließen.
Wenn es nicht an https und nicht an der Datenbank liegt, werden die Punkte an denen man ansetzen kann langsam rar oder? ;{
Hallo,
da es es damals ein RedHat Webserver bei einem Provider war haben wir erstmal "mit dem Finder auf ihn gezeigt" er hat dann belegen können das es an der Programmierung lag. Hast du , wie ich vermute mal in das DNS.log geschaut was da passiert ?
http://technet.microsoft.com/de-de/library/cc776445%28WS.10%29.aspx
Ich hab jetzt nicht verstanden welcher Webserver die Daten anbietet, aber da müsste es doch auch einen debugmodus geben.
http://support.microsoft.com/kb/295070/de
http://support.microsoft.com/kb/954873/de
Ablaufverfolgung
http://technet.microsoft.com/de-de/library/cc787109(WS.10).aspx
ich bin da auch kein SUper Spezialist und habe gerade ähnliche Probleme mit CentOS PHP und MySQL unter SugarCRM
gruss
ulti der gut gefrühstückt hat
da es es damals ein RedHat Webserver bei einem Provider war haben wir erstmal "mit dem Finder auf ihn gezeigt" er hat dann belegen können das es an der Programmierung lag. Hast du , wie ich vermute mal in das DNS.log geschaut was da passiert ?
http://technet.microsoft.com/de-de/library/cc776445%28WS.10%29.aspx
Ich hab jetzt nicht verstanden welcher Webserver die Daten anbietet, aber da müsste es doch auch einen debugmodus geben.
http://support.microsoft.com/kb/295070/de
http://support.microsoft.com/kb/954873/de
Ablaufverfolgung
http://technet.microsoft.com/de-de/library/cc787109(WS.10).aspx
ich bin da auch kein SUper Spezialist und habe gerade ähnliche Probleme mit CentOS PHP und MySQL unter SugarCRM
gruss
ulti der gut gefrühstückt hat
Mit Profiler meinte ich auch PHP.
Dazu brauchst du Xdebug http://www.xdebug.org/
Den Profiler aktivierst du in der php.ini mit
Danach nimmst du KCachegrind (oder WinCacheGrind)
http://kcachegrind.sourceforge.net/html/Home.html
und guckst ob welche Funktion am längsten braucht...
Dazu brauchst du Xdebug http://www.xdebug.org/
Den Profiler aktivierst du in der php.ini mit
xdebug.profiler_enable 1
xdebug.profiler_output_dir "C:/irgendwo" http://kcachegrind.sourceforge.net/html/Home.html
und guckst ob welche Funktion am längsten braucht...
Zitat von @ultiman:
Hallo,
da es es damals ein RedHat Webserver bei einem Provider war haben wir erstmal "mit dem Finder auf ihn gezeigt" er hat
dann belegen können das es an der Programmierung lag. Hast du , wie ich vermute mal in das DNS.log geschaut was da passiert
?
http://technet.microsoft.com/de-de/library/cc776445%28WS.10%29.aspx
Ich hab jetzt nicht verstanden welcher Webserver die Daten anbietet, aber da müsste es doch auch einen debugmodus geben.
http://support.microsoft.com/kb/295070/de
http://support.microsoft.com/kb/954873/de
Ablaufverfolgung
http://technet.microsoft.com/de-de/library/cc787109(WS.10).aspx
ich bin da auch kein SUper Spezialist und habe gerade ähnliche Probleme mit CentOS PHP und MySQL unter SugarCRM
gruss
ulti der gut gefrühstückt hat
Hallo,
da es es damals ein RedHat Webserver bei einem Provider war haben wir erstmal "mit dem Finder auf ihn gezeigt" er hat
dann belegen können das es an der Programmierung lag. Hast du , wie ich vermute mal in das DNS.log geschaut was da passiert
?
http://technet.microsoft.com/de-de/library/cc776445%28WS.10%29.aspx
Ich hab jetzt nicht verstanden welcher Webserver die Daten anbietet, aber da müsste es doch auch einen debugmodus geben.
http://support.microsoft.com/kb/295070/de
http://support.microsoft.com/kb/954873/de
Ablaufverfolgung
http://technet.microsoft.com/de-de/library/cc787109(WS.10).aspx
ich bin da auch kein SUper Spezialist und habe gerade ähnliche Probleme mit CentOS PHP und MySQL unter SugarCRM
gruss
ulti der gut gefrühstückt hat
Hallo Ulli,
vielen Dank für die Antwort.
Ich werde das mal versuchen, allerdings kann ich DNS meiner Meinung nach fast ausschließen.
Ich hatte auch zuerst Probleme mit DNS vermutet.
Mein Webhoster hostet die öffentliche IP für das System und auch einen Apache.
Damit hier jedes Problem ausgeschlossen werden kann habe ich eine lokale Zone auf meinem Domänencontroller eingerichtet die alle Aufrufe von intern an die externe Domäne beantworten kann und lokal überschreibt für diesen Host.
Trotzdem werde ich das mal testen.
Gruß
Zitat von @dog:
Mit Profiler meinte ich auch PHP.
Dazu brauchst du Xdebug http://www.xdebug.org/
Den Profiler aktivierst du in der php.ini mit
Danach nimmst du KCachegrind (oder WinCacheGrind)
http://kcachegrind.sourceforge.net/html/Home.html
und guckst ob welche Funktion am längsten braucht...
Mit Profiler meinte ich auch PHP.
Dazu brauchst du Xdebug http://www.xdebug.org/
Den Profiler aktivierst du in der php.ini mit
> xdebug.profiler_enable 1
> xdebug.profiler_output_dir "C:/irgendwo"
> http://kcachegrind.sourceforge.net/html/Home.html
und guckst ob welche Funktion am längsten braucht...
Hi,
das teste ich mal durch und melde mich morgen noch mal.
Gruß und Danke
ps: Die Installation von XDebug ist aber auch alles andere als unkompliziert ;)
Zitat von @dog:
Mit Profiler meinte ich auch PHP.
Dazu brauchst du Xdebug http://www.xdebug.org/
Den Profiler aktivierst du in der php.ini mit
Danach nimmst du KCachegrind (oder WinCacheGrind)
http://kcachegrind.sourceforge.net/html/Home.html
und guckst ob welche Funktion am längsten braucht...
Mit Profiler meinte ich auch PHP.
Dazu brauchst du Xdebug http://www.xdebug.org/
Den Profiler aktivierst du in der php.ini mit
> xdebug.profiler_enable 1
> xdebug.profiler_output_dir "C:/irgendwo"
> http://kcachegrind.sourceforge.net/html/Home.html
und guckst ob welche Funktion am längsten braucht...
Ok ich komm genau bis punkt 4 bei der XDebugInstalltion.
Dann soll ich "phpize" eingeben und ernte ein "Command not found"
Ich gebe in / ein "phpize --help" und erhalte wieder "Command not found".
Ok dann gehe ich vor wie in dem Link vorgegeben http://www.xdebug.org/docs/faq#custom-phpize
und suche finde ein /etc/php5 , dort findet sich aber auch keine anwendung für phpize.
Auch eine Php-Config suche ich auf dem kompletten Filesystem mit der Suche vergebens.
Da du Windows benutzt kannst du XDebug nicht selbst kompilieren, du musst das fertige Build herunterladen.
Die gibt es unter http://www.xdebug.org/download.php "Windows binaries" für jede PHP-Version passend.
Die gibt es unter http://www.xdebug.org/download.php "Windows binaries" für jede PHP-Version passend.
Zitat von @dog:
Da du Windows benutzt kannst du XDebug nicht selbst kompilieren, du musst das fertige Build herunterladen.
Die gibt es unter http://www.xdebug.org/download.php "Windows binaries" für jede PHP-Version passend.
Da du Windows benutzt kannst du XDebug nicht selbst kompilieren, du musst das fertige Build herunterladen.
Die gibt es unter http://www.xdebug.org/download.php "Windows binaries" für jede PHP-Version passend.
Das System mit den Problemen ist ein Ubuntu 8.04 LTS,
hier läuft auch die Mysql Datenbank und Mantis.
Ich bin jetzt nicht sicher ob das PHP dort auch zusammengeschustert wird, aber eigentlich müsste es das dann doch oder?
zumindest das Verzeichnis /etc/php5 ist auch vorhanden und ein Apache2 läuft auch dort.
Für Ubuntu gibt es eine Anleitung: http://ubuntuforums.org/showthread.php?t=525257
Sieht so aus als will Kachegrind das ich KDE 3.x installiere.
Ich benutze Gnome und frage nun ganz unbedarft - beisst sich da nichts wenn ich Kde über den Packetmanager nachinstalliere?
Wenn du das über den Paketmanager machst sollte das schon gehen, aber du kannst die Datei auch auf Windows kopieren und das Windows-Programm benutzen.
Zitat von @dog:
Wenn du das über den Paketmanager machst sollte das schon gehen, aber du kannst die Datei auch auf Windows kopieren und das
Windows-Programm benutzen.
Wenn du das über den Paketmanager machst sollte das schon gehen, aber du kannst die Datei auch auf Windows kopieren und das
Windows-Programm benutzen.
hm
wie soll ich das denn machen?
Er bietet mir auf der Downloadepage nur einen tarball, der zB ein Install.sh Skript stellt.
Das wird doch schwierig unter Windows oder nicht ...?
Nein, du sollst die Ausgabedatei von Xdebug auf Windows kopieren und dort WinCacheGrind benutzen.
Zitat von @dog:
Nein, du sollst die Ausgabedatei von Xdebug auf Windows kopieren und dort WinCacheGrind benutzen.
Nein, du sollst die Ausgabedatei von Xdebug auf Windows kopieren und dort WinCacheGrind benutzen.
Ich hab schon kurz gedacht eine Entwicklung wäre an mir vorbeigegangen ;)
Zitat von @dog:
Nein, du sollst die Ausgabedatei von Xdebug auf Windows kopieren und dort WinCacheGrind benutzen.
Nein, du sollst die Ausgabedatei von Xdebug auf Windows kopieren und dort WinCacheGrind benutzen.
XDebug ist noch widerspenstig.
Es gibt mir keine Logdatei obwohl das mit der Installation scheinbar geklappt hat.
Das habe ich in die /etc/php5/apache2/php.ini geschrieben
xdebug.profiler_enable 1
xdebug.profiler_output_dir "/home/Schnappauf/Desktop/XDEBUG"
*stirnrunzel*
Die Einträge in der php.ini hast du aber gemacht?
Standardmäßig landen die Dateien in
Standardmäßig landen die Dateien in
/var/tmp/cachegrind.xxxZitat von @dog:
Die Einträge in der php.ini hast du aber gemacht?
Standardmäßig landen die Dateien in
Die Einträge in der php.ini hast du aber gemacht?
Standardmäßig landen die Dateien in
/var/tmp/cachegrind.xxxJa in var/tmp ist nichts drin :{
PS: Moment ... Xdebug habe ich auf der Ubuntukiste installiert.
Bei Cachegrind gab es doch das Problem das ich KDE installieren musste , daraufhin habe ich Wincachegrind auf einen Windowsclient gelegt.
Sollte ich dann nicht auf der Ubuntukiste nach XDEBUGlogs suchen?
Dann guck in die
Da steht ob Xdebug Profiling aktiv ist und wohin.
Apache muss natürlich auch nach Änderungen an der php.ini neugestartet werden.
phpinfo().Da steht ob Xdebug Profiling aktiv ist und wohin.
Apache muss natürlich auch nach Änderungen an der php.ini neugestartet werden.
Zitat von @dog:
Dann guck in die
Da steht ob Xdebug Profiling aktiv ist und wohin.
Apache muss natürlich auch nach Änderungen an der php.ini neugestartet werden.
Dann guck in die
phpinfo().Da steht ob Xdebug Profiling aktiv ist und wohin.
Apache muss natürlich auch nach Änderungen an der php.ini neugestartet werden.
Apache wurde natürlich gleich neu gestartet
Hier ein Auszug von phpinfo()
phpinfo() PHP Version => 5.2.4-2ubuntu5.12 System => Linux Rechnername.de 2.6.24-28-generic #1 SMP Wed Nov 24 09:30:14 UTC 2010 i686 Build Date => Sep 20 2010 13:15:27 Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => /etc/php5/cli Loaded Configuration File => /etc/php5/cli/php.ini Scan this dir for additional .ini files => /etc/php5/cli/conf.d additional .ini files parsed => /etc/php5/cli/conf.d/mysql.ini, /etc/php5/cli/conf.d/mysqli.ini, /etc/php5/cli/conf.d/pdo.ini, /etc/php5/cli/conf.d/pdo_mysql.ini, /etc/php5/cli/conf.d/xdebug.ini PHP API => 20041225 PHP Extension => 20060613 Zend Extension => 220060519 Debug Build => no Thread Safety => disabled Zend Memory Manager => enabled IPv6 Support => enabled Registered PHP Streams => zip, php, file, data, http, ftp, compress.bzip2, compress.zlib, https, ftps Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls Registered Stream Filters => string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.*, bzip2.*, zlib.* This server is protected with the Suhosin Patch 0.9.6.2 Copyright (c) 2006 Hardened-PHP Project This program makes use of the Zend Scripting Language Engine: Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
Das meine ich nicht.
xdebug.profiler_output_dir => /tmp => /tmp
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.trace_output_dir => /tmp => /tmp
xdebug.trace_output_name => trace.%c => trace.%c
aber in tmp find ich nichts das cachegrind.out* heisst
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.trace_output_dir => /tmp => /tmp
xdebug.trace_output_name => trace.%c => trace.%c
aber in tmp find ich nichts das cachegrind.out* heisst
Entscheidend ist auch profile_enable oder profile_enable_trigger (in dem Fall musst du ?XDEBUG_PROFILE an die URL anhängen).
Zitat von @dog:
Entscheidend ist auch profile_enable oder profile_enable_trigger (in dem Fall musst du ?XDEBUG_PROFILE an die URL anhängen).
Entscheidend ist auch profile_enable oder profile_enable_trigger (in dem Fall musst du ?XDEBUG_PROFILE an die URL anhängen).
habs gerade gemerkt.
Da liegt der Hase im Pfeffer
xdebug.profiler_enable => Off => Off
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_enable_trigger => Off => Off
Zitat von @Rico55:
> Zitat von @dog:
> ----
> Entscheidend ist auch profile_enable oder profile_enable_trigger (in dem Fall musst du ?XDEBUG_PROFILE an die URL
anhängen).
habs gerade gemerkt.
Da liegt der Hase im Pfeffer
>xdebug.profiler_enable => Off => Off
>xdebug.profiler_enable_trigger => Off => Off
> Zitat von @dog:
> ----
> Entscheidend ist auch profile_enable oder profile_enable_trigger (in dem Fall musst du ?XDEBUG_PROFILE an die URL
anhängen).
habs gerade gemerkt.
Da liegt der Hase im Pfeffer
>xdebug.profiler_enable => Off => Off
>xdebug.profiler_enable_trigger => Off => Off
Eigentlich alles richtig gemacht glaube ich.
In meiner /etc/php5/apache2/php.ini
stehen die letzten 3 Zeilen die ich eingefügt habe dort
zend_extension="/usr/lib/php/20060613+lfs/xdebug.so"
xdebug.profiler_enable 1
xdebug.profiler_output_dir "/home/Schnauppauf/XDEBUG"
xdebug.profiler_enable 1
xdebug.profiler_output_dir "/home/Schnauppauf/XDEBUG"
Da gehört ein
= zwischen Zitat von @dog:
Den Profiler aktivierst du in der php.ini mit
Den Profiler aktivierst du in der php.ini mit
> xdebug.profiler_enable 1
> xdebug.profiler_output_dir "C:/irgendwo"
> :P
ok dann versuchen wir das mal ;)
Zitat von @Rico55:
> Zitat von @dog:
> Den Profiler aktivierst du in der php.ini mit
>
:P
ok dann versuchen wir das mal ;)
> Zitat von @dog:
> Den Profiler aktivierst du in der php.ini mit
>
> > xdebug.profiler_enable 1
> > xdebug.profiler_output_dir "C:/irgendwo"
> > :P
ok dann versuchen wir das mal ;)
zend_extension="/usr/lib/php5/20060613+lfs/xdebug.so"
xdebug.profiler_enable=1
xdebug.profiler_output_dir="/home/Schnappauf/XDEBUG"
xdebug.profiler_output_name="timestamp"
Ergebnis:
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => Off => Off
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_output_dir => /tmp => /tmp
*seufz*
okaaaaay
statt das hier
in die /etc/php5/apache2/php.ini zu schreiben habe ich es nun in die /etc/php5/cli/php.ini geschrieben und siehe da auf einmal steht der profiler auf ON.
*kopfkratz*
statt das hier
zend_extension="/usr/lib/php5/20060613+lfs/xdebug.so"
xdebug.profiler_enable=1
xdebug.profiler_output_dir="/home/Schnappauf/XDEBUG"
xdebug.profiler_output_name="timestamp"
xdebug.profiler_enable=1
xdebug.profiler_output_dir="/home/Schnappauf/XDEBUG"
xdebug.profiler_output_name="timestamp"
in die /etc/php5/apache2/php.ini zu schreiben habe ich es nun in die /etc/php5/cli/php.ini geschrieben und siehe da auf einmal steht der profiler auf ON.
*kopfkratz*
Original so aus einem "php phpinfo.php > php.txt"
Trotzdem keine Logs in /home/Schnappauf/XDEBUG
xdebug.profiler_enable => On => On
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_output_dir => /home/Schnappauf/XDEBUG => /home/Schnappauf/XDEBUG
xdebug.profiler_output_name => timestamp => timestamp
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_output_dir => /home/Schnappauf/XDEBUG => /home/Schnappauf/XDEBUG
xdebug.profiler_output_name => timestamp => timestamp
Trotzdem keine Logs in /home/Schnappauf/XDEBUG
Xdebug reinstalliert und die Php5-dev's aber keine Änderung des Zustands.
Ok irgendwie klappt das nicht Xdebug, keine Ahnung warum.
Nochmal zurück zu den anderen potentiellen Fehlerquellen.
Ich habe immer wenn ich die https: Seite des Servers aufrufe eine rote Url im Browser (zertifikatsfehler usw)
Bekomme ich das irgendwie weg?
Der Server steht bei uns im Netz und geht dann über unseren Webhoster ins Internet
Ich vermute die Url ist rot weil die Domäne des Webhosters keine vetrauenswürdige Zone ist?
was muss ich da genau tun?
Gruß
Nochmal zurück zu den anderen potentiellen Fehlerquellen.
Ich habe immer wenn ich die https: Seite des Servers aufrufe eine rote Url im Browser (zertifikatsfehler usw)
Bekomme ich das irgendwie weg?
Der Server steht bei uns im Netz und geht dann über unseren Webhoster ins Internet
Ich vermute die Url ist rot weil die Domäne des Webhosters keine vetrauenswürdige Zone ist?
was muss ich da genau tun?
Gruß
Nochmal zurück zu den anderen potentiellen Fehlerquellen.
Es gibt keine anderen mehr, die hast du mit der statischen Testdatei ausgeschlossen.
Bekomme ich das irgendwie weg?
Zertifikat als vertrauenswürdig hinzufügen.
Geht das auch Domänenweit irgendwie ohne eine eigene CA hochzuziehen?
ps: ok das heißt dann wohl ich probier XDebug so lange bis es irgendwann funktioniert :{
Ich hoffe es klappt irgendwie.
ps: ok das heißt dann wohl ich probier XDebug so lange bis es irgendwann funktioniert :{
Ich hoffe es klappt irgendwie.
Zertifikate lassen sich über Gruppenrichtlinien verteilen und mit XDebug hatte ich noch nie Probleme.
Da ich keinen Fortschritt erzielen konnte habe ich das System nun neu aufgesetzt.
Die logs sollten in /home/test1 liegen richtig?
Die logs sollten in /home/test1 liegen richtig?
Die logs sollten in /home/test1 liegen richtig?
Wenn der Prozess da schreiben kann, ja.
ich habe dem Ordner ein chmod +a rwx (nun drwxrwxrwx) spendiert und trotzdem gibts keine logs :{
Ich habe keine Ahnung, was du falsch machst.
Am Besten du veränderst mal nicht
Am Besten du veränderst mal nicht
output_dir und output_name und setzt xdebug.profiler_enable_trigger = 1 und rufst dann die URL mit ?XDEBUG_PROFILE auf
