Высокопроизводительный веб-сервер приложений в C/С++

Ответ 1

У меня были те же требования к моей работе, поэтому я оценил ряд решений: mongoose, libmicrohttpd, libevent. И я также думал о написании модулей nginx. Вот краткое изложение моих выводов:

Nginx

страница проекта nginx

Мне нравится этот сервер и его много использовать. Его производительность и использование ресурсов намного лучше, чем у Apache, которые я также все еще использую, но планирую переход на nginx.

• Очень хорошая настраиваемая производительность. Богатая функциональность. Переносимость.
• Модуль API не документирован и представляется очень многословным. См. Этот nginx hello world module в качестве примера.
• Nginx не использует потоки, но использует несколько процессов. Это затрудняет работу с письмами, необходимо изучить nginx API для общей памяти и т.д.

мангуст

страница проекта mongoose

• Весь код сервера находится в одном файле mongoose.c(около 130K), без зависимостей. Это хорошо.
• Один поток на соединение, поэтому, если вам нужно concurrency, вам нужно настроить множество потоков, т.е. высокая оперативная память. Не слишком хорошо.
• Производительность хорошая, хотя и не исключительная.
• API прост, но вы должны сами составлять все HTTP-заголовки ответа, т.е. подробно изучите HTTP-протокол.

libmicrohttpd

страница проекта libmicrohttpd

• Официальный проект GNU.
• API-интерфейс Verbose кажется мне неудобным, хотя гораздо проще, чем писать модули nginx.
• Хорошая производительность в режиме keep-alive (ссылка на мои тесты ниже), не так хорошо, если вы не живете.

Libevent

страница проекта libevent

Библиотека Libevent имеет встроенный веб-сервер, называемый evhttp.

• Это событие основано на использовании libevent для этого.
• Легкий API. Создает заголовки HTTP автоматически.
• Официально однопоточный. Это главный недостаток. Я нашел взломать, что заставляет несколько экземпляров evhttp запускать одновременно прием соединений из одного и того же сокета. Не уверен, что все это безопасно и надежно.
• Производительность однопоточного evhttp удивительно бедна. Многопоточный взлом работает лучше, но все же не очень хорошо.

G-WAN

Проект G-WAN не является открытым исходным кодом, но я хотел бы сказать несколько слов об этом.

• Очень хорошая производительность, низкое использование памяти, 150 KB исполняемый файл.
• Очень удобное развертывание "сервлета": просто скопируйте файл .c в каталог csp, и запущенный сервер автоматически скомпилирует его. Изменения кода также скомпилированы "на лету".
• Простой API. Хотя в некоторых отношениях они ограничены. Богатая функциональность (json, хранилище ключей и т.д.).
• нестабильная. У меня были segfaults на статические файлы. Висит несколько примеров скриптов. (Опытный в чистой установке. Никогда не смешанные файлы разных версий).
• Только 32-битный двоичный (не больше).

Итак, как вы можете видеть, ни одна из существующих альтернатив полностью не удовлетворила меня. Поэтому я разработал свой собственный сервер, который...

NXWEB

Страница проекта NXWEB

Основные моменты:

• Очень хорошая производительность; см. контрольные показатели на странице проекта.
• Может обслуживать десятки тысяч одновременных запросов
• Малая занимаемая площадь памяти
• Многопоточная модель, предназначенная для масштабирования.
• Исключительно легкая база кода
• Простой API
• Достойная обработка протоколов HTTP
• Поддерживать соединения
• Поддержка SSL (через GNUTLS)
• HTTP-прокси (с пулом соединений keep-alive)
• Поддержка неблокирующей отправки файлов (с настраиваемым небольшим кэшем файловой памяти, предварительным кодированием файла gzip)
• Модульный дизайн для разработчиков
• Может быть запущен как демон; перезапускает себя при ошибке
• Открытый исходный код

Ограничения:

• Зависит от библиотеки libev (не больше)
• Проверено только на Linux

Ответ 2

Я бы предложил написать исполняемый файл FastCGI, который можно использовать со многими высокопроизводительными веб-серверами (даже с закрытыми исходными).

Ответ 3

Я собираюсь предложить то же самое, что и Axel Gneiting, но дал ответ с моими причинами для такого подхода:

1) HTTP не является тривиальным как протокол - написание собственного сервера или внесение изменений в готовое решение - очень сложная задача - намного сложнее, чем использование доступных API для реализации отдельного механизма обработки

2) Использование (немодифицированного) основного веб-сервера должно предоставить вам больше функциональности, чем вам нужно (поэтому у вас есть растущая комната).

3) Использование (немодифицированного) основного веб-сервера обычно означает, что он был гораздо более широко протестирован и документирован, чем система доморощенного.

4).. и его вероятность быть надежной и стабильной.

5) Используя fastCGI, вы можете использовать всевозможные языки для разработки вашей внутренней обработки в - включая С++ и C. Существуют стандартные инструментальные средства для облегчения этого.

6), в качестве альтернативы, многие веб-серверы обеспечивают поддержку для запуска запущенных двигателей интерпретатора (например, mod_php, mod_perl). Я бы посоветовал не использовать собственный собственный код в качестве модуля.

Он не может быть основан на файлах.

А? Что это значит?

Ответ 4

mongoose: один файл. Легко и просто использовать. а не asycn io, но идеально подходит для встроенных и конкретных целей.

Гван. отлично. никаких сбоев. ультра хорошо спланированная конфигурация. очень умный и легкий для разработки c/С++, другими словами, очень чистый разумный api по сравнению с nginx. обеспечивает поток на ядро. или что бы вы ни указали. отличный выбор. самый большой недостаток (возможно, им недостает в этой области): не может пройти через код.

libevent: единственный поток не является недостатком на одноядерной машине. после этого его точкой является async i/o. имеет многопоточность для других ядер.

nginx: никакого личного опыта. набрав серьезную почву на нечетком сервере. (ужасно запутанный api)

boost asio: библиотека С++ для asynchio (asio). здорово. нужен дружественный api более высокого уровня для таких простаков, как я. и другие, которые поступают из php, java, javascript, node.js и других веб-языков.

python bottle: awesome 1 файл lib (framework/system), который упрощает создание веб-приложений python. имеет /- встроенный сервер httpd, например libevent и node.js

node.js: сервер asyncio javascript. отличный выбор. к сожалению, приходится программировать в javascript, который становится утомительным. в то время как есть что сказать, чтобы выполнить работу; есть также кое-что, что можно сказать о том, чтобы наслаждаться во время процесса. надеюсь, что ни у кого не появляется node.php

Ответ 5

Я - жадный nginx пользователь; nginx записывается в C; nginx кажется, что он может сработать для вас. Если вам нужна самая лучшая скорость из nginx, я бы сделал модуль nginx. Ниже представлены сторонние модули, которые вы можете изучить, чтобы получить представление о том, что он требует.

Что касается требования длительных опросов, вы можете захотеть взглянуть на модули push push.