nginx-0.3.19.

nginx-0.3.18.

Последние несколько дней я изучал возможность встраивания перла в nginx на манер mod_perl. Там есть свои проблемы. Прежде всего, при программировании большинства скриптов совершенно не учитывается, что они могут блокироваться в течение продолжительного времени, ожидая ответ от базы данных или определяя IP-адрес по имени. Это не создаёт никаких проблем в Апаче, в котором каждое соединение обслуживается отдельным процессом или потоком, но в серверах, которые в одном процессе или потоке работают с тысячами соединений, это неприемлемо, поскольку в течение времени ожидания, возникшего при обработке одного соединения, все остальные тысячи обрабатываться не будут. Поэтому использовать без потерь в производительности такие скрипты, а так же многие модули CPAN, не выйдет. Их нужно переписывать с учётом неблокирующейся архитектуры.

В то же время ряд скриптов не зависят от внешних факторов и вполне могут использоваться в неблокирующемся сервере. Например, такой простенький перловый модуль (практически совместимый с mod_perl'ом) уже работает с экспериментальным модулем ngx_http_perl_module:

package hello;

use nginx;

sub handler {
    my $r = shift;

    $r->send_http_header; 
    return OK if $r->header_only;

    $r->print("hello!\n", "URI: \"", $r->uri, "\"\n");
    return OK;
}

1;
__END__

http {
    perl_modules  /usr/local/nginx/perl;
    perl_require  hello.pm;

    server {
        location / {
            perl  hello::handler;
        }
    }
}

Если скрипты не блокируются, то на один рабочий процесс nginx'а достаточно одного интерпретатора перла: интерпретатор обрабатывает запрос, выводит данные, эти данные копируются, после чего интерпретатор может обрабатывать следующий запрос, а скопированные данные отдаются клиенту уже без участия перла. Копирование в данном случае представляется меньшим злом, чем простаивание интерпретатора во время передачи данных клиенту, поскольку интерпретатор в памяти занимает как минимум 1 мегабайт, а объём данных, как правило, значительно меньше.

Для скриптов, зависящих от внешних факторов, нужен отдельный интерпретатор для каждого запроса на всё время его исполнения. Для этого используется пул интерпретаторов, как в mod_perl 2.0. Однако с вызовом perl_clone(), позволяющем уменьшить занимаемую интерпретаторами память, есть проблемы. Он может использоваться, только если perl собран с параметром -Dusethreads, что не всегда удобно. nginx'у вполне достаточно параметра -Dusemultiplicity, но perl_clone() уже не может быть использован. В этом случае nginx создаёт каждый интерпретатор с нуля, что увеличивает занимаемую память.

nginx-0.3.17.

nginx-0.3.16. Модуль ngx_http_map_module.

nginx-0.3.15.

nginx-0.3.13 и nginx-0.3.14.

На днях поставил Firefox 1.5. Особого ускорения по сравнению с 1.0.7 не заметил, но это из-за того, что компьютер быстрый, на медленном было бы заметно. Понравились две новинки — можно менять местами табы и при неудачном соединении информация об этом появляется в табе, а не в выскакивающем окошке. Зато частично перестало работать одно из двух расширений, которыми я пользуюсь — LiveHTTPHeaders — в Page Info в табе Headers не показываются строки заголовков запроса и ответа. После некоторого поиска нашлось решение этой проблемы.

nginx-0.3.12. Экспериментальный модуль ngx_http_memcached_module.

nginx-0.3.10 и nginx-0.3.11. Добавлено описание директив двух модулей: ngx_http_empty_gif_module и ngx_http_referer_module.

nginx-0.3.9.

nginx-0.3.8. Добавлено описание директив двух модулей: ngx_http_log_module и ngx_http_realip_module.

nginx-0.3.7 и патч для softupdates.

nginx-0.3.6.

nginx-0.3.5.

nginx-0.3.3 и nginx-0.3.4.

nginx-0.3.2.

nginx-0.3.1.

nginx-0.3.0. На данный момент я рассматриваю этот релиз как экспериментальный.

nginx-0.2.6.

nginx-0.2.5.

Год назад вышел nginx-0.1.0. Судя по последним логам рамблеровского робота, сейчас nginx работает примерно на 80 000 виртуальных серверах. Если же считать только физические адреса, то их около 400.

nginx-0.2.4.

nginx-0.2.2 и nginx-0.2.3.

Когда я в январе тестировал SSL-акселератор Soekris vpn1401, поддерживаемый во FreeBSD устройством hifn(4), то оказался не прав, сказав, что его симметричные шифры в HTTPS использовать не получится. Если в nginx-0.2.3 указать

ssl_prefer_server_ciphers  on;
ssl_ciphers  AES128-SHA:DES-CBC3-SHA:!EXPORT56:RC4+RSA:+SSLv2:+EXP;

то MSIE и Opera выбирают шифр DES-CBC3-SHA, а Firefox и Konqueror - AES128-SHA. Таким образом, распространённые браузеры будут использовать акселерируемые шифры и при этом сохранится совместимость с другими браузерами.

Рамблер сегодня отмечает 9 лет, хотя вряд ли кто-то может точно сказать, когда у него день рождения. Поэтому решили взять дату регистрации домена rambler.ru. А я в Рамблере работаю уже почти 5 лет.

nginx-0.2.1.

nginx-0.2.0.

Изменились имена pid-файлов, используемые во время обновления исполняемого файла. Ручное переименование теперь не нужно. Старый основной процесс добавляет к своему pid-файл суффикс ".oldbin" и запускает новый исполняемый файл. Новый основной процесс создаёт обычный pid-файл без суффикса ".newbin". Если новый основной процесс выходит, то старый процесс переименовывает свой pid-файл c суффиксом ".oldbin" в pid-файл без суффикса. При обновлении с версии 0.1.х до 0.2.0 нужно учитывать, что оба процесса — старый 0.1.x и новый 0.2.0 — используют pid-файл без суффиксов.

nginx-0.1.44.

nginx-0.1.43.

nginx-0.1.42.

nginx-0.1.41. Это последний релиз перед отпуском.

Добавлено описание директив ещё двух модулей: ngx_http_userid_module и ngx_http_headers_module.

nginx-0.1.40.

Добавлено описание директив ещё двух модулей: ngx_http_access_module и ngx_http_auth_basic_module.

Добавлено описание директив трёх модулей: ngx_http_ssi_module, ngx_http_index_module и ngx_http_autoindex_module.

За последние дни появилось описание директив трёх модулей: ngx_http_geo_module, ngx_http_gzip_module и ngx_http_ssl_module.

nginx-0.1.39.

nginx-0.1.38.

nginx-0.1.37.

nginx-0.1.36.

Очередная таблица среднего времени сборки nginx'а в секундах с оптимизацией -O на одной и той же машине разными версиями gcc. Машина медленнее, чем была в предыдущем февральском тесте, да и nginx тоже изменился. Проверить gcc 2.7, 3.0 и 3.1 не получилось, зато добавились новые 4.0 и 4.1. 4.1 удивил.

gcc 2.8.1	66.5
gcc 2.95.3	70.1
gcc 3.2.3	105.2
gcc 3.3.6	95.7
gcc 3.4.2	90.1
gcc 4.0.1	89.1
gcc 4.1.0	130.4

nginx-0.1.35.

nginx-0.1.34.

nginx-0.1.33.

nginx-0.1.32.

nginx-0.1.31.

nginx-0.1.30.

nginx-0.1.29. Много изменений, особенно в модулях ngx_http_proxy_module и ngx_http_fastcgi_module, нужно обязательно читать CHANGES.ru и документацию по этим модулям — ngx_http_proxy_module и ngx_http_fastcgi_module. Модуль ngx_http_ssi_module поддерживает обработку подзапросов, причём подзапросы на одной странице, обрабатываемые через прокси или FastCGI, работают параллельно.

А ещё появилась wiki по nginx и сайт nginx.info.

nginx-0.1.28.

В описание модуля ngx_http_rewrite_module добавлены две директивы: if и valid_referers.

nginx-0.1.27.

nginx-0.1.26. Появился модуль ngx_http_auth_basic_module.

nginx-0.1.25.

nginx-0.1.24.

nginx-0.1.23. Появился модуль ngx_http_ssi_filter_module. Пока поддерживается только команда вида <!--# echo var="HTTP_USER_AGENT" default="" -->.

nginx-0.1.21, и даже nginx-0.1.22.

Перед каждым релизом я собираю nginx несколькими компиляторами — gcc, icc, msvc, bcc и openwatcom — чтобы посмотреть, не появилось ли каких-нибудь warning'ов. Кроме того, проверяется сборка на нескольких версиях FreeBSD от 3.0 до 5.3, (в том числе и на amd64), на RedHat 6.2 и Solaris 8 и 9 (только i386). А ещё время от времени я запускаю сборку 8-ю версиями gcc — от 2.7 до 3.4. В таблице представлено среднее время сборки в секундах с оптимизацией -O на одной и той же машине разными версиями gcc:

gcc 2.7.2.3	47.4
gcc 2.8.1	46.3
gcc 2.95.4	48.2
gcc 3.0.4	70.7
gcc 3.1.1	81.3
gcc 3.2.3	81.2
gcc 3.3.4	74.5
gcc 3.4.0	65.7

gcc 3.0 собирает nginx примерно в полтора раза медленнее, чем предыдущие версии. gcc 3.1 и 3.2 ещё медленнее, и только в версии 3.3 наступил перелом. gcc 3.4 уже собирает немного быстрее 3.0, но до скорости 2.95 всё ещё далеко.

nginx-0.1.20.

mod_accel-1.0.34.

nginx-0.1.19.

Появилось описание пары директив двух модулей ngx_http_core_module и ngx_http_rewrite_module. Будем надеяться, что теперь процесс добавления документации пойдёт быстрее.

Что касается использования mod_deflate на сайте mail.ru, то, как оказалось, он там живёт уже пару лет.

nginx-0.1.18.

Судя по последним логам рамблеровского робота, nginx работает на 10 021 сайтах, но подавляющее большинство из них — это виртуальные сервера. Если же считать только физические адреса, то их 110.

А ещё вчера я заметил, что Яндекс стал использовать mod_deflate на сайте yandex.ru. А mail.ru, похоже, использует его с лета 2004. Интересно, что Яндекс собрал mod_deflate с Apache 1.3.6 — без напильника здесь не обошлось, так как патчи из дистрибутива mod_deflate не подходят к версиям, более ранним, чем 1.3.12.

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

На днях обнаружил, что gcc до версии 3.2.3 включительно (по крайней мере, в gcc 3.3.4 этой проблемы уже нет) неверно компилирует такой код на x86:

#include <stdio.h>

struct t {
    unsigned   count:4;
};

void f(struct t *t)
{
    if (t->count-- == 0) {
        printf("ok\n");

    } else {
        printf("bug\n");
    }
}

int main() {
    struct t t;
    t.count = 0;
    f(&t);
    return 0;
}

Поскольку в x86 нет операции постдекремента, то переменная уменьшается на единицу, а затем сравнивается, но не с нулём, а с -1. Но в данном случае нужно сравнивать с 15.

nginx-0.1.17. Появился модуль ngx_http_geo_module. Модуль ngx_http_rewrite_module переписан. Теперь можно делать редиректы, возвращать коды ошибок и проверять переменные и рефереры. Директивы можно использовать внутри location.

nginx-0.1.16.

mod_accel-1.0.33. Совместимость с gcc 2.x и ничего более.

nginx-0.1.15.

nginx-0.1.14. Появился модуль ngx_http_fastcgi_module.

В конце декабря я добавил в nginx поддержку SSL-акселераторов. Тестировалось это хозяйство с помощью Soekris vpn1401, который во FreeBSD поддерживается устройством hifn(4). К сожалению, для акселерации HTTPS этот прибор оказался бесполезен. В отличие от устройства ubsec(4), hifn на данный момент не поддерживает аппаратное вычисление модульной экспоненты, применяемое в алгоритмах с открытым ключом, поэтому он не может ускорить самую ресурсоёмкую часть SSL — установление соединения.

Однако и симметричные шифры использовать не удаётся. vpn1401 поддерживает DES, 3DES, AES128 и RC4, но cryptodev(4), через который OpenSSL работает с hifn, не поддерживает RC4. А MSIE и Opera не устраивают DES, 3DES и AES128, они хотят RC4. Если же разрешить использовать RC4, то и другие браузеры — Konqueror и Netscape 4 — тоже будут использовать RC4, игнорируя прочие шифры. Для Mozilla самым приоритетным является AES256, однако OpenSSL не использует аппаратный AES128 для AES256. Если же AES256 запретить, то из AES128 и RC4 Mozilla выбирает RC4. Похоже, единственный браузер, для которого 3DES более приоритетен, чем RC4 — это Links. Кстати, симметричные шифры двух других FreeBSD'шных устройств, safe(4) и ubsec(4), тоже бесполезны для HTTPS, поскольку cryptodev не даёт им возможности использовать RC4, даже если бы он был реализован аппаратно. Что касается дайджестов MD5 и SHA1, то хотя hifn и cryptodev их поддерживают, однако OpenSSL считает их аппаратную реализацию слишком медленной и вычисляет их, используя основной процессор.

Нужно заметить, что в OpenSSL операции с аппаратными акселераторами блокирующиеся, и единственный способ продолжить обработку других соединений — это использование нескольких процессов или потоков.