Wenn man langeweile hat kommt ja bekanntlich auf dumme Gedanken. Ich habe momentan ein bisschen mit dem Tool Pyrit zu tun, welches auch eine Netzwerk-Funktionalität bietet. Man kann also eine ganze Serverfarm nutzen um einen WPA-Schlüssel zu knacken wenn man das möchte. Dazu wird ein Server in den Modus “pyrit serve” gesetzt – er wartet dann auf Jobs, die vom Client vergeben werden. Ich habe also mal testweise einige Server verbunden um zu testen was denn so an Rechenleistung bei einem kleinen “Cluster” aus Pyrit-Servern leistungstechnisch geht. Es sind 6 Server an der Zahl: Genauer 1 Dual-Quad-Core, 4 Quad-Core und 1 Dual Core System, die aber alle auch zum Testzeitpunkt normal im Produktiveinsatz genutzt wurden. Der Client rechts im Bilde ist ebenfalls ein Dual-Quad-Core System.
Ernüchternd ist am Ende jedoch die Erkenntnis, dass die gleiche Leistung mit EINER GeForce 295 GTX erreicht werden kann. 4 dieser Karten sollen wohl 90.000 PMKs/s erreichen. Da kann man sich natürlich berechtigterweise fragen, ob WPA sicher vor Bruteforce-Attacken ist. Daher möchte ich die Zeit einmal in der Theorie durchrechnen.
Gegeben sei ein WLAN-Router mit einem 16-stelligen Code nur aus Zahlen. Das würde bedeuten 10 Möglichkeiten (0-9) hoch 16 Stellen also in einer Zahl 10.000.000.000.000.000 verschiedene Möglichkeiten für den werksgesetzten WLAN-Schlüssel. Wenn ich mit dem kleinen zusammengeschusterten Cluster hier 20000 PMKs/s erreiche sind das 500000000000 Sekunden oder 833333333 Minuten oder 138888888 Stunden oder 5787037 Tage..das wären also ca 16000 Jahre in etwa..wenn man die Entwicklung neuer Internetstandarts bedenkt, wofür man neue Router benötigt ist das also ein ziemlich sinnloses Unterfangen. Hat man 10 Systeme mit jeweils 4xGeForce 295 GTX kann man es auch schon in knapp einem Jahr schaffen, aber das setzt voraus man weiß, dass der Schlüssel tatsächlich nur aus Zahlen besteht und 16-stellig ist. Wählt man für sein WPA-verschlüsseltes WLAN also ein mindestens 10-stelliges Passwort aus Zahlen, Klein- und Großbuchstaben, so ist es mit “normalen” Mitteln nicht knackbar.
Ich habe heute rein aus reiner Neugierde ausprobiert, wie effektiv das Cache-System asy_jpcache für Textpattern arbeitet beziehungsweise um welchen Faktor die Anzahl der ausgelieferten Seiten steigen würde. Mir ist klar, dass solche Benchmark-Werte nicht die repräsentativsten sind, daher beschreibe ich in aller Kürze die Testbedingungen damit sich jeder selbst ein Bild machen kann. Der Benchmark wird mit ApacheBench auf einem EEE PC ausgeführt und das Gerät, dessen Leistung getestet wird ist eine SheevaPlug mit einem 1,2Ghz ARM Prozessor und 512MB RAM. Der verwendete Webserver ist (natürlich) Nginx in der Version 0.8.31, der auf einem Debian Lenny läuft. Die beiden Rechner sind über einen 100Mbit-Switch verbunden (was aber keine Rolle spielen sollte, da die SheevaPlug ohnehin nicht so viel ausliefern kann). Die Seite, auf die der Benchmark ausgeführt wurde ist die Startseite von Textpattern nach einer frischen Installation.
Benchmark erfolgte mit diesen Parametern
ab -n 1000 -c 10 http://SheevaPlug/index.php
Benchmark #1 (ohne Cache)
Server Software: nginx/0.8.31
Server Hostname: SheevaPlug
Server Port: 80
Document Path: /index.php
Document Length: 7668 bytes
Concurrency Level: 10
Time taken for tests: 390.297 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 8008000 bytes
HTML transferred: 7668000 bytes
Requests per second: 2.56 [#/sec] (mean)
Time per request: 3902.969 [ms] (mean)
Time per request: 390.297 [ms] (mean, across all concurrent requests)
Transfer rate: 20.04 [Kbytes/sec] received
Benchmark #2 (mit Cache)
Server Software: nginx/0.8.31
Server Hostname: SheevaPlug
Server Port: 80
Document Path: /index.php
Document Length: 7668 bytes
Concurrency Level: 10
Time taken for tests: 90.844 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 8238254 bytes
HTML transferred: 7668000 bytes
Requests per second: 11.01 [#/sec] (mean)
Time per request: 908.438 [ms] (mean)
Time per request: 90.844 [ms] (mean, across all concurrent requests)
Transfer rate: 88.56 [Kbytes/sec] received
Natürlich ist die Betrachtung aller Werte wichtig für das Ergebnis, doch ich nehme für einen ungefähren Performancevergleich die “Time taken for tests” heran, die ohne Cache bei 390 Sekunden und mit Cache bei 91 Sekunden lag. Daraus folgt, dass durch den Einsatz eines Cache-Systems wie hier asy_jpcache etwa Faktor 390/91=4,3 mehr Seiten ausgeliefert werden können.
//Nachtrag: Ich habe (ohne mir noch viel mehr zu Versprechen) zu der oben genannten Konfiguration noch XCache hinzugefügt und es hat mich fast aus den Socken gerissen. Ich hätte ja mit einer winzigen Verbesserung gerechnet, aber seht selbst:
Benchmark #3 (mit Textpattern Cache und XCache)
Server Software: nginx/0.8.31
Server Hostname: SheevaPlug
Server Port: 80
Document Path: /index.php
Document Length: 7667 bytes
Concurrency Level: 10
Time taken for tests: 26.063 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 8238247 bytes
HTML transferred: 7667000 bytes
Requests per second: 38.37 [#/sec] (mean)
Time per request: 260.625 [ms] (mean)
Time per request: 26.063 [ms] (mean, across all concurrent requests)
Transfer rate: 308.69 [Kbytes/sec] received
Noch einmal konnten die 1000 Abfragen um fast Faktor 4 schneller ausgegeben werden, was am Ende bedeutet, dass ein optimiertes System mit einem Cache für das CMS kombiniert mit einem opcode Cache wie XCache in meinem Beispiel Faktor 390/26=15 schneller arbeiten kann. Mit weiteren Optimierungen ist da sicherlich noch etwas mehr drin, allerdings reicht dieser Wert für mich erstmal locker aus 
Ja, er baut immer noch. Privat hat sich in den letzten Monaten viel für mich verändert, aber ich habe den Umbau meines Blogs (Ziel ist der Einsatz eines performanteren CMS sowie die Nutzung eines schlanken Webservers) nicht aus den Augen verloren. Es ist nicht so, dass der Blog momentan langsam läuft, aber dieser Apache-Brei + Wordpress fordert einen einfach überhaupt nicht. Ich gebe zu es funktioniert alles ganz einfach, aber warum denn einfach, wenn es auch kompliziert geht
Ich hoffe mit dem Übernehmen der Artikel und der SEO-Anpassung an das neue System werde ich in den nächsten Wochen abschließen können. Ich freue mich ja selbst schon darauf euch die Verwendete Software, Benchmarks und so weiter vorzustellen.
Vielleicht wundern sich einige (ich weiß nicht, ob ich tatsächlich regelmäßige Leser habe), warum hier nichts mehr passiert. Aber ich bin durchaus noch aktiv an der Arbeit für diesen Blog. Was momentan so viel Zeit frisst ist der Umbau dieses Wordpress Blogs auf Textpattern. Der darauf laufende Webserver wird Nginx sein und er wird natürlich auch mod_rewrite unterstützen und euch schöne URLs liefern, die gleich den Titel des jeweiligen Artikels verraten wie bisher. Darum geduldet euch noch ein wenig
Ich werde eventuell hin und wieder von dem Umbau berichten. Fest steht, es bringt auf jeden Fall mehr Performance von Apache loszukommen und Wordpress ist langsam und umständlich im Vergleich zu anderen Systemen.
Es gibt diesen Blog nun gerade einmal 2 Monate und schon haben sich einige für mich wichtige und schöne Ereignisse angesammelt. Daher heute mal ein paar Zahlen. Dies ist der 100. Post. Der erste Post geschah am 26.4.2009. Das bedeutet, dass alle 2 Tage 3 Posts geschrieben wurden. Nach ca. einem Monat hatte ich schon die ersten 3000 Besucher (Bots abgezogen). Diesen Monat hat die Seite ~320GB Traffic verursacht (größtenteils durch die WPA-Rainbowtables).
Die 5 meistgelesenen Beiträge sind folgende (absteigend):
Mein Fazit daraus..ich sollte einfach in einem Beitrag Wilmaa schreiben und schon wird er gelesen. Die Nachfrage nach Wilmaa scheint so enorm, dass die Menschen einfach alles dafür tuen würden es zu empfangen. Nachvollziehbar wie ich finde. Ich werde auf jeden Fall so weitermachen wie bisher und die Themen behandeln, mit denen ich mich tagtäglich beschäftige oder auch auf Nachfrage bestimmte Dinge recherchieren. Weiterhin viel Spaß euch, liebe Leser
Mobbler ist ein kleines Tool für Symbian-fähige Handys, womit man Last.FM hören kann. Nachdem man seinen Login eingegeben hat kann man zwischen den Bitraten 64kbits und 128kbit wählen und sich verbinden. Wie gewohnt gibt man dann einen Künstler ein und hört ähnliche Tracks.
Mobbler 0.6.5124
Ein wirklich empfehlenswertes, cooles Tool um auch unterwegs in grenzenlosen Musikgenuss zu kommen.
