Какое самое быстрое решение для веб-серверов с наименьшим объемом памяти?

Мне нужен веб-сервер, чтобы обслуживать очень простые запросы POST/GET как JSON. Мне не нужны MVC, Rails, Django. Мне нужно что-то, что занимает очень мало памяти, предпочтительно около 5K за каждый запрос. Веб-сервер будет разговаривать с бэкэнд-услугами, такими как Scribe, с помощью Facebook Thrift. Каждый HTTP-запрос также будет обращаться к базе данных SQLLite, по одному для каждого пользователя, а пользовательские данные не перекрываются. Он будет обслуживать статические html файлы, а также json webservice.

Я рассматриваю следующее:

Njinx с PHP,
Кеплер из Луа,
прокатайте свои собственные с libevent или libev, возможно, вызывая Lua, или
MochiWeb.

Какой из этих вариантов лучше всего подходит и какие другие варианты есть? Я могу использовать PHP, python или Lua для базовых сценариев и даже делать базовые C. Я склоняюсь к некоторому решению Erlang.

Ответ 1

У меня был хороший опыт работы с nginx (https://nginx.org/), в котором говорилось, что при выборе веб-сервера вы должны внимательно изучить ваши требования и принять обоснованное решение, поскольку эти вещи могут зависеть от конкретного приложения.

Вы заметите, что в этом вопросе многие люди рекомендуют g-wan, Webmachine и т.д.... это все, на что вы должны обратить внимание и оценить, насколько они быстрее для вашего варианта использования.

Это тот тип вопроса, который поощряет болельщиков, нет "правильного ответа".

Ответ 2

Как один из авторов Webmachine, я рад помочь вам. Одной из причин, по которым я слежу, является то, что даже если в Webmachine нет кода, связанного с JSON, вам может показаться полезным знать, что мы используем его ежедневно для обработки многих разных запросов и ответов JSON. Он простой, чисто расширяемый и хорошо работает.

Если вам просто нужна статическая доставка, то что-то вроде nginx или lighttpd было бы очевидным путем. Для сочетания статических и динамических запросов и встроенного хорошего поведения в Интернете вы можете найти Webmachine в хорошей форме.

Посмотрите тривиальный пример кода на http://code.google.com/p/webmachine/wiki/ExampleResources и последние сообщения в блоге http://blog.therestfulway.com/ для получения дополнительной информации.

Это хорошо сработало для нас; если у вас есть вопросы, не стесняйтесь бросать мне строку.

Ответ 3

Веб-сервер Cherokee на www.cherokee-project.com

Ответ 4

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

TrustLeap G-WAN (150 КБ, без зависимостей) предлагает Java, C/С++, Objective-C и D скрипты.

В соответствии с этими критериями он также использует меньше ресурсов памяти и ЦП, чем Nginx или Lighttpd, при этом работает быстрее:

http://www.gwan.ch/benchmark

Ответ 5

Lighttpd имеет отличный отпечаток, насколько большая часть вашей памяти, вероятно, будет затронута любым языком, который вы решите использовать (если вы не идете по маршруту C, что действительно не рекомендуется).

Ответ 6

В статье на IBM developerWorks есть довольно обширный список "легких" веб-серверов:
Легкие веб-серверы: http://www.ibm.com/developerworks/web/library/wa-ltwebserv/

Ответ 7

Mochiweb очень легкий, и он обрабатывает тупо высокую нагрузку.

Ответ 8

Самый быстрый встроенный веб-сервер - это Snorkel - проверка там веб-сайта, они уничтожили nginx в моем тестировании с использованием ab. http://sites.google.com/site/snorkelembedded

Ответ 9

G-WAN (150 КБ, включая скрипты ANSI C) имеет собственный JSON-анализатор, возможно самый быстрый доступный с учетом функций (он позволяет вам искать записи по имени или по значению в дополнение к импорту/экспорту из/в текст).

Избиение базы данных размером 150 КБ (сервер + script включен) будет сложным.

Ответ 10

Взгляните на this. Я думаю, что именно то, что вы ищете. Вам не нужен полноценный веб-сервер, поэтому использование Erlang + libevent/libev должно быть хорошим.

Ответ 11

Для C или Lua Mongoose является опцией https://github.com/valenok/mongoose. Он использует более 5 тыс. На запрос, главным образом потому, что данные для каждого соединения имеют буфер для предварительно настроенных заголовков запроса +, а максимальный размер запроса по умолчанию равен 16 тыс. Это настраивается, хотя нет проблем, чтобы сделать его менее 5k, просто измените #define MAX_REQUEST_SIZE 16384 на mongoose.c, когда вы вставляете Mongoose. С точки зрения footprint, он составляет около 50 тыс., Скомпилированных на диске, не считая Lua (в случае необходимости) и SSL (также, если вам это нужно). Продолжительность работы зависит от ОС.

Ответ 12

Поскольку вы упомянули Python, вы можете взглянуть на web.py, чтобы очень просто слушать порт 80 и сопоставить URL-адреса с действиями.

Он также будет запущен через ваш любимый CGI, если вы хотите соединить со стандартным веб-сервером (т.е. за Nginx/FastCGI), и я запишу реквизиты Nginx для массового concurrency в статических файлах. (Они использовали его с Lighttpd в Reddit.)

thttpd - это другой веб-сервер, на который я бы посмотрел, особенно если память крайне скудна, например, во встроенной системе.

Ответ 13

Взгляните на klone на сайте koanlogic.com... будучи ориентированным на встроенные системы, он очень мал, и, кстати, очень быстро: http://john.freml.in/teepeedee2-vs-klone. Это может быть написано на C/С++ (ультраэффективный) или обычный PHP/CGI (намного менее результативный), в зависимости от навыков/вкуса...

Ответ 14

Если бы код на C или С++, я думаю, lighttz будет самым быстрым и будет использовать наименьшую память. Однако причина в том, что он использует libev, и он абсолютно ничего, без поддержки php, без поддержки html - ничего. Все, что он предоставляет, - это функция обратного вызова, где u обрабатывает каждый HTTP-запрос. Вам нужно разобрать HTTP-запрос GET/POST и вернуть html в виде строки. Вы можете видеть, что он сравнивается с nginx, lighttpd, apache и т.д. И поднимается вверх (ссылка).

Ответ 15

Вы можете взглянуть на FAPWS (Fast Asynchronous Python WSGI-сервер). Философия проекта полностью соответствует вашим потребностям. http://www.fapws.org

Ответ 16

Nginx сравнивается с Varnish (кеш, используемый Facebook) и Apache Traffic Server (кеш, используемый Yahoo!):

И, Игорь Сысоев, парень позади Nginx, не получил комментариев в своем блоге.