Im Prinzip sollte man sein sasap durch die Vorgehensweise so tunen, dass es zur Cacheerstellung brav unter einer Minute bleibt. sas liest mit der neuen Version sowieso nur noch den Cache und ist somit immer schnell. Die time-Methode, die koyaanisqatsi hier beschreibt, ist dazu ideal.
Ich vermute allerdings, dass er bei: time php sas.php info=status
eher das einzelne Pseudoscript meint anstelle von sas.php - also time php prseudoschalter.php info=status
sas.php läuft zum Testen auch ohne Parameter: time php sas.php
Bei mir braucht sasap etwa eine halbe Minute. Mit vielen Pseudoscripten kann der Wert höher sein. Es gilt zu verhindern, dass sozusagen sasap noch läuft und durch cron ein weiteres sasap gestartet wird, bevor das vorangegangene fertig ist. Passiert das, gibt das einen Kaskadeneffekt und irgendwann hat man einen Haufen noch nicht fertig abgearbeiteter sasap, die sich gegenseitig behindern. Den Aufruf von sasap zu verhindern, wenn noch ein sasap läuft ginge zwar, würde aber dann ein eventuelles zeitgesteuertes Schalten verhindern, weil die Zeit bereits um ist, wo geschaltet werden sollte. Naja, das nur am Rande.
Faustregel: sasap muss für einen Durchlauf weniger als eine Minute brauchen, dann passts.
SAS-WebGUI muss nicht getunt werden, das läuft mit Cache immer schnellstmöglich.
Noch als Nachtrag:
Zeitintensiv sind gerne Pseudoscripte mit Multiabfragen über sashelper durch curl,
Aufrufe von langsamen Internetseiten zur Daten-/Sensorwertgewinnung,
Manche Betriebssystembefehle,
Geräte, die nicht erreichbar sind und dann einen Fehler liefern. (Wird zwar schon programmseitig etwas abgefangen, dass nicht ewig drauf gewartet wird, aber...)
Gleiches gilt für Webseiten, die down sind.
