Sonstiges

Timeout-Probleme bei Plugins

Frage: bei manchen Plugins bekommt man es hin und wieder mit Timeout-Problemen zu tun. Das macht sich idR so bemerkbar: aktiviere ich das Plugin und nutze dann das entsprechende Menue im Admin-Bereich, ploppt der Download-Manager hoch und bietet mir eine .php-Datei zum Download an. Das passiert wann? Tja, sobald das Plugin irgendwelche Daten auslesen will und es wohl zu lange dauert. Bei den meisten Plugins läuft das prima, aber bspw. bei Michaels neuem Simple-Tagging oder diesem hier kommt das Problem.

Wo liegt da Kernproblem? Warum klappt das mit manchen Plugins, bei anderen wiederum nicht (obwohl beide Typen vom Grundprinzip manchmal mehrere tausend Datensätze durchwühlen und verknüpfen müssen)? Ist doch bestimmt ne Einstellung in der php-ini oder?

Einstellung:
max_execution_time 30 30
oder ist das ein anderes Overflow-Problem?


Neue Stellenangebote

Growth Marketing Manager:in – Social Media
GOhiring GmbH in Homeoffice
Praktikum im Bereich interne Kommunikation und Social Media
BOS GmbH & Co. KG in Ostfildern bei Stuttgart
Praktikum (m/w/d) Projektmanagement Social Media ab Januar 2025
CEWE Stiftung & Co. KGaA in Oldenburg

Alle Stellenanzeigen


Über den Autor

Robert Basic

Robert Basic ist Namensgeber und Gründer von BASIC thinking und hat die Seite 2009 abgegeben. Von 2004 bis 2009 hat er über 12.000 Artikel hier veröffentlicht.

12 Kommentare

  • Da ich zufällig anscheinend betroffen bin, würden mich eventuelle Antworten natürlich brennend interessieren. Und nebenbei: Das Plugin wird in Kürze so geändert, dass das angesprochene Problem nicht mehr auftreten sollte. Der Chart wird dann nur bei einem neuen Post oder Kommentar neu generiert und der Output in eine Bilddatei geschrieben, die man überall einbinden kann. So muss der Chart nicht bei jedem Zugriff neu generiert werden…

  • Ergänzung: Falls das Problem von der umfangreichen SQL-Abfrage herrührt, ist es vielleicht gar nicht so clever, das bei jedem Kommentar laufen zu lassen. Vielleicht greife ich dann doch besser auf den Cron-Mechanismus von WordPress zurück.
    Anyway: Ich bin gespannt auf mögliche Lösungsansätze…

  • Lösung hab‘ ich akkut keine, an ein Timeoutproblem glaube ich aber nicht, da das normalerweise nicht mit dem Download der php-Datei quittiert wird.

  • Erhöhe doch einfach mal die max_execution_time, dann kannst du zumindest schon mal diese Vermutung ausschliessen bzw. bestätigen.

    In der den Import ausführenden Datei, folgende Zeile im Headbereich einfügen:

    ini_set(„max_execution_time“, „90“);

    Der 2. parameter ist in Sekunden, kannst ja beliebig anpassen, defaultwert ist 30.
    Geht aber nur, wenn php nicht im safemode
    läuft. Ein Versuch ist es allemal wert. Evt. hat dein Provider auch einfach ein Skriptlaufzeit limit. Das ist durchaus üblich, Einflus darauf hat man allerdings nicht.

  • Wenn der Effekt umgehend auftritt, dann liegt es nicht zwangsweise am Script. Sondern das Script wird (warum auch immer) nicht von PHP geparst.
    Den gleichen Effekt erzielst du wenn du in der httpd-conf den Application-Type änderst/löscht (AddType application/x-httpd-php .php)
    In dieser Zeile kannst du auch noch .html angeben, dann werden auch alle html-Dateien von PHP verarbeitet bevor sie an den Browser geschickt werden.

    Von daher tippe ich mal eher auf ein Serverproblem. Anscheinend werden die PHP-Dateien nicht verarbeitet, sondern direkt zum Browser geschickt. Das wiederum könnte daran liegen, dass der Server mit der Verarbeitung des PHP-Scripts nicht rechtzeitig fertig wird weil er zu viel mit anderen Dingen (z.B. MySQL) zu tun hat.
    Versuch lieber mal den KeepAliveTimeout runter zu setzen.

  • Den Effekt kenne ich nur zu gut, weiß aber leider auch nicht was das verursacht. Ich weiß nur, dass ein Neustart (nicht reload) von Apache immer geholfen hat.

    Ich bin auch an Tipps interessiert … denn bei mir tritt das ab und zu sogar in der ganz normalen Adminoberfläche von WordPress auf. Ich will keine leere php-datei zum Download angeboten bekommen 😉