Ähem: Asynchron ohne Threads?

[jkow]

> Anders als traditionelle Webserver setzt Nginx nicht auf Threads, um Anforderungen zu verarbeiten. Stattdessen kommt eine gut skalierende, ereignisbasierte und damit asynchrone Architektur zum Einsatz.

Hier kann man sich natürlich fragen, was ein traditioneller Webserver sein soll und warum dieser auf Threads setzen sollte (Apache setzte traditionell auf mehrere Prozesse und erst "jüngst" auf Threads).

Vor allem aber fragte ich mich, wie Nginx denn asynchron die Anforderungen abarbeiten möchte, ohne Threads zu verwenden. "Ereignisbasiert"? Ja klar.. und wer arbeitet die Ereignisse dann asynchron ab?

Daher habe ich mir mal kurz die Nginx Quellen runtergeladen und siehe da:
find -name "*.c" -exec grep -nH "pthread_create" {} \;
liefert:
./os/unix/ngx_pthread_thread.c:30: err = pthread_create(tid, &thr_attr, func, arg);

Es werden also durchaus Threads verwendet. pthread_create() wird nur durch ngx_create_thread() gewrappt und diese wird dann in ngx_worker_process_cycle() verwendet, um mehrere Worker-Threads zu erstellen.

Es gibt auch die Möglichkeit, Nginx ohne Threads zu compilieren, dann werden aber anscheinend Worker-Prozesse verwendet - ganz toll, weil Prozesse gegenüber Threads ja so viel weniger Overhead bedeuten. Das ist wohl eher ein Stabilitätsfeature: Wenn ein Worker-Prozess abschmiert, kann man ihn leichter neustarten, als wenn ein Thread und damit auch der Master abschmiert.

Der Autor des Artikels meinte vielleicht, dass im Unterschied zu manch anderem Webserver nicht für jedes Request ein extra Thread erstellt wird, aber das bedeutet letztlich nur einen Verlust an Asynchronität. Das muss nicht schlecht sein, aber es ist dann schon verwirrend, wenn Asynchronität als besonderes Feature der "ereignisbasierten" Architektur hervorgehoben wird.