1. Специализированные http-демона
● Качественное решение
вопроса
производительности;
● Высокая стоимость
разработки;
● Особенности
эксплуатации;

2. Когда нужны и когда нет?
Нет ДА!
● Менее 1000 ● Принципиально решить
запросов в секунду; вопрос
производительности;
● Работает неплохо ● Есть время и деньги на
на стандартных разработку;
решениях;
● Нет уверенности
в квалификации
специалистов;

3. Где используются?
● Системы статистики (счётчики);
● Рекламные системы;
● Внутренние модули посещаемых сайтов;
● Чаты, мессенджеры на крупных сайтах;

4. Вопросы архитектуры
Архитектура определяется задачей, чаще всего язык C или C++.
● Однопоточная или многопоточная модель;
● Принцип работы с сетевыми соединениями;
● Необходимость работы с ФС;
● Необходимость выполнения фоновых задач;
● Общие RW-данные, вопросы блокировок;
● Вопросы старта и завершения,
непредвиденные падения;

5. Однопоточный демон wz-httpd
http://github.com/bachan/wz-httpd
● Простейший однопоточный сервер, копипаст 0w;
● Подключаемые so-модули;
● Простота разработки модулей;
● Ответы не длиннее 32К;
● Моментальный ответ, никаких ожиданий;
● Допускается создание фоновых потоков, почти
не блокирующих основной процесс;
● kevent/FreeBSD + epoll/Linux;
● Нежелательна работа с диском при обработке запросов;

6. Многопоточный демон blizzard
http://github.com/bachan/blizzard
Проектировался для обработки запросов, которые
могут обращаться к диску.
● Подключаемые so-модули;
● Два набора потоков — быстрые и медленные;
● Быстрые запросы — моментальный ответ,
обращение к диску не допускается;
● Медленные запросы могут обращаться к диску
или иному хранилищу данных;

7. Предыстория демонов-сборщиков
Чего хотелось?
● Демон-сборщик
● Однопоточная
архитектура
● Несколько
источников данных
● Сложная логика
дозапросов

8. Демона-сборщики на nginx
Плюсы Минусы
● Решают задачу; ● Сложно разрабатывать;
● Ещё сложнее
● Простая корректировать логику
эксплуатация; запросов;
● Отсутствие so-модулей;
● Отсутствие запросов
класса «отправил
и забыл».

9. Требования к новому демону
● Сравнимые с модулями nginx по
производительности и требованиям
к ресурсам;
● Простота разработки модулей;
● Модули могут не дожидаться ответов
бекендов;

10. Архитектура демона ugh
● Не отдаляться от зарекомендовавших себя
ключевых идей демона nginx;
● Однопоточный http-демон;
● Работа с сетью через libev
● Переключение между контекстами
осуществляется с помощью корутин

11. Кратко о корутинах на примере
ugh_subreq_t *r = ugh_subreq_add(
c, url, url_size UGH_SUBREQ_WAIT);
ugh_subreq_set_body(r, body, body_size);
ugh_subreq_set_header(r, ...);
ugh_subreq_set_timeout(r, 0.1);
ugh_subreq_run(r);
ugh_subreq_wait(c); /* switch coroutine */

12. Демон ugh
Исходники и пример использования:
http://github.com/bachan/ugh

13. Настоящее и будущее ugh
Сегодня Завтра
● Работающая альфа-
● Развитие возможностей
версия; конфигурирования,
директива location;
● 2 типа запросов:
с ожиданием и
● Запросы в БД (mysql, pgsql
без ожидания ответа; и другие) и другие типы
источников (fastcgi);
● Возможность сделать
несколько запросов
● Язык высокого уровня
параллельно; для написания скриптов
(php как модуль ugh);
● Некоторые плюшки nginx
(переменные, мапы,
● Больше плюшек;
апстримы и др.);

14. Спасибо за внимание!
Сергей Боченков (bachan@advaction.ru)
Панков Александр (pianist@advaction.ru)
Компания Advaction