Von Zeit und Datenmengen
Bei Datenmigrationen und der Batchverarbeitung kommen 2 Bereiche zusammen bei denen viele Entwickler (mich eingeschlossen) schnell an eine mentale Grenze stossen:
- Zeit
- Datenmenge
Wohl ist jedem bekannt das ein Tag 24 Stunden hat und ein Terabyte aus 1024 Gigabyte besteht. Und doch kommt es immer wieder zu bösen Überraschungen.
Eine Optimierung am Code ist reine Zeitverschwendung, da die Arbeit in einer Sekunde erledigt ist.
Wer hat nicht schon solche Aussagen gehört? Das Problem von dieser einen Sekunde ist nicht die Dauer. Das Problem liegt in der impliziten Aussage über die Geschwindigkeit. Eine Sekunde ist kurz, meine Arbeit gross und daraus folgt mein Code ist schnell. Wenn es so doch nur so einfach wäre…
Wie lange kann es auf der Produktion schon gehen wenn es auf dem Testsystem gar nicht messbar ist?
Ist die wohl noch schönere Frage. Wer schon einmal versuchte eine grössere Datenmenge zu migrieren kennt die unbequeme Antwort: Lange – viel zu lange.
Was genau messen wir?
Wie immer wenn etwas gemessen wird kommt es auf die Relevanz an. Ob 1 Sekunde schnell oder langsam ist hängt davon ab, was darin gemacht wurde. Wie viele Datensätze wurden verarbeitet? Und in welchem Verhältnis steht diese Datenmenge zum Zielsystem?
Die einzelnen Sekunden summieren sich sehr schnell, alles was es dazu braucht ist eine unterschiedliche Menge an Daten auf dem Test- und auf dem Produktionssystem. Bei einem linearen Anstieg wächst die Verarbeitungsdauer gleichmässig mit der Datenmenge. Verdoppelt sich die Datenmenge, verdoppelt sich auch die Verarbeitungsdauer. Hat man 60x mehr Daten in der Produktion als auf dem Testsystem wird aus dieser einen Sekunde bei der Einführung eine Minute.
Eine Hochrechnungstabelle
Was passiert aber wenn man statt auf dem Testsystem auf dem Entwicklungssystem gemessen hat? Da ist das Verhältnis vielleicht nicht 1:60, sondern 1:1'000, 1:10'000 oder gar 1:100'000. Wie lange waren nochmal 100'000 Sekunden?
Diese kleine Hochrechnungstabelle nimmt das Rechenbeispiel auf und geht von einer Sekunde für eine bestimmte Menge von Daten aus. 10x mehr Daten ergeben den Faktor 10, der für diesen linearen Anstieg auch in einer 10x längeren Dauer resultiert:
| Faktor Datenmenge | Dauer |
|---|---|
| 1 | 00:00:01 |
| 10 | 00:00:10 |
| 100 | 00:01:40 |
| 1'000 | 00:16:40 |
| 10'000 | 02:46:40 |
| 100'000 | 27:46:40 oder 1 Tag 03:46:40 |
| 1'000'000 | 277:46:40 oder 11 Tage 13:46:40 |
Die 100'000x mehr Daten machen aus der getesteten Sekunde bei der Einführung eine Aufgabe die sich in einem Tag nicht mehr abschliessen lässt. Aber schon bei 10'000x mehr Daten dürfte so mancher Einführungsplan in den kritischen Bereich kommen.
Probleme vermeiden
Diese Probleme lassen sich am einfachsten dadurch vermeiden, dass man die Performance-Messungen auf vergleichbaren Systemen mit vergleichbaren Datenmengen macht.
Ist es nicht möglich muss man die Werte entsprechend umrechnen. Dies ist viel aufwändiger und weniger genau, aber immer noch besser als sich einzureden die Arbeit sei in einer Sekunde erledigt. Dabei gilt es aber nicht nur die Datenmenge zu bedenken. SSD-Festplatten sind gerade in Kombination mit kleinen Datenmengen deutlich schneller als so manche Server-Festplatte. Von CPU, Netzwerk und Systemdiensten die auch noch laufen ganz zu schweigen.
Fazit
Wenn man eine Performance-Messung nur auf die Dauer reduziert führt dies zu völlig falschen Annahmen. Um lange Wartezeiten bei der produktiven Einführung zu verhindern muss daher unbedingt beachtet werden wie sich die Daten und Systeme gegenüber der Produktion unterschieden. Mehr Daten bedeutet eine längere Verarbeitungszeit. Und nur weil es auf irgendeinem System schnell ist bedeutet dies nicht automatisch das man aufs optimieren verzichten kann. Ganz abgesehen davon dass eine exponentielle Zunahme der Verarbeitungszeit alles noch viel schlimmer macht...