Список обязательных требований:
Что мне не нужно:
Есть предложения, пожалуйста?
nginx Узнайте больше на wiki-сайт nginx.
Жарко, быстро, мало. Несколько% на Обзор Netcraft.
Lighttpd приходит в голову.
Согласно Учебная документация по Lighttpd, настройка статического сервера занимает около 5 минут:
Их много, но мне лично Cherokee нравится. Он относительно новый, но очень простой в настройке с помощью встроенного веб-интерфейса.
Может быть, меня проиграют, потому что это решение не скомпилировано в собственный код согласно списку «обязательных» вопросов, но для статического контента это не намного проще, чем совместное использование текущего каталога с одним лайнером Python:
python -m SimpleHTTPServer 9914
Обратите внимание, что порт 9914 произвольный, это просто пример, в котором я нашел это решение: http://linux.byexamples.com/archives/506/python-simple-http-server-for-file-sharing
Естественно, вы также можете сделать это с помощью Perl:
perl -MIO::All -e 'io(":8080")->fork->accept->(sub { $_[0] < io(-x $1 ? "./$1 |" : $1) if /^GET \/(.*) / })'
. . . как описано на http://search.cpan.org/~ingy/IO-All-0.39/lib/IO/All.pod#A_Tiny_Web_Server
Сервер, который вы описали:
Сверхбыстрые серверы, которые также жестяная банка при необходимости обслуживать динамические страницы:
Несколько комментаторов упомянули lighttpd. Другой вариант - thttpd.
Быстрый, безопасный, эффективный, малофункциональный: общедоступный файл Дэна Бернштейна.
или kHTTPd - сервер встроенный в ядро linux?
Я бы пошел с Чероки Вот. Кроме того, я бы забыл об Apache. Мы все росли с любовью, используя apache, забавляясь с ним и mysql. У всех нас прекрасная память, и все мы знаем, как ее использовать. :)
Это, однако, прошлое, окрашенное розовыми очками. Жирное использование памяти, жирные процессы, сложные файлы конфигурации, встроенные интерпретаторы .. фех. В сегодняшнюю эпоху VPS никому больше не нужен жирный apache. Любите воспоминания, но сохраните оперативную память для своих приложений.
я использовал mathopd за последние 2 года для обслуживания статического контента [сочетание изображений на каком-то сайте электронной коммерции + несколько больших загрузок]. нет головной боли - легко настроить, просто работает и оставляет процессор в простое.
Я много лет добивался отличных результатов с thttpd, часто обслуживает 250+ запросов в секунду (и это было в среднем за час) и до 400 одновременных запросов. Использование памяти невелико, стабильность чрезвычайно высока, а нагрузка на систему практически отсутствует, даже при высокой нагрузке запросов в секунду.
Кот Билл из округа Блум, объясняет как произносится thttpd.
Возможно, вы захотите взглянуть на http://www.lighttpd.net/. Не уверен, что это перебор для ваших требований.
Существует коммерческий веб-сервер под названием Зевс это довольно широко используется в контент-индустриях, характеризующихся большим объемом статического контента. IIRC основан на async. Ввод-вывод, который очень эффективен для ЦП. Он может делать то, что вы хотите, но это не бесплатно.
OKWS - это веб-сервер, специализирующийся на создании быстрых и безопасных веб-сервисов. Он предоставляет веб-разработчикам небольшой набор инструментов, которые оказались достаточно мощными для создания сложных систем с ограниченными усилиями. Несмотря на акцент на безопасности, OKWS демонстрирует преимущества в производительности по сравнению с популярными конкурентами: при обслуживании полностью динамических рабочих нагрузок баз данных без привязки к диску пропускная способность и скорость отклика OKWS превышают Apache, вспышка (правящий король производительности веб-серверов) и Хабуб (академическая система считается самым быстрым веб-сервером Java в своем квартале). Коммерческий опыт с OKWS показывает, что система может снизить затраты на оборудование и управление системой, обеспечивая при этом гарантии безопасности, отсутствующие в существующих системах.
скопировано из okws.org
Чтобы быть более или менее полным, не забывайте Гайавата. Его разработка ведется довольно активно, и у него есть дружелюбное и отзывчивое сообщество.
Уже упоминалось большинство безопасных и легких веб-серверов (например, publicfile, Nginx, Cherokee и т. Д.). Если ни один из них не будет соответствовать вашим требованиям, я думаю, что я предлагаю разместить ваши статические файлы (активы) в AWS S3 и CloudFront и Сайты Google для ваших веб-страниц.