Cronjobs: Nicht öfter als nötig

So ein Cronjob ist eine feine Sache. Regelmäßig wird nachgeschaut, ob es was für ihn zu tun gibt; und das nicht nur auf der lokalen Platte, sondern problemlos auch auf einem Server am anderen Ende der Welt. Per FTP, HTTP, SCP, POP3 oder IMAP, usw.

Im Prinzip können Sie alle fünf Sekunden einen Server in Australien per FTP kontaktieren und nach neuen Daten zur Verarbeitung suchen. Ob das allerdings sinnvoll ist, lassen wir mal dahingestellt. Denn nicht nur wird alle paar Sekunden der Prozessor für diese FTP-Abfrage gebraucht, auch das Netz wird ja dadurch belastet. Ein kleines Login, nach Dateien schauen und wieder raus. Das ist nicht viel, aber: "Es läppert sich".

Sicher, es gibt Daten, die so schnell wie irgend möglich bearbeitet werden müssen. Aber dafür bieten wir ja schließlich Eingangsagenten wie FTP oder HTTP an, die ereignisorientiert ein Profil starten, sobald Daten eingestellt werden. In solch zeitkritischen Fällen sollte eine solche aktive Versorgung mit Daten also, wenn möglich, vorgezogen werden.

In vielen anderen Fällen ist aber ein aktives Daten-Einstellen nicht möglich. Der Partner mag vielleicht einfach nur nicht und ein Weltkonzern lässt sich eben nichts vorschreiben. Dann ist die Frage: Wie schnell müssen denn die Daten wirklich verarbeitet werden? Müssen Sie tatsächlich alle zehn Sekunden nachsehen oder dürfen es auch zehn Minuten sein? Oder: Gibt es womöglich feste Zeitpunkte zu denen Daten bereitgestellt werden?

Nehmen wir folgendes Beispiel:

Ihr Partner stellt immer abends zwischen 17 und 18 Uhr Bestellungen in ein Verzeichnis seines FTP-Servers. Manchmal kann es auch bis 19 Uhr dauern, später wird es nicht. Aber wenn die Bestellungen da sind, dann sollen diese zeitnah verarbeitet werden, damit die LKWs noch morgen früh losfahren können.

Sie könnten jetzt natürlich einen Cronjob aufsetzen, der im Intervall von einer Minute nach Daten schaut. Den ganzen Tag. Davon ca. 23 Stunden völlig vergebens. Und am Wochenende kommt sowieso nie was. Noch zwei komplette Tage sinnlose Arbeit für den Cronjob.

Sie könnten aber auch eine Crontab-Steuerung aufsetzen die nur werktags zwischen 17 und 19 Uhr alle Minute nachschaut und für den unwahrscheinlichen Fall, dass doch mal außer der Reihe was kommt (oder die Einstellung der Daten doch mal nach 19 Uhr erfolgt), im Rest der Zeit alle 15 Minuten. Sonntag lassen wir weg, da ist eh nichts los.

Das sähe dann etwa so aus:

Werktags (und samstags) zwischen 17 und 19 Uhr werden die Daten nach maximal einer Minute vom Server abgeholt, den Rest dieser Tage nach maximal 15 Minuten. Das sollte doch reichen, oder?

Bei Zugriffen auf die lokale Platte sind die Suchvorgänge natürlich wesentlich weniger kritisch, aber denken Sie dran, dass eingebundene Laufwerke bzw. gemountete Verzeichnisse auch wieder Netzwerk-Ressourcen verbrauchen! Und für jeden solchen Cronjob läuft ein Thread, der immer wieder das Verzeichnis nach Dateien durchsucht.

Übertreiben Sie es aber nicht mit der Effizienz! Die Daten werden über den Tag verteilt bereitgestellt, sind aber alles andere als zeitkritisch, also reicht doch einmal am Tag? Schön, aber nicht, dass dann plötzlich ein paar hundert Dateien auf einen Schlag kommen und das System für eine Stunde oder mehr auslasten! Dann doch lieber einmal pro Stunde das Abräumen was bisher so aufgelaufen ist.

Cronjobs entzerren

Wenn Ihr System zu immer denselben Zeiten massive Performance-Einbrüche zeigt bzw. voll belastet ist, sollten Sie Ihre Cronjobs mal darauf hin überprüfen, ob vielleicht viele davon zur selben Zeit loslaufen. So was kann schnell passieren, wenn man z. B. ein neues Profil als Kopie eines alten erstellt, ein paar Einstellungen ändert und dabei die Zeitsteuerung des Cronjobs unverändert lässt. Und plötzlich rennen um acht Uhr morgens drei Dutzend Jobs los und streiten sich um die Ressourcen, von denen die meisten eigentlich schon irgendwann im Laufe der Nacht ihre Daten gehabt hätten und längst fertig sein könnten.

Und wie gerade schon mal angemerkt: Cronjobs zu oft laufen zu lassen verbraucht unnötig Ressourcen. Aber zu wenige Läufe, die dann auf einen Schlag riesige Datenmengen verarbeiten müssen, sind auch nicht das Wahre. Dann lieber regelmäßig die neuen Daten abholen und so immer nur vertretbare Portionen verarbeiten.

Stellen Ihre Partner immer zu denselben Zeiten ihre Daten ein, können Sie natürlich wenig machen. In dem Fall sollten Sie aber zumindest die Prozesse, auf die Sie Einfluss haben, möglichst auf andere Zeiträume legen. Was bringt es, wenn es am Tag zwei Stunden Auslastung gibt und der Rest der Zeit Leerlauf ist?

Cronjobs für Datenbank-Abfragen

Sie haben sicher aufmerksam den Abschnitt über Speicherprobleme gelesen. Dort wurde geraten die Klasse DefaultFileSQLCron zu benutzen, da sowohl die einfache Datenbank-Abfrage als auch die Klasse DefaultSQLCron die Daten direkt im Speicher übergeben.

Was für den Speicher gut ist, ist für die Performance nicht ganz so gut. Solange Sie also wissen, dass Ihr Select-Statement nur relativ wenige Daten (ein paar hundert Zeilen sind völlig in Ordnung) ergibt, nutzen Sie ruhig je nach Anforderung den einfachen Datenbank-Eingangsagenten oder den DefaultSQLCron. Das macht den Lauf des Profils etwas flotter, da die Daten nicht erst wieder aus einer Datei neu in den Speicher gelesen werden müssen. Wobei der Performance-Gewinn hier nicht so sehr ins Gewicht fällt. Aber es sollte zumindest erwähnt werden.