Moin!
ich gebe dir in allen Punkten recht.
Das ist nett. :)
Ich habe eine kleine Intranet (nur firmen interne User) PHP Anwendung.
Hier habe ich jetzt mal eine Änderung versucht bei der der Client Browser per Javascript alle 10 Sekunden pollt und auf dem webserver bzw. MySQL Server nach aktuellen Einträgen in einer Tabelle sucht.
HTTP ist halt kein Push-Protokoll, wie es für viele Anwendungen sinnvoll wäre. Das wird sich auch so schnell leider nicht ändern, obwohl der Bedarf offenbar so langsam auch bei den Browserentwicklern durchdringt. Siehe z.B. unser Interview mit Mozilla (Stichwort "Engpaß HTTP").
Dabei ist mir halt aufgefallen, dass die Access.log doch recht groß wird.
Eigentlich habe ich damit kein Problem, nur weiss ich nicht wie man das dann am besten den Admins beibringt nach den Logfiles zu schauen bzw. auch wegen der Dimensionierung der HDs.
Die Sache ist doch recht simpel: Wenn Logging nicht benötigt wird, weil dadurch sowieso nur Datenmüll erzeugt wird, kann man's auch komplett abschalten, und nur im Bedarfsfall wieder aktivieren zur Fehlersuche o.ä.
Wenn das Logging hingegen gebraucht wird, um irgendwelche Statistiken zu befüllen, dann muß man die Logfiles ja sowieso verarbeiten und irgendwo lassen. Also wird sich um das Problem sowieso gekümmert werden. Logfiles zu archivieren ist gezippt (also mit gzip oder bzip2) sehr effektiv, weil sehr viele identische Informationen in den Dateien stehen. Sollte also ein Logfile eines ganzen Monats zu groß für die Festplatte sein, teilt man einfach den Zeitraum in kleinere Einheiten. Tagesweises Rotieren und Archivieren von Logfiles ist ja nun keine Seltenheit. Große Provider machen das sogar noch häufiger.
Dein Problem lautet also eigentlich nicht, wie du Logging selektiv verhinderst, sondern wie du Logfiles nach ihrer Entstehung sinnvoll weiterverarbeitest.
- Sven Rautenberg
"Love your nation - respect the others."