Gestern Nachmittag durfte ich auf dem LinuxTag 2010 Franklin in einem Kurzvortrag von 10 Minuten vorstellen. Nachdem der Monitor angeschlossen war und der erste Schock verdaut war - immerhin hatte ich ja OSX in Benutzung und nicht das bei den Anwesenden sehr beliebte Ubuntu - ging alles ganz reibungslos über die Bühne.
Wer sich anschauen möchte was ich da genau vorgestellt habe, oder wer noch nicht weiss was man mit Franklin machen kann, sollte sich die Präsentation als PDF anschauen.
In der Vortragsreihe hat Caspar auch Vimperator vorgestellt, was ich gerade mit wachsender Begeisterung teste. Mit der Firefox Erweiterung kann man alles mit der Tastatur steuern. Echt voll nerdy ;-)
In einem aktuellen Projekt steht bald ein signifikanter Server-Wechsel an. Um später genau sagen zu können, was das gebracht hat, wollte ich mehrere Teile der Website (verschiedene URIs) mit dem Apache Tool ab zu verschiedenen Tageszeiten, einmal vor Wechsel des Servers und nach Wechsel des Servers, testen. Da ich nicht viel Zeit verschwenden wollte, hab’ ich ein Shell-Script geschrieben das mir wenigstens die Arbeit abnimmt die verschiedenen URIs abzuchecken:
#!/bin/bash
##############################################################################
# Run ab on a list of URIs
#
# Usage:
# ab_batch.sh
#
# Author: Marcel Eichner // Ephigenia <love@ephigenia.de>
# Date: 2010-06-03
##############################################################################
URL="http://www.horrorblog.org"
SLEEP=30
URIS=(
"/"
"/blog/reca-drei-clips-und-red-band-trailer/"
"/blog/the-crazies-remake-horrorblog-kritik/"
"/blog/the-crazies-interview-clips/"
"/blog/the-devils-playground-erste-bilder/"
"/blog/a-nightmare-on-elm-street-remake-horrorblog-kritik/"
)
date
echo -e "Batch Apache-Benchmarking on n${URL}"
for URI in ${URIS[@]};
do
echo "uri: ${URI}"
ab -c 10 -t 60 "${URL}${URI}" | grep -P "(request|second):"
sleep ${SLEEP}
done
Das liefert dann zum Beispiel folgendes Ergebnis. Die Werte kann man dann in eine Tabelle übertragen und ein Diagram draus machen. Nach dem Server wechseln dann das ganze noch einmal durchführen und schon hat man einen schönen Beweis was der Umzug denn gebracht hat.
Fr 4 Jun 2010 12:15:54 CEST
Batch Apache-Benchmarking on
http://www.horrorblog.org
uri: /
Finished 349 requests
Requests per second: 5.57 [#/sec] (mean)
Time per request: 1794.754 [ms] (mean)
Time per request: 179.475 [ms] (mean, across all concurrent requests)
uri: /blog/reca-drei-clips-und-red-band-trailer/
Finished 588 requests
Requests per second: 9.79 [#/sec] (mean)
Time per request: 1021.170 [ms] (mean)
Time per request: 102.117 [ms] (mean, across all concurrent requests)
uri: /blog/the-crazies-remake-horrorblog-kritik/
Finished 407 requests
Requests per second: 6.78 [#/sec] (mean)
Time per request: 1474.255 [ms] (mean)
Time per request: 147.425 [ms] (mean, across all concurrent requests)
uri: /blog/the-crazies-interview-clips/
Finished 397 requests
Requests per second: 6.60 [#/sec] (mean)
Time per request: 1514.682 [ms] (mean)
Time per request: 151.468 [ms] (mean, across all concurrent requests)
uri: /blog/the-devils-playground-erste-bilder/
Finished 331 requests
Requests per second: 5.50 [#/sec] (mean)
Time per request: 1816.657 [ms] (mean)
Time per request: 181.666 [ms] (mean, across all concurrent requests)
uri: /blog/a-nightmare-on-elm-street-remake-horrorblog-kritik/
Finished 506 requests
Requests per second: 8.43 [#/sec] (mean)
Time per request: 1185.792 [ms] (mean)
Time per request: 118.579 [ms] (mean, across all concurrent requests)
Für Verbesserungsvorschläge bin ich wie immer offen! Kommentiert einfach!
Letzte Woche Freitag Nacht wurde von Google der Source Code aka Quellcode zu deren Online-Betriebssystem Chrome OS released. Ein paar Videos und noch mehr Infos gibt’s in dem dazugehörigen Blog-Post im Chrome-Blog.
Wer es drauf hatte auf Ubuntu seinen eigene Version zu compilieren kann sich glücklich schätzen und kennt sich wahrscheinlich gut damit aus. Ich musste mich mit dem Versuch begnügen das ganze mit einem Festplatten-Image von GDGT in Virtual Box (3.0.12 r54655) auf Snow Leopard (10.6.2) zum Laufen zu bekommen. Nachdem ich den Netzwerkadapter auf Desktop umgestellt habe, Linux - Ubuntu - Other Linux wie in der Anleitung angegeben hatte zeigte sich auch endlich der Login-Screen! So, jetzt noch die Tücken der englischen Tastatur besiegen und nachdem das "z" im Passwort auch hübsch als "y" auf der Tastatur eingegeben wurde komm ich auch mit meinem Google Account rein! (Manchmal geht das wohl nicht weil die Server überlastet waren?)
Ja, wie ist es? Ganz nett - es kann noch nich’ viel, alles läuft quasi im "Browser". Das Schachspiel das man schon gesehen hat vielleicht läuft in Flash und ich glaube nativ installiert, auf einem Netbook, ist Chrome OS superschnell! Frisch hochgefahren mit 3 Fensterchen offen, verbrauchte Chrome OS nur ca. 50MB!
Ich bin gespannt wie das fertige System aussehen wird. In einem Jahr wird sich ja hoffentlich noch viel Ändern und noch mehr "Programme" geboten werden. Zum Websites-Testen braucht man Chromium auf jeden Fall nicht - da reicht auch der Chrome-Browser.
Aus aktuellem Anlass wollte ich ein Shell-Script schreiben das mir anzeigt, wenn sich eine Datei ändert (ein Log-File) und diese dann kurz ausgibt. Jedes mal wenn sich also die Datei ändert, klingelt es im Terminal (printf 'a') und ich bekomme die letzten Einträge angezeigt:
interval=${2:-1}
filename=$1
filename=${filename:?"missing."}
while true
do
if test `find "$filename" -mmin ${interval}`
then
clear;
printf "`date`n$filenameann";
tail "$filename"
fi
echo "sleeping for next check in $((interval * 60)) seconds ..."
sleep $((interval * 60))
done
Man kann das auch auf die Spitze treiben, aber so macht’s erstmal das was ich wollte. Benutzt wird es dann wie folgt:
./fileChanged.sh folder/testlog.log
Checkt dann jede Minute ob die Datei sich geändert hat. Wer rausbekommt wie man das mit Sekunden machen kann sagt mir Bescheid :)
Wie gestern schon beschrieben kann man super ab (Apache Bench) die Performance seiner Applikationen im Web testen. Durch Zufall hab ich in meiner Ports Sammlung noch ein anderes Programm gefunden das auch sehr vielversprechend aussieht: siege.
Dort kann man auch mehrere URLs testen, einen User simulieren und noch viel mehr. Damit habe ich allerdings noch nicht so viel Erfahrung. Hab aber gleich mal meine App getestet:
siege -c 100 -t 10s http://localhost/myProject/
Die Ausgabe sieht fast so aus wie beim ab:
Transactions: 545 hits
Availability: 100.00 %
Elapsed time: 17.85 secs
Data transferred: 1.33 MB
Response time: 1.02 secs
Transaction rate: 30.53 trans/sec
Throughput: 0.07 MB/sec
Concurrency: 31.01
Successful transactions: 604
Failed transactions: 0
Longest transaction: 3.31
Shortest transaction: 0.03
Mit einem Config File kann man aber auch noch mehrere Urls abfragen und so ein realistischeres Ergebnis erzielen. Mehr dazu steht in der Docu von Siege oder in Tutorials die man so im Netz findet: Regression testing with Siege.
Ich denke mal das solche Tools auch eine wunderbare Möglichkeit sind verschiedene Hoster zu testen oder einem Kunden zu zeigen wie Vorteilhaft eine Optimierung seiner Applikation wäre oder einfach nur welchen extremen Effekt der Einbau eines Caches hat.
Wer sich mit Websiten beschäftigt die von mehr als 100 Besuchern am Tag besucht werden und nicht wirklich viel im Terminal macht freut sich eventuell über Apache Bench.
Das ist ein Programm das man auf OSX ganz einfach im Terminal laufen lassen kann um seinen Server mal so richtig schwitzen zu lassen.
Ein üblicher (und auch vergleichbarer) Aufruf ist der folgende:
ab -c 10 -t 60 http://localhost/myProject/
Was 60 Sekunden lang, immer 10 Requests auf die Seite abfeuert und einem danach folgende Ausgabe generiert:
Finished 3102 requests
Server Software: Apache/2.0.59
Server Hostname: localhost
Server Port: 80
Document Path: /myProject/
Document Length: 2005 bytes
Concurrency Level: 10
Time taken for tests: 60.002 seconds
Complete requests: 3102
Failed requests: 303
(Connect: 0, Receive: 0, Length: 303, Exceptions: 0)
Write errors: 0
Total transferred: 7530897 bytes
HTML transferred: 6211149 bytes
Requests per second: 51.70 [#/sec] (mean)
Time per request: 193.431 [ms] (mean)
Time per request: 19.343 [ms] (mean, across all concurrent requests)
Transfer rate: 122.57 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 1.2 0 11
Processing: 30 186 663.6 157 20630
Waiting: 0 161 83.6 155 621
Total: 30 187 663.6 157 20631
Percentage of the requests served within a certain time (ms)
50% 157
66% 196
75% 219
80% 235
90% 276
95% 309
98% 354
99% 386
100% 20631 (longest request)
In dieser Ausgabe kann man erkennen das das aktuelle Projekt so ca. 50 Leute gleichzeitig aushalten könnte. Im vergleich mit anderen Projekten kann man dann Rückschlüsse darauf ziehen wie gut man programmiert hat ;-)
Viele benutzen ab auch zum Vergleich von verschiedenen Frameworks die ich euch natürlich nicht vorenthalten möchte: Test1, Test2 und Test3.
ab kann man wie üblich über macports installieren (OSX Developer Tools müssen installiert sein):
sudo port install ab
Viele von den PHP Codern da draussen kennen es wahrscheinlich schon, aber ich will trotzdem mal darauf hinweisen. Datei Uploads in PHP sind ja manchmal etwas verwirrend, vor allem was verschiedene Fehlerquellen angeht. Um schon im Vorhinein Fehler abzufangen bietet sich folgendes Code-Snippet an:
// test if a file was uploaded
$formFieldName = 'myFile';
if (isset($_FILES[$formFieldName])) {
switch(@$_FILES[$formFieldName]['error']) {
case UPLOAD_ERR_OK: // 0
// everything is ok with the upload for php
break;
case UPLOAD_ERR_INI_SIZE:
// file is larger than the size set in php.ini
// upload_max_filesize
break;
case UPLOAD_ERR_FORM_SIZE:
// file exceeds size set in form
break;
case UPLOAD_ERR_PARTIAL:
// file upload
break;
case UPLOAD_ERR_NO_FILE:
// no file was specified (empty form field)
break;
case UPLOAD_ERR_NO_TMP_DIR:
// no tmp dir specified in php.ini
break;
case UPLOAD_ERR_CANT_WRITE:
// tmp dir from php.ini is not writable for php
break;
default:
// unknown error code
break;
}
}
Wie man sieht bietet PHP weit aus mehr Möglichkeiten fehlgeschlagene Datei-Uploads zu erkennen als manchen bewusst ist. Vor allem wenn große Dateien hochgeladen werden die zu groß sind (upload_max_filesize) gibt PHP direkt einen Fehler aus, ohne riesen Dateien anzunehmen.
Nach Ewigkeiten hab ich’s wieder gefunden! Juhu! Der ASCII Editor für den Mac! Man was hab ich mich dumm gegoogelt und dann find ich das auf der Seite des wohl bekanntesten Tetris Spiels für den Mac Quinn :)
Für die Dosen gibts das auch, kann sogar noch mehr und heisst ASCII Art Studio.
Kann man super gebrauchen um in PHPDoc Kommentaren mal ein wenig zu malen :) hrhr!