[StefanT]

Nachdem es immer noch nicht sauber zeitgerecht funktionierte habe ich in der ./task.php die Zeile

PHP-Code:

if($task['locked'] != 0 && $task['locked'] > TIME_NOW-300) 


zu

PHP-Code:

in if($task['locked'] != 0 && $task['locked'] > TIME_NOW-1) 


Was willst du mit der Änderung bezwecken? Es ist wichtig, das Aufgaben nicht parallel ausgeführt werden, denn dieses kann zu Race-Conditions und schwerwiegenden Fehlern führen. Der originale Wert von 5 Minuten ist dabei gut gewählt, für aufwendige Aufgaben sogar schon fast zu kurz. Eine Sekunden ist viel zu kurz für eine korrekte Funktionsweise.

1. Wird der Task Send Mail Queue ausgeführt, wird im Logfile immer "Es wurden 10 E-Mails aus der Warteschlange versendet." angezeigt. Dies obwohl definitiv keine Mails (welche auch, ist ja das Testforum) versendet wurden.
Was ist da wo inkorrekt definiert?

Es wir nur geloggt, wie viele E-Mails gesendet werden können. Die tatsächliche Anzahl wird nicht ermittelt.

2. Task Datenbank optimieren (Quelle: hier (Autor = StefanT)
die Datenbank (gehostet bei Webgo) zeigt immer wieder auf, das einige Tabellen nicht optimiert sind.

Ist das schlimm? In einer produktiven Datenbank wird nun einmal gearbeitet und nicht optimiert. Du kannst (und willst) ja nicht nach jeder Änderung neu optimieren. MySQL ist eigentlich sehr gut darin die Datenbanken zu verwalten, da braucht man in der Regel nicht regelmäßig eingreifen.

[Gerti]

Danke für die Hinweise.

Eine Sekunden ist viel zu kurz für eine korrekte Funktionsweise.

Ops, ist durchaus ein Fehler meinerseits. Dachte in Minuten statt Sekunden.

Es wir nur geloggt, wie viele E-Mails gesendet werden können. Die tatsächliche Anzahl wird nicht ermittelt.

Können? Die zugehörige Textvariable lautet doch "Es wurden {1} E-Mails aus der Warteschlange versendet." Wurde bedeute doch unstrittig das etwas ausgeführt wurde (Ausführung in der Vergangenheit) und nicht könnte (Ausführung in der Zukunft). Irgendetwas ist da nicht in sich schlüssig, lerne aber gerne dazu.

Ist das schlimm? In einer produktiven Datenbank wird nun einmal gearbeitet und nicht optimiert. Du kannst (und willst) ja nicht nach jeder Änderung neu optimieren. MySQL ist eigentlich sehr gut darin die Datenbanken zu verwalten, da braucht man in der Regel nicht regelmäßig eingreifen.

das mag ja alles sein, aber
a) warum hast Du dann damals für einen User den Cronjob erstellt?
b) möchte die beiden Tasks nicht anhaltend, sondern maximal einmal täglich ausführen
c) unabhängig ob sinnvoll oder nicht, funktionieren sollten die von Dir erstellten Cronjobs doch
Somit war Deine Ausführungen zwar Informativ (besten Dank dafür), stellt jedoch inhaltlich keine Antwort auf die gestellte Frage dar.

[StefanT]

Ops, ist durchaus ein Fehler meinerseits. Dachte in Minuten statt Sekunden.

Eine Aufgabe ist nur dann gesperrt, wenn sie gerade ausgeführt wird. Daher ist auch eine Verringerung auf eine Minute nicht sinnvoll.

Können? Die zugehörige Textvariable lautet doch "Es wurden {1} E-Mails aus der Warteschlange versendet." Wurde bedeute doch unstrittig das etwas ausgeführt wurde (Ausführung in der Vergangenheit) und nicht könnte (Ausführung in der Zukunft). Irgendetwas ist da nicht in sich schlüssig, lerne aber gerne dazu.

Die Meldung kommt auch, wenn die Warteschlange leer ist. Der Informationswert dieser Meldung ist daher eher begrenzt.

das mag ja alles sein, aber
a) warum hast Du dann damals für einen User den Cronjob erstellt?
b) möchte die beiden Tasks nicht anhaltend, sondern maximal einmal täglich ausführen
c) unabhängig ob sinnvoll oder nicht, funktionieren sollten die von Dir erstellten Cronjobs doch
Somit war Deine Ausführungen zwar Informativ (besten Dank dafür), stellt jedoch inhaltlich keine Antwort auf die gestellte Frage dar.

a) Warum sollte ich das nicht machen, wenn es explizit gewünscht ist? Das heißt nicht, dass es sinnvoll oder empfohlen ist.
b) In der MySQL-Dokumentation werden die Use-Cases von OPTIMIZE genannt. In einem durchschnittlichen Forum hast du weder "substantial insert, update, or delete operations" noch löschst du "large part[s]" von Tabellen; jedenfalls nicht täglich.
c) Mit den damaligen Versionen hat er das vermutlich auch, das ist immerhin 12 Jahre her.

PHP-Code:

$db->optimize_table('posts'); 


sollte allerdings auch heute noch funktionieren. Wenn nicht liegt der Fehler irgendwo anders.

[Gerti]

Die Meldung kommt auch, wenn die Warteschlange leer ist. Der Informationswert dieser Meldung ist daher eher begrenzt.

Naja, wenn schon Werte mit angegeben werden wird sich jemand mal dazu Gedanken gemacht haben. Vermute mal dass die Sprachvariabe (Wert) nicht mehr gegeben ist. Somit nur ein Hinweis, dass Mails versendet werden könnten, aber keien gegeben sind.

Für Deine Erläuterungen der Themen besten Dank.

[Juventiner]

b) In der MySQL-Dokumentation werden die Use-Cases von OPTIMIZE genannt. In einem durchschnittlichen Forum hast du weder "substantial insert, update, or delete operations" noch löschst du "large part[s]" von Tabellen; jedenfalls nicht täglich.
c) Mit den damaligen Versionen hat er das vermutlich auch, das ist immerhin 12 Jahre her.

PHP-Code:

$db->optimize_table('posts'); 


sollte allerdings auch heute noch funktionieren. Wenn nicht liegt der Fehler irgendwo anders.

Funktionier auch, so lange die Tabellen nicht als InnoDB angelegt sind - was an sich auch kein Problem ist. InnoDB gibt zumindest keinen freien Speicher frei und optimiert nur die Tabellen. Das nur als Ergänzung soweit.

[StefanT]

Ja, es gibt da deutliche Unterschiede zwischen MyISAM und InnoDB. Aber der SQL-Befehl ist ja trotzdem genau gleich?