| 1 |
root |
1.1 |
!init OPT_STYLE="paper" |
| 2 |
|
|
|
| 3 |
|
|
!define DOC_NAME "Wie ich mit Perl Apache und thttpd erschlug" |
| 4 |
|
|
!define DOC_AUTHOR "Marc Lehmann <pcg@goof.com>" |
| 5 |
|
|
!build_title |
| 6 |
|
|
|
| 7 |
|
|
H1: Ein reißerischer Titel |
| 8 |
|
|
|
| 9 |
|
|
Ja, theatralisch war ich schon immer ;) |
| 10 |
|
|
|
| 11 |
|
|
H2: Das Problem, das es zu lösen galt |
| 12 |
|
|
|
| 13 |
|
|
Wie bei allen meiner Programme und Module, stand am Anfang ein |
| 14 |
|
|
Problem: Ich hatte Festplatten. Damals grooose Festplatten |
| 15 |
|
|
(insgesamt 320Gb). Mit Dateien drauf. Groooosen Dateien. Beliiiebten |
| 16 |
|
|
Dateien. Filme! Animes, um genau zu sein. |
| 17 |
|
|
|
| 18 |
|
|
Und weil man das nur sehr schwer bekommt, dachte ich mir, packe sie auf |
| 19 |
|
|
einen Webserver und bring' sie unter das Volk. |
| 20 |
|
|
|
| 21 |
|
|
Und da fingen die Probleme an: "beliebt" ist leicht |
| 22 |
|
|
untertrieben. Innerhalb von fünf Tagen wuchs die Zahl der gleichzeitig |
| 23 |
|
|
offenen Verbindungen von 100 (erster Tag) auf 700. Natürlich hatte ich |
| 24 |
|
|
da schon längst von apache auf thttpd umgestellt. Einen Prozeß (oder |
| 25 |
|
|
Thread, was das gleiche ist) pro Verbindung war indiskutabel (das war mir |
| 26 |
|
|
schon vorher klar), ein Webserver wie thttpd, der alle Verbindungen in |
| 27 |
|
|
einem Prozeß bedient, ist eine Notwendigkeit. |
| 28 |
|
|
|
| 29 |
|
|
H2: Die Probleme mit thttpd |
| 30 |
|
|
|
| 31 |
|
|
Schon nach kurzer Zeit stellte sich dann heraus, daß thttpd Bugs, |
| 32 |
|
|
häßliche, zerstörerische Bugs, hatte. Ein solcher Bug war, daß thttpd |
| 33 |
|
|
zum Fileserven mmap+write benutze. Bei Dateien, die 100-700MB gross |
| 34 |
|
|
sind, ist der virtuelle Speicher schnell aufgebraucht, so daß mmap |
| 35 |
|
|
fehlschlägt. thttpd reagiert darauf mit einem "500 Internal Error". Und |
| 36 |
|
|
verloren. Da er den mmap-cache auch so einfahc nicht wieder hergibt, macht |
| 37 |
|
|
thttpd seine eigene Denial-of-Service attack... |
| 38 |
|
|
|
| 39 |
|
|
Aber, ich bin ja ein kompetenter C-Programmierer (ah, wie ich das |
| 40 |
|
|
hasse! C!), also habe ich thttpd umgeschrieben, so daß er auf read+write |
| 41 |
|
|
zurückfällt bei grossen Dateien. |
| 42 |
|
|
|
| 43 |
|
|
Danach ging es, wenn man "ging" als "korrekt, aber langsam" versteht. 7 |
| 44 |
|
|
Mbit ist nicht gerade berauschend (auf einem PC, unsere SGI von 1995 mit |
| 45 |
|
|
13x4GB SCSI-Platten brachte es auf sage und schreibe 20MBit!). |
| 46 |
|
|
|
| 47 |
|
|
H2: Warum neuschreiben in Perl schöner war |
| 48 |
|
|
|
| 49 |
|
|
Es sollte klar sein, daß das vertreiben dieser Filme nicht legal |
| 50 |
|
|
ist. Tatsächlich gibt es eine Art ungeschriebene Übereinkunft zwischen |
| 51 |
|
|
den japanischen Firmen und "Anbietern" wie mir: solange ein Film/Serie |
| 52 |
|
|
ausserhalb Japans nicht lizensiert wurde, wird das kopieren geduldet, |
| 53 |
|
|
da es ja einen Markt schafft (zwischen Lizensierung und Verkauf liegen |
| 54 |
|
|
manchmal Jahre). Zudem steckt in den Untertitelungen von Fans auch viel |
| 55 |
|
|
Arbeit (manche Firmen kaufen die Rechte der Untertitelungen von den Fans |
| 56 |
|
|
oder schreiben mir, wenn eine Serie lizensiert wird, so daß ich sie |
| 57 |
|
|
sperren kann). |
| 58 |
|
|
|
| 59 |
|
|
Ich lege "ausserhalb Japans" etwas inkorrekt aus als: "wenn |
| 60 |
|
|
in Land X keine Lizenz bekannt ist, dürfen Leute aus Land X |
| 61 |
|
|
downloaden". Also muss ich irgendwie das Land feststellen, am besten |
| 62 |
|
|
über whois-Anfragen. Letzteres ist ein schwieriges Problem (da ARIN, die |
| 63 |
|
|
amerikanische IP-Addressen-"Registry", leider ein völlig chaotisches und |
| 64 |
|
|
teilweise nicht parsebares Format hat, während RIPE (Europa) und APNIC |
| 65 |
|
|
(Asien&Pazifik) ein standardisiertes Format verwenden) und müsste zudem |
| 66 |
|
|
asynchron im Webserver stattfinden, etwas, was ich nicht in C machen |
| 67 |
|
|
wollte. |
| 68 |
|
|
|
| 69 |
|
|
Nebenbei wollte ich nicht glauben, daß der Rechner "nur" ca. 7Mbit |
| 70 |
|
|
liefern konnte, in Perl müsste man doch mehr Leistung erreichen. |
| 71 |
|
|
|
| 72 |
|
|
H1: Der Webserver - und Coro |
| 73 |
|
|
|
| 74 |
|
|
"Zufällig" hatte ich eine Woche vor dieser Erkenntnis das Coro-Modul in |
| 75 |
|
|
einer benutzbaren Form fertiggestellt. Die Stärke von Coro ist weniger |
| 76 |
|
|
Effizienz oder Geschwindigkeit der Programme, sondern die Effizienz und |
| 77 |
|
|
Geschwindigkeit, mit der Programme geschrieben werden können. |
| 78 |
|
|
|
| 79 |
|
|
In weniger als einer Stunde hatte ich einen HTTP/1.0-Webserver, |
| 80 |
|
|
der virtual hosts, nph-cgi und byte-ranges (wichtig fürs resumes) |
| 81 |
|
|
unterstützte. In 367 Zeilen (ist als Beispiel eg/myhttpd in der |
| 82 |
|
|
Coro-Distribution). |
| 83 |
|
|
|
| 84 |
|
|
H1: Das Programm |
| 85 |
|
|
|
| 86 |
|
|
Wie jeder andere "forkende" Server, erzeugt auch dieser Webserver eine Listen-Socket |
| 87 |
|
|
und wartet auf Verbindungen: |
| 88 |
|
|
|
| 89 |
|
|
!block perl |
| 90 |
|
|
my $port = new Coro::Socket |
| 91 |
|
|
LocalAddr => $SERVER_HOST, |
| 92 |
|
|
LocalPort => $SERVER_PORT, |
| 93 |
|
|
ReuseAddr => 1, |
| 94 |
|
|
Listen => 1, |
| 95 |
|
|
or die "unable to start server"; |
| 96 |
|
|
|
| 97 |
|
|
my $connections = new Coro::Semaphore $MAX_CONNECTS; |
| 98 |
|
|
|
| 99 |
|
|
# Starte den "Accept-Prozeß" |
| 100 |
|
|
async { |
| 101 |
|
|
slog 1, "accepting connections"; |
| 102 |
|
|
while () { |
| 103 |
|
|
$connections->down; |
| 104 |
|
|
async { |
| 105 |
|
|
$_[0] or return; # accept liefert manchmal undef |
| 106 |
|
|
eval { conn->new($_[0])->handle }; |
| 107 |
|
|
close $_[0]; |
| 108 |
|
|
slog 1, "$@" if $@ && !ref $@; |
| 109 |
|
|
$connections->up; |
| 110 |
|
|
} $port->accept; |
| 111 |
|
|
} |
| 112 |
|
|
}; |
| 113 |
|
|
|
| 114 |
|
|
# Springe in die Event-Hauptschleife |
| 115 |
|
|
loop; |
| 116 |
|
|
!endblock |
| 117 |
|
|
|
| 118 |
|
|
Das Coro::Socket-Modul hat (ungefähr) die gleiche Bedienung und Semantik |
| 119 |
|
|
wie IO::Socket::INET, der Aufruf ist also nicht neues. |
| 120 |
|
|
|
| 121 |
|
|
Der nächste Abschnitt erzeugt eine Coro::Semaphore. Jedesmal, bevor eine |
| 122 |
|
|
Verbindung 'accepted' wird, wird diese Semaphore gelockt und erst wieder |
| 123 |
|
|
freigegeben, wenn die Socket wieder geschlossen wird. Dadurch wird die |
| 124 |
|
|
Zahl der offenen Filehandles effektiv begrenzt, was, zumindest bei meinem |
| 125 |
|
|
Server, dringend notwendig war (1000-2000 Verbindungen). |
| 126 |
|
|
|
| 127 |
|
|
Die Schleife um den C<accept>-Aufruf besteht im wesentlichen aus: |
| 128 |
|
|
|
| 129 |
|
|
!block perl |
| 130 |
|
|
async { |
| 131 |
|
|
eval { ... Verbindung behandeln ...}; |
| 132 |
|
|
} $port->accept; |
| 133 |
|
|
!endblock |
| 134 |
|
|
|
| 135 |
|
|
Das muß man rückwärts lesen, denn der Aufruf von C<async> kann erst |
| 136 |
|
|
stattfinden, wenn alle Argumente vollständig sind, und C<$port->accept> |
| 137 |
|
|
kann eine sehr lange Zeit dauern, wenn keine Verbindungen aufgebaut |
| 138 |
|
|
werden. Wenn C<accept> zurückkehrt, wird eine neue Coroutine erzeugt. |
| 139 |
|
|
|
| 140 |
|
|
Die Klasse C<conn> implementiert ein "Verbindungsobjekt", C<handle> |
| 141 |
|
|
verarbeitet die Anfragen. |
| 142 |
|
|
|
| 143 |
|
|
H2: Lesen des HTTP-Headers |
| 144 |
|
|
|
| 145 |
|
|
Ein HTTP-Header besteht aus mehreren (nichtleeren) Zeilen, gefolgt von |
| 146 |
|
|
einer leeren Zeile. Ein idealer Job für C<$/>, aber in Programmen mit |
| 147 |
|
|
Coroutinen ist C<$/> gefährlich, da die Variable von allen Coroutinen |
| 148 |
|
|
gemeinsam benutzt wird. |
| 149 |
|
|
|
| 150 |
|
|
Da dies nur problematisch bei Coro::Handle ist (normaler I/O blockiert den |
| 151 |
|
|
Prozeß, ein C<local $/> reicht also), besitzt die C<readline>-Methode ein |
| 152 |
|
|
optionales zweites Argument - den effektiven Wert von C<$/>. |
| 153 |
|
|
|
| 154 |
|
|
!block perl |
| 155 |
|
|
# Lese den HTTP-Request |
| 156 |
|
|
$fh->timeout($::REQ_TIMEOUT); |
| 157 |
|
|
my $req = $fh->readline("\015\012\015\012"); |
| 158 |
|
|
$fh->timeout($::RES_TIMEOUT); |
| 159 |
|
|
|
| 160 |
|
|
defined $req or |
| 161 |
|
|
$self->err(408, "request timeout"); |
| 162 |
|
|
|
| 163 |
|
|
$req =~ /^(?:\015\012)? |
| 164 |
|
|
(GET|HEAD) \040+ |
| 165 |
|
|
([^\040]+) \040+ |
| 166 |
|
|
HTTP\/([0-9]+\.[0-9]+) |
| 167 |
|
|
\015\012/gx |
| 168 |
|
|
or $self->err(403, "method not allowed", { Allow => "GET,HEAD" }); |
| 169 |
|
|
|
| 170 |
|
|
$2 >= 2 |
| 171 |
|
|
or $self->err(506, "http protocol version not supported"); |
| 172 |
|
|
|
| 173 |
|
|
$self->{method} = $1; |
| 174 |
|
|
$self->{uri} = $2; |
| 175 |
|
|
!endblock |
| 176 |
|
|
|
| 177 |
|
|
C<readline> liefert den {{ganzen}} Request-Header, die Regex parsed |
| 178 |
|
|
nur die erste Zeile (eine Leerzeile am Anfang stammt evt. noch von |
| 179 |
|
|
einem kaputten vorherigen POST-Request. Kann ohne Keep-Alive zwar nicht |
| 180 |
|
|
passieren, aber falls persistente Connections jemals implementiert werden |
| 181 |
|
|
(sie wurden es), ist es besser, wenn der Rest damit klarkommt). |
| 182 |
|
|
|
| 183 |
|
|
Bei dieser (und der folgenden) Regex wurde auf Geschwindigkeit |
| 184 |
|
|
geachtet: Im Normalfall (kein Syntaxfehler) ist das Parsen linear, d.h. |
| 185 |
|
|
keine komplizierten Alternativen, kein non-greedy-modifier (?). |
| 186 |
|
|
|
| 187 |
|
|
Die Methode C<err> (um etwas abzuschweifen) ist der General-Abbruch. Sie gibt |
| 188 |
|
|
eine absolut primitive Fehlerseite aus und ruft dann: |
| 189 |
|
|
|
| 190 |
|
|
!block perl |
| 191 |
|
|
die bless {}, err::; |
| 192 |
|
|
!endblock |
| 193 |
|
|
|
| 194 |
|
|
... auf. C<err> ist eine echte Exception-Klasse, nur eben vollkommen leer ;) Dadurch wird |
| 195 |
|
|
auch die folgende Zeile im Hauptprogramm klar: |
| 196 |
|
|
|
| 197 |
|
|
!block perl |
| 198 |
|
|
slog 1, "$@" if $@ && !ref $@; |
| 199 |
|
|
!endblock |
| 200 |
|
|
|
| 201 |
|
|
Zurück zum Header-Parsen: |
| 202 |
|
|
|
| 203 |
|
|
!block perl |
| 204 |
|
|
# Parse die Header |
| 205 |
|
|
{ |
| 206 |
|
|
my (%hdr, $h, $v); |
| 207 |
|
|
|
| 208 |
|
|
$hdr{lc $1} .= ",$2" |
| 209 |
|
|
while $req =~ /\G |
| 210 |
|
|
([^:\000-\040]+): |
| 211 |
|
|
[\008\040]* |
| 212 |
|
|
((?: [^\015\012]+ | \015\012[\008\040] )*) |
| 213 |
|
|
\015\012 |
| 214 |
|
|
/gxc; |
| 215 |
|
|
|
| 216 |
|
|
$req =~ /\G\015\012$/ |
| 217 |
|
|
or $self->err(400, "bad request"); |
| 218 |
|
|
|
| 219 |
|
|
$self->{h}{$h} = substr $v, 1 |
| 220 |
|
|
while ($h, $v) = each %hdr; |
| 221 |
|
|
} |
| 222 |
|
|
|
| 223 |
|
|
$self->{server_port} = $self->{h}{host} =~ s/:([0-9]+)$// ? $1 : 80; |
| 224 |
|
|
!endblock |
| 225 |
|
|
|
| 226 |
|
|
Da HTTP-Header case-insensitive sind, Perl das von Haus aus aber |
| 227 |
|
|
nicht unterstützt, wird alle Header (z.B. "Content-Length") in |
| 228 |
|
|
Kleinbuchstaben gespeichert ("content-length"). Die Regex in der Schleife |
| 229 |
|
|
ist meines Wissens nach vollkommen korrekt und ließe sich auch auf |
| 230 |
|
|
andere RFC-2822-Header anwenden (News, Mail, ...). Auch hier wurde auf |
| 231 |
|
|
Geschwindgkeit geachtet. |
| 232 |
|
|
|
| 233 |
|
|
Der einfache (aber falsche) Weg wäre, den Kopf in Zeilen zu zerlegen |
| 234 |
|
|
und jede Zeile als Header betrachten. RFC2822-Header sind jedoch |
| 235 |
|
|
mehrzeilig. Für Perl jedoch kein Problem: durch den g und den c-Modifier |
| 236 |
|
|
und das \G am Anfang der Regex parsed Perl genau dort weiter, wo die |
| 237 |
|
|
vorherige Regex aufgehört hat. |
| 238 |
|
|
|
| 239 |
|
|
Die while-Schleife hört auf, sobald der Header zu Ende ist oder ein |
| 240 |
|
|
illegaler Header auftaucht. Das prüft die nächste Zeile, denn nach dem |
| 241 |
|
|
Header sollte eine einzelne, leere Zeile folgen. |
| 242 |
|
|
|
| 243 |
|
|
Die folgende Schleife kopiert den Header in den Hash C<$self->{h}>. |
| 244 |
|
|
|
| 245 |
|
|
Hier würde ich mich Fragen, was denn das C<.= ",$2"> und das C<substr $v, |
| 246 |
|
|
1> da zu suchen haben. Nun, manche Header können mehrfach vorkommen (tun |
| 247 |
|
|
dies auch), und das ist so ungefähr gleichwertig mit einem Header, in dem |
| 248 |
|
|
mehrere durch Komma getrennte Werte vorkommen. Das steht auch in C<%hdr>, |
| 249 |
|
|
mit einem "," am Anfang, was vom C<substr> weggeschnitten wird. |
| 250 |
|
|
|
| 251 |
|
|
In neueren Perl-Versionen (5.8 ;) geht das (dank Value-Sharing) mit einem: |
| 252 |
|
|
|
| 253 |
|
|
!block perl |
| 254 |
|
|
$_ = substr $_, 1 for values %hdr; |
| 255 |
|
|
!endblock |
| 256 |
|
|
|
| 257 |
|
|
Aber ich bin ja portabel... |
| 258 |
|
|
|
| 259 |
|
|
Jetzt muß der Request bearbeitet werden: |
| 260 |
|
|
|
| 261 |
|
|
!block perl |
| 262 |
|
|
$self->map_uri; |
| 263 |
|
|
$self->respond; |
| 264 |
|
|
!endblock |
| 265 |
|
|
|
| 266 |
|
|
Ok, nicht sehr beeindruckend. Hier das wichtigste von C<map_uri>: |
| 267 |
|
|
|
| 268 |
|
|
!block perl |
| 269 |
|
|
my $uri = $self->{uri}; |
| 270 |
|
|
|
| 271 |
|
|
# mach aus der uri was pfad-ähnliches |
| 272 |
|
|
$uri =~ s/%([0-9a-fA-F][0-9a-fA-F])/chr hex $1/ge; |
| 273 |
|
|
$uri =~ s%//+%/%g; |
| 274 |
|
|
$uri =~ s%/\.(?=/|$)%%g; |
| 275 |
|
|
1 while $uri =~ s%/[^/]+/\.\.(?=/|$)%%; |
| 276 |
|
|
|
| 277 |
|
|
$uri =~ m%^/?\.\.(?=/|$)% |
| 278 |
|
|
and $self->err(400, "bad request"); |
| 279 |
|
|
|
| 280 |
|
|
$self->{name} = $uri; |
| 281 |
|
|
|
| 282 |
|
|
# now do the path mapping |
| 283 |
|
|
$self->{path} = "$::DOCROOT/$host$uri"; |
| 284 |
|
|
!endblock |
| 285 |
|
|
|
| 286 |
|
|
Die vielen Regexes dienen dazu, "%xx", ".." und ähnliches in der URI aufzulösen. Am Ende sollte |
| 287 |
|
|
nirgendwo mehr ein ".." vorkommen, sonst haben wir ein Problem a'la Microsoft: |
| 288 |
|
|
|
| 289 |
|
|
!block perl |
| 290 |
|
|
213.114.180.157 - - [11/Dec/2001:04:44:44 +0100] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 265 |
| 291 |
|
|
213.114.180.157 - - [11/Dec/2001:04:44:44 +0100] "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 231 |
| 292 |
|
|
!endblock |
| 293 |
|
|
|
| 294 |
|
|
(ein tail -f auf ein beliebiges accesslog zu einer beliebigen Zeit |
| 295 |
|
|
reicht vollkommen aus, um sowas zu finden. Man beachte, daß Microsoft |
| 296 |
|
|
Zugriffschecks und ähnliches macht, {{bevor}} die URI geparsed |
| 297 |
|
|
wird. Hätten sie es blind nach Standard gemacht, wäre der Code |
| 298 |
|
|
sicherlich einfacher. Ach ja, der Hack hätte auch nicht funktioniert, |
| 299 |
|
|
aber Microsoft macht's gerne etwas besser als es im Standard steht. Das |
| 300 |
|
|
nennt man dann "Feature", glaube ich). |
| 301 |
|
|
|
| 302 |
|
|
C<respond> ist auch nicht weiter interessant: |
| 303 |
|
|
|
| 304 |
|
|
!block perl |
| 305 |
|
|
my $path = $self->{path}; |
| 306 |
|
|
|
| 307 |
|
|
stat $path |
| 308 |
|
|
or $self->err(404, "not found"); |
| 309 |
|
|
|
| 310 |
|
|
# ich glaube nicht, daß ich mir den nächsten Kommentar |
| 311 |
|
|
# hätte verkneifen können ;) |
| 312 |
|
|
# idiotic netscape sends idiotic headers AGAIN |
| 313 |
|
|
my $ims = $self->{h}{"if-modified-since"} =~ /^([^;]+)/ |
| 314 |
|
|
? str2time $1 : 0; |
| 315 |
|
|
|
| 316 |
|
|
if (-d _ && -r _) { |
| 317 |
|
|
# Verzeichnis |
| 318 |
|
|
if ($path !~ /\/$/) { |
| 319 |
|
|
# Redirect erzeugen, um einen "/" am Ende zu bekommen |
| 320 |
|
|
# (macht sich besser ;) |
| 321 |
|
|
$self->err(301, "moved permanently", { Location => "http://".$self->server_hostport."$self->{uri}/" }); |
| 322 |
|
|
} else { |
| 323 |
|
|
... verzeichnis anzeigen |
| 324 |
|
|
} |
| 325 |
|
|
} elsif (-f _ && -r _) { |
| 326 |
|
|
-x _ and $self->err(403, "forbidden"); |
| 327 |
|
|
|
| 328 |
|
|
$self->handle_file($queue_file); |
| 329 |
|
|
} else { |
| 330 |
|
|
$self->err(404, "not found"); |
| 331 |
|
|
} |
| 332 |
|
|
!endblock |
| 333 |
|
|
|
| 334 |
|
|
H1: Asynchrone Ein-/Ausgabe, und warum Linux Müll ist |
| 335 |
|
|
|
| 336 |
|
|
Eigentlich wäre jetzt C<handle_file> an der Reihe (oder die Werbepause, |
| 337 |
|
|
machen wir zuerst die Werbepause). |
| 338 |
|
|
|
| 339 |
|
|
Ich habe den Server geschrieben, um mehr Möglichkeiten und mehr |
| 340 |
|
|
Freiheiten zu erhalten, mit dem Server herumzuexperimentieren. |
| 341 |
|
|
|
| 342 |
|
|
Er war nicht schneller als thttpd. Ein C<strace> (ist fast immer sehr |
| 343 |
|
|
lehrreich) zeigte, daß der Serevr (wie thttpd) ca 90% der Realzeit im |
| 344 |
|
|
C<read>-syscall steckte. |
| 345 |
|
|
|
| 346 |
|
|
Das ist auch logisch, wenn mans weiß: bei, sagen wir, 800 gleichzeitigen |
| 347 |
|
|
Downloads kann man sich den read-ahead sonstwo hinstecken: er findet nicht |
| 348 |
|
|
statt (außer in Linux, aber damit rechne ich gleich ab). Deshalb ist |
| 349 |
|
|
jeder Zugriff auch ein Seek (minimum), und dauert somit mindestens 0.01s, |
| 350 |
|
|
manchmal auch doppelt oder dreimal so lang. Und in 0.01s könnte ich schon |
| 351 |
|
|
mehr als 100kb/s ins Internet blasen (100Mbit Netzwerkkarte). |
| 352 |
|
|
|
| 353 |
|
|
Leider kann der Webserver in dieser Zeit auch nichts anderes tun, er steht |
| 354 |
|
|
ja und wartet auf die Platte, obwohl er doch so viele andere Filehandles |
| 355 |
|
|
zu bedienen hätte. |
| 356 |
|
|
|
| 357 |
|
|
Viele Threads würden hier helfen (nein, falsch, aber dazu komme ich |
| 358 |
|
|
gleich), und viele Java-Anhänger kennen nur den einen Weg (klar, die |
| 359 |
|
|
Sprache {{kann}} es ja auch nicht anders, und wenn man nur einen Hammer |
| 360 |
|
|
hat, sieht eben alles wie ein Nagel aus), aber die wahre Lösung heißt: |
| 361 |
|
|
|
| 362 |
|
|
"Asynchrone Ein-/Ausgabe" |
| 363 |
|
|
|
| 364 |
|
|
Natürlich kann Linux das nicht. Noch nicht. Aber man hat ja Threads, was |
| 365 |
|
|
ja (Java zeigt es uns!) dasselbe ist, aber Perl kann leider keine Threads |
| 366 |
|
|
(nein, wirklich, Perl kann keine Threads). |
| 367 |
|
|
|
| 368 |
|
|
Also muss XS her. Dank Linux kann ich auch einfach gcc verlangen, und dank gcc |
| 369 |
|
|
kann ich closures benutzen, und dank closures kann ich errno ohne Assembler |
| 370 |
|
|
abfangen, und wenn man diesen Horror in ein Modul packt, merkts auch keiner: |
| 371 |
|
|
|
| 372 |
|
|
!block perl |
| 373 |
|
|
#undef errno |
| 374 |
|
|
#include <asm/unistd.h> |
| 375 |
|
|
|
| 376 |
|
|
static int |
| 377 |
|
|
aio_proc(void *thr_arg) |
| 378 |
|
|
{ |
| 379 |
|
|
aio_thread *thr = thr_arg; |
| 380 |
|
|
aio_req req; |
| 381 |
|
|
int errno; |
| 382 |
|
|
|
| 383 |
|
|
/* we rely on gcc's ability to create closures. */ |
| 384 |
|
|
_syscall3(int,lseek,int,fd,off_t,offset,int,whence) |
| 385 |
|
|
_syscall3(int,read,int,fd,char *,buf,off_t,count) |
| 386 |
|
|
_syscall3(int,write,int,fd,char *,buf,off_t,count) |
| 387 |
|
|
_syscall3(int,open,char *,pathname,int,flags,mode_t,mode) |
| 388 |
|
|
_syscall1(int,close,int,fd) |
| 389 |
|
|
|
| 390 |
|
|
sigprocmask (SIG_SETMASK, &fullsigset, 0); |
| 391 |
|
|
|
| 392 |
|
|
/* then loop */ |
| 393 |
|
|
while (read (reqpipe[0], (void *)&req, sizeof (req)) == sizeof (req)) |
| 394 |
|
|
{ |
| 395 |
|
|
req->thread = thr; |
| 396 |
|
|
errno = 0; |
| 397 |
|
|
|
| 398 |
|
|
if (req->type == REQ_READ || req->type == REQ_WRITE) |
| 399 |
|
|
{ |
| 400 |
|
|
if (lseek (req->fd, req->offset, SEEK_SET) == req->offset) |
| 401 |
|
|
{ |
| 402 |
|
|
if (req->type == REQ_READ) |
| 403 |
|
|
req->result = read (req->fd, req->dataptr, req->length); |
| 404 |
|
|
else |
| 405 |
|
|
req->result = write(req->fd, req->dataptr, req->length); |
| 406 |
|
|
} |
| 407 |
|
|
} |
| 408 |
|
|
else if (req->type == REQ_OPEN) |
| 409 |
|
|
... |
| 410 |
|
|
|
| 411 |
|
|
req->errorno = errno; |
| 412 |
|
|
write (respipe[1], (void *)&req, sizeof (req)); |
| 413 |
|
|
} |
| 414 |
|
|
|
| 415 |
|
|
return 0; |
| 416 |
|
|
} |
| 417 |
|
|
!endblock |
| 418 |
|
|
|
| 419 |
|
|
Ja, dies ist kein Perl, sondern C (aber nicht ANSI), aber dieses Jahr soll |
| 420 |
|
|
auf dem Perl-Workshop ja mehr praktisches gezeigt werden und, so leid es |
| 421 |
|
|
mir tut, hier kommt die Wirklichkeit angerollt. |
| 422 |
|
|
|
| 423 |
|
|
Aber etwas langsamer: Das Linux-AIO-Modul ist relativ klein (C ist eben |
| 424 |
|
|
umständlich). Es startet im wesentlichen einen (oder mehrere) Thread(s), |
| 425 |
|
|
die in einer Schleife auf Anfragen (von Perl) warten, diese abarbeiten und |
| 426 |
|
|
das Ergebnis zurückmelden. Da dies in einem Thread passiert, kann der |
| 427 |
|
|
eigentliche Webserver weiterarbeiten. |
| 428 |
|
|
|
| 429 |
|
|
Als Anfragen kann man read() und write() stellen, aber auch open(), denn |
| 430 |
|
|
open kann sehr lange dauern. Eigentlich sollte man auch stat() einbauen, |
| 431 |
|
|
aber dazu bin ich noch nicht gekommen. |
| 432 |
|
|
|
| 433 |
|
|
Die Anwendung ist recht einfach, statt einem: |
| 434 |
|
|
|
| 435 |
|
|
!block perl |
| 436 |
|
|
sysread $fh, $buf, $h > $bufsize ? $bufsize : $h |
| 437 |
|
|
or last; |
| 438 |
|
|
!endblock |
| 439 |
|
|
|
| 440 |
|
|
(C<last> springt aus einer hier nicht gezeigten Schleife), schreibt man "einfach": |
| 441 |
|
|
|
| 442 |
|
|
!block perl |
| 443 |
|
|
my $current = $Coro::current; |
| 444 |
|
|
my $r; |
| 445 |
|
|
|
| 446 |
|
|
aio_read($fh, $l, ($h > $bufsize ? $bufsize : $h), |
| 447 |
|
|
$buf, 0, sub { |
| 448 |
|
|
$r = $_[0]; |
| 449 |
|
|
$current->ready; |
| 450 |
|
|
}); |
| 451 |
|
|
&Coro::schedule; |
| 452 |
|
|
last unless $r; |
| 453 |
|
|
!endblock |
| 454 |
|
|
|
| 455 |
|
|
Ok, gelogen, es sieht umständlich und langsam aus. Es ist auch |
| 456 |
|
|
umständlich und langsam. Es ist genau so, wie ich es damals zum |
| 457 |
|
|
Testen geschrieben hatte, ohne Abstraktion (IO::Handle => Coro::Handle |
| 458 |
|
|
=> Linux::AIO::Handle??). Es sieht auch heute noch so aus, denn es |
| 459 |
|
|
funktioniert und war bisher nicht das Nadelöhr. |
| 460 |
|
|
|
| 461 |
|
|
C<aio_read> hat die gleichen Argumente wie C<sysread> und dann noch |
| 462 |
|
|
eins (den File-Offset) und dann noch eins (eine Code-Referenz, die |
| 463 |
|
|
aufgerufen wird, wenn die Daten gelesen wurden, es heißt ja nicht umsonst |
| 464 |
|
|
{{asynchrone}} Ein-/Ausgabe) und dann war's das aber. |
| 465 |
|
|
|
| 466 |
|
|
Nachdem der Lesevorgang "in Auftrag" gegeben wurde, legt sich die |
| 467 |
|
|
Coroutine schlafen: C<schedule> kehrt nicht von sich aus zurück. |
| 468 |
|
|
|
| 469 |
|
|
Der Callback speichert die Anzahl der gelesenen Byte ($! ist übrigens |
| 470 |
|
|
gesetzt) in C<$r> und weckt die Coroutine wieder auf, die - früher oder |
| 471 |
|
|
später - nach C<schedule> weiterläuft. |
| 472 |
|
|
|
| 473 |
|
|
H2: Linux... |
| 474 |
|
|
|
| 475 |
|
|
Jetzt kommts. AIO brachte den Webserver sofort auf 20Mbit. Toll, so shcnell war |
| 476 |
|
|
er noch nie. Aber irgendwie... irgendwie... war das wenig, denn über "Kunden" |
| 477 |
|
|
konnte sich der Webserver nicht beklagen. |
| 478 |
|
|
|
| 479 |
|
|
Was habe ich nach der Ursache gesucht. |
| 480 |
|
|
|
| 481 |
|
|
Und gesucht. |
| 482 |
|
|
|
| 483 |
|
|
Naja, vielleicht ist IDE einfach Müll, dachte ich.... |
| 484 |
|
|
|
| 485 |
|
|
Und schließlich habe ich bemerkt, daß zwar ca. 5MB/s von den Festplatten |
| 486 |
|
|
gelesen wurde, asber irgendwie nur wenig mehr als 2MB/s im Netz landeten. |
| 487 |
|
|
Merkwürdig. |
| 488 |
|
|
|
| 489 |
|
|
Zwei Wochen(!) Diskussion auf der Kernel-Liste später, war das Problem |
| 490 |
|
|
gefunden: Read-Ahead. Was normalerweise absolut notwendig ist, war hier |
| 491 |
|
|
Fatal: der Webserver liest (sagen wir mal) 256Kbyte, der Kernel hängt |
| 492 |
|
|
128Kbyte Read-Ahead dran und 600 Filehandles später wird der Speicher |
| 493 |
|
|
knapp und der Kernel schmeißt weg - genau, die Read-Ahead-Daten. |
| 494 |
|
|
|
| 495 |
|
|
Gut, es ließ sich fixen. Ich hatte noch ein anderes Problem: Zehn |
| 496 |
|
|
parallele Threads (und ca. 10 parallele Read-Requests) sollten dem Kernel |
| 497 |
|
|
erlauben, wesentlich effizienter über die Plattenoberfläche zu Rasen als |
| 498 |
|
|
immer nur einer. Leider braucht ein einzelner Read-Request, nicht 10 (oder |
| 499 |
|
|
9 mal) so lange, wie bei einem Thread sondern schlichtweg 80 oder 90 mal |
| 500 |
|
|
so lange. In Mbit: 7. Irgendwie ging dieses Problem auf der Kernel-Liste |
| 501 |
|
|
unter, und ergo benutze ich nur einen Thread. Sieht eh' viel hübscher aus. |
| 502 |
|
|
|
| 503 |
|
|
Und wenn die FreeBSD-Leute sich jetzt toll fühlen: wenn ich unter FreeBSD |
| 504 |
|
|
auf einen Event (kqueue) warte, bleiben alle Threads stehen. Yeah ;) |
| 505 |
|
|
|
| 506 |
|
|
(Aber die VM von FreeBSD ist geil!) |
| 507 |
|
|
|
| 508 |
|
|
H1: Back to the roots... |
| 509 |
|
|
|
| 510 |
|
|
... Perl! |
| 511 |
|
|
|
| 512 |
|
|
Gut. Ich war schließlich bei ca. 70Mbit (immer pro Sekunde, übrigens ;) |
| 513 |
|
|
angekommen. Die restlichen 10Mbit (am Wochenende sogar 20!) waren ganz |
| 514 |
|
|
einfach zu erreichen: Diesmal waren es {{wirkllich}} die Festplatten: Wer |
| 515 |
|
|
viel Platz braucht (und kein Geld dafür ausgeben will) landet |
| 516 |
|
|
zwangsläufig bei 80GB-Maxtor-Platten. Genau, die langsamen. |
| 517 |
|
|
|
| 518 |
|
|
Eine Beschränkung auf (willkürliche) 400 Datenverbindungen gleichzeitig |
| 519 |
|
|
(also eine Art "Download-Queue") brachte diesen erhofften Durchbruch - in |
| 520 |
|
|
nur zwei Zeilen: |
| 521 |
|
|
|
| 522 |
|
|
!block perl |
| 523 |
|
|
# Am Programmanfang |
| 524 |
|
|
my $transfers = new Coro::Semaphore 400; |
| 525 |
|
|
|
| 526 |
|
|
# In handle_file, nach dem der HTTP-Response-Header |
| 527 |
|
|
# geschickt wurde: |
| 528 |
|
|
my $gaurd = $transfers->guard; |
| 529 |
|
|
!endblock |
| 530 |
|
|
|
| 531 |
|
|
C<guard> ist ähnlich wie C<down>, leifert aber ein Objekt, das in der |
| 532 |
|
|
C<DESTROY>-Methode ein C<up> macht - also sobald sicht die Funktion |
| 533 |
|
|
beendet, abgebrochen wird, abstürzt.... |
| 534 |
|
|
|
| 535 |
|
|
H2: Ach ja, C<handle_file> und die bösen Windows-User |
| 536 |
|
|
|
| 537 |
|
|
!block perl |
| 538 |
|
|
!endblock |
| 539 |
|
|
|
| 540 |
|
|
!block perl |
| 541 |
|
|
!endblock |
| 542 |
|
|
|
| 543 |
|
|
!block perl |
| 544 |
|
|
!endblock |
| 545 |
|
|
|
| 546 |
|
|
!block perl |
| 547 |
|
|
!endblock |
| 548 |
|
|
|
| 549 |
|
|
!block perl |
| 550 |
|
|
!endblock |
| 551 |
|
|
|
| 552 |
|
|
|
| 553 |
|
|
|
| 554 |
|
|
|
| 555 |
|
|
|
| 556 |
|
|
|
| 557 |
|
|
|
| 558 |
|
|
|
| 559 |
|
|
|
