Вот так с точки зрения FreeBSD 5.3 выглядит родной amd64:

CPU: AMD Opteron(tm) Processor 246 (2004.56-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0xf58  Stepping = 8
  Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,
SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
  AMD Features=0xe0500800<SYSCALL,NX,MMX+,LM,3DNow+,3DNow>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1

CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.12-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0xf34  Stepping = 4
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,
SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,
SSE2,SS,HTT,TM,PBE>
  Features2=0x441d<SSE3,RSVD2>,MON,DS_CPL,CNTX-ID,<b14>>
  AMD Features=0x20000800<SYSCALL,LM>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  6

nginx-0.1.13.

nginx-0.1.12.

nginx-0.1.11.

nginx-0.1.10.

nginx-0.1.9.

nginx-0.1.8.

Создан список рассылки для обсуждения вопросов, связанных с nginx.

nginx-0.1.7.

nginx-0.1.5, и даже nginx-0.1.6.

mod_accel-1.0.32.

nginx-0.1.4. В версии 0.1.3 найдена ошибка в модуле ngx_http_autoindex_module.

nginx-0.1.3. Появился модуль ngx_http_autoindex_module.

А ещё вчера стараниями Сергея Осокина и Дмитрия Морозовского появился FreeBSD порт nginx'а.

nginx-0.1.2.

nginx-0.1.1. В этой версии исправлены серьёзные ошибки, возникающие при проксировании больших ответов. Если используете nginx в режиме проксирования, то нужно обязательно обновить версию.

nginx-0.1.0.

Модуль mod_realip-2.0.

Что показывает netstat -Lan.

mod_deflate-1.0.21. Совместимость с Apache 1.3.31 и ничего более.

Три года назад вышел mod_deflate-1.0.3, а спустя 4 месяца — mod_accel-1.0.0. Если считать только физические адреса и исключить из них массовые хостинги типа Урал Релкома, то, судя по последним логам рамблеровского робота, сейчас mod_accel установлен примерно на 300-ах серверах, а mod_deflate — на 500-ах.

Немного о вчерашних бенчмарках. Я, честно говоря, думал, что безумно долгое время обработки джавовскими XSLT-процессорами вызвано инициализациями java-машины. Однако это оказалось не так. Xalan'у можно указать ключ -diag и он скажет, сколько времени заняло собственно преобразование. Так вот, судя по тому, что он выдаёт, инициализация занимает примерно 0.6 секунды. То есть, из 3 с половиной минут, которые Xalan затрачивает на трансляцию всего сайта, на инициализацию 77 запусков java-машин приходится секунд 50, а 2 с половиной минуты работает сам Xalan. Рекордсменом оказался самый большой файл — mod_accel/readme.html. Под JDK-1.4.2.04 Xalan транслирует его 4 секунды, а под JDK-1.2.2.017 — 19 секунд. Напомню, что libxslt-1.0.27 обрабатывает весь сайт за 6 секунд. Всё это запускалось под FreeBSD 4.8 на P3 733MHz, использовались Sun'овские JDK для Linux.

Предчувствия меня не обманули. Заочная личная неприязнь была не напрасной.

Кроме уже упомянутых пяти XSLT-процессоров, сегодня добавился ещё Xalan-C 1.7.0, который транслирует сайт за 24 секунды.

Два года назад я написал пару XSLT для преобразования сайта и документации из XML в HTML. В процессе написания я стал испытывать такую личную неприязнь к XSLT, что кушать не могу. Поэтому практически не трогал это хозяйство с момента создания. Однако для документации nginx этой функциональности не хватало, поэтому я решил переписать всё на XSLScript, который избавляет от необходимости писать весь этот синтаксический мусор из монстрообразных конструкций <xsl:choose>, <xsl:with-param> и им подобных, занимающих в XSLT половину объёма, и в которых теряется смысл написанного. Скрипт на XSLScript весьма компактен и транслируется в обычный XSLT один в один. Заглядывать внутрь получившегося XSLT совсем не обязательно, что не может не радовать.

Кстати, о синтаксическом мусоре. С изобретением XML идея заполонить проекты синтаксической шелухой овладевает умами всё чаще. Кроме XSLT, есть ещё два характерных примера: MSBuild и Ant.

Однако у замечательного во всех отношениях XSLScript'а есть один недостаток — он написан на java, к которой я заочно испытываю личную неприязнь. Поэтому сначала я попытался собрать XSLScript java-компилятором gcj из gcc 3.4, но не тут-то было (такое ощущение, что gcj может собрать разве что HelloWorld.java, бинарник которого получается размером около 10M). В результате всё-таки пришлось поставить JDK-1.4.2.04, и, надо заметить, jar'овские классы заработали сразу же и без проблем. Стартуют только безобразно долго. Ну, а уж коль на компьютере завелась java, то я заодно поставил и написанные на ней XSLT-процессоры — Xalan и Saxon, чтобы тестировать получающиеся XSLT на совместимость. Дело в том, что мои двухлетней давности XSLT прекрасно понимались тогдашним libxslt-1.0.9, а вот более современным libxslt-1.0.27 или 1.1.5 они уже совсем не нравятся. Более того, как выяснилось впоследствии, они не нравятся и другим XSLT-процессорам. Новые XSLT, полученные из XSLScript'а, обрабатываются без ошибок и предупреждений пятью процессорами — libxslt, Sablotron, Xalan и двумя версиями Saxon'а — 6 и 7. XT использовать не получилось, так как он застыл на уровне 1999 года и напрочь не понимает никаких кодировок, кроме iso-8859-1 и utf, а перекодировать специально для него из koi8-r в utf-8 нет никакого желания.

Ну и напоследок, бенчмарки. libxslt-1.0.27 транслирует весь сайт (77 файлов) за 6 секунд, Sablotron-1.0 — за 16, Saxon 6.5.3 — за 2 с половиной минуты, Saxon 7.9.1 — за 4 с лишним минуты и Xalan 2.6.0 — за 3 с половиной минуты. Для трансляции каждого файла java запускается заново, но, тем не менее, даже при сравнении только процессоров, написанных на java, разброс в минуты удивляет.

Вести с полей. nginx раздаёт mp3 на звуках.ру, проксирует без кэширования, сжимает HTML и раздаёт статику на foto.rambler.ru и на горячем эстонском сайте rate.ee, отдающем днём и вечером 40-60M/s.

На загруженной машине один рабочий процесс не успевает отдавать картинки по сравнению с многопроцессными серверами, например, Apache, и в результате в браузере картинки могут появляться постепенно. Поэтому пришлось сделать возможность запускать несколько рабочих процессов, хотя первоначально подобную задачу предполагалось решать с помощью потоков. Однако реализация в виде нескольких рабочих процессов значительно проще, хотя и менее эффективней, чем обработка несколькими потоками. Потоки оставлены на потом. На FreeBSD 4.x потоки будут сделаны на rfork(), mutex'ы с помощью CAS-операций и SysV семафоров, а conditional variables на SysV семафорах.

Модули, использующие kqueue, select и epoll, отлажены под нагрузкой на вышеупомянутых сайтах и признаны вполне работоспособными. С poll есть ещё некоторые проблемы.

В дополнение к gcc, icc и MSVC nginx собирается также Open Watcom C и Borland C 5.5.

Вышел mod_deflate-1.0.20.

Как я и предполагал два года назад, многопоточный mod_perl использует столько же физической памяти, как и mod_perl 1.x, и даже больше. Причина описана здесь.

Тем временем, nginx [engine x] уже поддерживает epoll и Linux rt signals. Правда, поддержка сигналов пока без обработки переполнений.

В течение двух лет я неспешно разрабатывал http сервер. Сейчас он находится в достаточно рабочем состоянии и даже раздаёт mp3 на одном известном сайте. Сервер использует два процесса — рабочий, он обрабатывает входящие соединения, и управляющий, который перезапускает рабочий процесс в случае изменения конфигурации, переоткрытия логов и аварийного завершения рабочего процесса. Кроме того, возможна работа в виде одного процесса. В этом случае при изменении конфигурации старые соединения используют прежнюю конфигурацию, а новые — новую. В принципе, в сервере одновременно может быть несколько конфигураций — старые удаляются только после того, как закроются все соединения, их использующие. Также реализована схема плавного апгрэйда сервера — по получению сигнала USR2 управляющий процесс fork()ается и загружает исполняемый файл. При этом слушающие сокеты наследуются новым сервером и он может принимать соединения наравне со старым сервером.

Рабочий процесс обрабатывает соединения, используя kqueue, select, poll и /dev/poll. Поскольку архитектура сервера модульная, то каждый из этих методов сделан в виде отдельного модуля. Собственно, и реализация протокола HTTP — это тоже набор модулей. Обработка запросов похожа на обработку в Apache — запросы проходят через несколько фаз, а ответы — через фильтры. На данный момент готово три фильтра: byte ranges (докачка), сжатие и chunked ответ. Фильтры работают с цепочками буферов, причём те из буферов, что находятся в файлах, на FreeBSD, Linux и Solaris могут выводиться с помощью sendfile. Сервер поддерживает keep-alive соединения и pipelined запросы, виртуальные сервера (ip- и name-based), умеет раздавать статику, индексы (то есть, выдачу "/index.html" вместо "/") и переписывать URI с помощью регулярных выражений. Кроме того, есть не до конца оттестированные кэш открытых файлов и кэширующий reverse proxy.

Собирается сервер тремя компиляторами: gcc, icc и под Win32 — MSVC. На Win32 платформе можно использовать select или I/O completion port, однако Win32 код ещё практически не оттестирован.

Гибкость конфигурации сервера находится на уровне Apache. Например, такой конфигурации

DocumentRoot       /site/htdocs
DirectoryIndex     index.html  index.htm
AddDefaultCharset  windows-1251
DeflateEnable      on

Alias              /images/     /site/img/
AccelPass          /proxied/    http://backend/
<Location          /proxied/>
    AccelNoCache   on
</Location>

http {
    server {
        index            index.html index.htm;
        default_charset  windows-1251;
        gzip             on;

        location / {
            root   /site/htdocs;
        }

        location /images/ {
            alias  /site/img/;
        }

        location /proxied/ {
            proxy_pass   http://backend/;
            proxy_cache  off;
        }
    }
}

В ближайшее время планируется усовершенствование rewrite модуля, ssi фильтр, charset фильтр, модуль для ограничения соединений (throttling) и поддержка методов epoll и rt signals для Linux'а.

В дальнейшем возможна поддержка потоков, во-первых, для уменьшения задержек в обслуживании клиентов при блокировании на дисковых операциях, и, во-вторых, для использования нескольких процессоров. Число потоков при этом предполагается небольшим — немногим больше числа процессоров. Вариант с несколькими рабочими процессами тоже возможен, однако в этом случае нельзя использовать общий кэш открытых файлов.