Sind hier PHP'ler unterwegs?

[Hanzo2012]

Unmöglich ist es natürlich nicht, man müsste halt die Funktion entsprechend umbauen, so dass sie beim Abarbeiten immer wieder neu entscheidet, wie viele Threads genutzt werden. Oder von vornherein die Funktion nicht mit allen URLs füttern, sondern häppchenweise (z. B. immer in Blöcken von 100 URLs arbeiten), und jedes Mal die Anzahl der Threads festlegen und übergeben. Gibt viele Möglichkeiten.

[supervisior]

Das entspricht aber wesentlich gegen die Multi-Threading Funktionsweise oder bremst es zumindest aus. Ich werd' Morgen mal was austesten. Nur eine Idee, muss aber erstmal getestet werden.

[Hanzo2012]

In diesem Fall (so wie ich das verstehe, wie Multi-cURL in PHP funktioniert) werden ohnehin ständig neue Threads erzeugt und wieder beendet, also macht das nix.

[supervisior]

Also ich glaube jetzt zu wissen wie LiteSpeed das macht. Grundsätzlich wird auch hier php-curl verwendet und entspricht in der Funktionsweise wie ich das mache. Das fallweise reduzieren der gleichzeitigen Threads, wenn ein vorgegebener Wert überschritten wird, ist aber keine PHP oder cURL Funktion. LSWS hat dafür eine eigene Funktion und die ist an einen bestimmten UA gekoppelt. Den könnte ich zwar auch verwenden und hatte ich früher schon mal in Zusammenhang mit anderen Funktionen, aber nachdem sich bei mir der UA fallweise ändert und ich genau diese UAs brauche, kann ich diese serverseitige Funktion nicht nutzen. Allerdings und das müsste ich mal ausprobieren, könnte ich diesen besagten UA in meine UAs integrieren. Ist ja nur 1 Wort und würde meine Funktion nicht beeinträchtigen.

[supervisior]

In diesem Fall (so wie ich das verstehe, wie Multi-cURL in PHP funktioniert) werden ohnehin ständig neue Threads erzeugt und wieder beendet, also macht das nix.

Es macht tatsächlich nix. Ich habe nun eine Lösung gefunden, die gleich noch ein anderes Problem gelöst hat. Eigentlich war dafür nur ein 2-Zeiler notwendig, sodass es jetzt auch möglich ist die Zahl der max. gleichzeitigen Threads on-the-fly zu reduzieren, wenn nötig.

[supervisior]

Um dieses Thema noch etwas zu bereichern, hier noch eine Ergänzung. Nachdem ich das Script nun nahezu perfektioniert habe und hinreichend im Einsatz ist, konnte ich jetzt auch einiges an Erfahrungen sammeln. Mit den Erfahrungen verbinden sich auch Probleme, die ich aber nur bedingt verallgemeinern kann. Gemeint sind damit Probleme mit MySQL, bzw. MySQL und MyISAM Engine, sodass es in regelmäßigen Abständen zu Fehlern bei der Datenbank Verbindung kommt und MySQL moniert, dass Daten Pakete nicht gelesen werden konnten und deswegen die Verbindung abgebrochen wurde.

Nach langem Austesten und debuggen, kann ich den besagten Fehler fast vollständig ausschließen, wenn ich die cURL Options anpasse und CURLOPT_NOBODY auf false stelle. Was sich mir dabei aber nicht erschließt, ist was es mit dem Body auf sich hat, wenn dieser nicht zurückgegeben wird, bzw. warum der fehlende Body zu dem MySQL Error führt.

[Hanzo2012]

Vielleicht überlastest du deine Netzwerkverbindung, wenn die Bodys mit übertragen werden.

[supervisior]

CURLOPT_NOBODY => false bedeutet doch, dass der Body übertragen wird und wenn false, also mit body, gibts keine Errors. Das ist ja das paradoxe....

[Hanzo2012]

Hatte es gerade selbst gemerkt

[nerd]

Wie baust du deine mysql verbindung auf? Nutzt du ein framework oder plain PHP? Welchen zeichensatz hast du in deiner DB table, DB-verbindung und in PHP eingestellt?

[supervisior]

Wie baust du deine mysql verbindung auf? Nutzt du ein framework oder plain PHP? Welchen zeichensatz hast du in deiner DB table, DB-verbindung und in PHP eingestellt?

Das ist PHP Freestyle, aber mit PHP hat das zunächst mal wenig zu tun. Bei der besagten Funktion geht's im Wesentlichen nur um cURL. Dafür wird zwar PHP cURL verwendet, aber wer hier rumzickt ist MySQL. Nicht generell, aber im Durchschnitt bei jedem 20 bis 30 HTTP Request gibt es einen Error in der mysql_error_log, dass die DB Verbindung abgebrochen wurde, weil Daten Pakete nicht gelesen werden konnten, jedoch ohne dass es dadurch irgendwelche funktionellen Konsequenzen gibt. Auf nahe 0 Fehler lässt es sich bringen, wenn ich bei den cURL Parametern angebe, dass der Body zurückgegeben werden soll. Das führt unweigerlich dazu, dass die Menge der gleichzeitigen cURL Requests eingebremst werden, weil cURL eine systemimmanente Bremse hat, die sich nicht verbiegen lässt. Ich kann deswegen nur vermuten, dass es MySQL bei der Nutzung der MyISAM Engine einfach zu schnell geht. Wir reden hier ja um eine bis zu 6-stellige Anzahl an HTTP Requests pro Stunde.

[nerd]

Ich frage nur, weil man bei php-mysql systemen mehrmals das richtige und gleiche charset angeben muss:

- in php beim einstellen der verbindungsparameter
- mit dem mysql comman SET NAMES 'utf8mb4' als erster befehl nach verbindungsaufbau
- in Mysql in den einzelnen tables

ich nutze immer charset: utf8mb4 / collation: utf8mb4_unicode_ci - damit kann man alle internationalen zeichsaetze sowie emojis korrekt speichern.

Wenn man oben was vergisst kann es sein das eingaben nicht richtig gespeichert werden, weil MySQL meint es muesste irgendwelche charsets intern konvertieren.

[Hanzo2012]

Das mag ja alles sein, aber das erklärt doch nicht sein Problem. Da kannst du ihm genauso raten die Festplatte zu defragmentieren

[nerd]

Das mag ja alles sein, aber das erklärt doch nicht sein Problem.

Nicht?

Gemeint sind damit Probleme mit MySQL, bzw. MySQL und MyISAM Engine, sodass es in regelmäßigen Abständen zu Fehlern bei der Datenbank Verbindung kommt und MySQL moniert, dass Daten Pakete nicht gelesen werden konnten und deswegen die Verbindung abgebrochen wurde.
Nach langem Austesten und debuggen, kann ich den besagten Fehler fast vollständig ausschließen, wenn ich die cURL Options anpasse und CURLOPT_NOBODY auf false stelle. Was sich mir dabei aber nicht erschließt, ist was es mit dem Body auf sich hat, wenn dieser nicht zurückgegeben wird, bzw. warum der fehlende Body zu dem MySQL Error führt.

Falsche charsets setzten kann schnell passieren wenn man kein framework benutzt was das fuer dich tut. Es kann auch sein dass bestimmte daten nicht mehr in eng definierte spalten passen, weil du bei utf8-mb4 Multibyte character hast, womit ein feld oder index was z.b. fuer char(60) definiert ist in wirklichkeit laenger als 60 bytes wird.
Es sind auch sonst keine infos gegeben wie die tabelle definiert ist, welche config benutzt wird oder wie mysql bei zu langen daten reagieren soll.

[supervisior]

@nerd

Ich weiß Du willst nur was positives beitragen, aber mit dem charset dingens bist Du mind. 1 Lichtjahr von der Thematik entfernt. Deinem Verweis mit dem charset könnte man sicherlich nachgehen, aber wir reden hier nur von 1 einzigen DB Query, der URLs aus der DB holt. Von da an gibt es über das besagte Script keinen direkten Datenbank Zugriff mehr, weil nur mehr noch cURL HTTP Requests erzeugt und nur diese HTTP Requests erzeugen beim Aufruf Errors in der Datenbank.

Die besagten Errors treten aber nicht nur bei der Nutzung dieses Scripts auf, sondern auch im Regelbetrieb, wenngleich nur sporadisch. Wenn ich vorher wegen der Fülle an errors auf MyISAM fixiert war, scheint auch Innodb betroffen zu sein, aber eben noch zählbar. Diese Errors konnte ich inzwischen sehr stark reduzieren, weil ich beim Debuggen festgestellt habe, dass es den Applikationen, die MyISAM nutzen an Indizes fehlte. Das hat die Fehlerrate um min. 70% reduziert. Die Fehler sind also in gewisser Hinsicht fast immer nur 1 Applikation zuzuschreiben, aber nur fast.

Ich hab auch mit unterschiedlichen MySQL Settings herumexperimentiert, haben aber nur die Erkenntnis gebracht, dass MySQL nicht so perfekt konfiguriert werden kann, dass MyISAM und Innodb die jeweils besten Einstellungen bekommen. Bei einem Mischbetrieb beider Engines kann man nur einen Kompromiss finden und Komprimisse bringen immer Nachteile mit sich.

Was ich aber auch herausgefunden habe, ist dass das Multi-Threading Script und wenn man den body mit zurückgeben lässt einen exorbitanten Speicherverbrauch hat. Es scheint wohl so zu sein, dass die Daten aus dem Fetching des Bodys solange im RAM vorgehalten werden bis alle URLs abgerufen sind. Und da kommt einiges an Daten zusammen. Ich kann meine max_memory Settings zwar fast unbegrenzt hochschrauben, aber idealer wäre es, wenn die Daten nicht im RAM gehalten werden würden, sondern in /tmp gespeichert werden würden.