Найшвидший веб-сервер для розміщення статичного вмісту


12

Я оптимізував нашу систему для швидшої доставки статичного вмісту, і мені було цікаво, чи хтось має належний досвід роботи з найшвидшими веб-серверами для такої мети.

З трьох основних кандидатів, яких я розглянув - Nginx, Cherokee та Lighttpd, у кожного, схоже, є свої проблеми - але звіти, які я читав в Інтернеті, дещо упереджені і схиляються до того сервера, яким користувач користується.

Будь-які ідеї, де можна побачити належний орієнтир для цієї конкретної мети, або хоча б необ’єктивний список плюсів і мінусів? Будь-який особистий досвід та підводні камені, які я маю бути різними?

Спасибі

Редагувати: Serverfault.com дав відповідь як nginx. Я б ще хотів почути деякі думки розробників з цього кінця Всесвіту.


1
@Swader: Будь ласка, не репостуйте. Звичайний потік речей полягає в тому, щоб це питання автоматично мігрувало туди, коли отримує достатньо близьких голосів (5). Наявність двох однакових питань ускладнює наявність одного, остаточного джерела відповідей.
Камерон

Відповіді:


12

Кілька додаткових посилань та коментарів:

  • Нещодавно було порівняно порівняння Nginx, Apache, Varnish та GWan для обслуговування 100-байтних статичних файлів.
  • На сайті Cherokee є кілька орієнтирів, що порівнюють Nginx та Lighttpd.
  • Більше посилань: один , два , три , чотири , п’ять
  • Майте на увазі, що типові орієнтири мають вузьку смугу дійсності, особливо при цій великій ставці запиту. Наприклад, перший орієнтир добре, якщо всього, що ви обслуговуєте, є 100 байт-файлів, але результати можуть бути істотно різними, якщо ви використовуєте 1kb, 10kb або діапазон статичних розмірів файлів. Дуже багато опублікованих орієнтирів також мають те, що автор має хороший досвід роботи лише з одним із продуктів, це означає, що він має дуже гарну конфігурацію, а не з іншими продуктами, тобто вони мають неоптимальну або навіть погану конфігурацію, яка буде перекошеною. результати.
  • При такій великій кількості запитів буде багато речей, які можуть вплинути на результати порівняння. Не тільки конфігурація веб-сервера, але й сама конфігурація ОС та обладнання. Наприклад, використання SSD-накопичувача може збільшити кількість запитів, але може працювати з веб-сервером X краще, ніж Y.
  • Не просто дивіться на великі максимальні ставки запитів із орієнтирів, але враховуйте також середню та мінімальну. Наприклад, подивіться результати Apache за першим посиланням на орієнтир.
  • Найкращим еталоном є те, що ти робиш сам, використовуючи файли, які подаєш на обладнання, яке ти використовуєш. Навіть швидкі орієнтири можуть виявити проблеми та наслідки, які не видно з інших опублікованих результатів.
  • На цьому масштабі дійсно буде значення, чи зможете ви обслуговувати 15 к або 20 к запитів в секунду? Наприклад, при швидкості 20 кб / са 1,7 кб файл вимагатиме близько 100 ТБ пропускної здатності на місяць. Таку суму грошей, яку обійдеться пропускна здатність для придбання іншого сервера (або 10), буде порівняно дешево. Я б не вибирав лише те, який сервер дає найбільше "число", але також розглядаю, наскільки це легко налаштувати / використовувати, чи відповідає він необхідному набору функцій, чи добре підтримується він тощо.

Особисто я використовував Lighttpd роками і не міг бути щасливішим. Я насправді здивований тим, що він виконаний порівняно з Nginx в результатах еталонних показників Черокі.


Блискучі речі, дуже корисні, дуже дякую.
Шведка

G-WAN дійсно дуже швидкий. Ці посилання також цікаві. kristianlyng.wordpress.com/2011/03/16/… Лак здається дуже хорошим при великому навантаженні.
Мет

1

Журнал LinuxFormat (випуск 142, березень 2011 р.) Містить орієнтир Apache, Cherokee, Lighttpd та Nginx. Cherokee - найшвидший, більш ніж на 2 в порівнянні з Apache, і на 20% швидше, ніж у Nginx.


Дякую! Просто прочитайте статтю, і хоча шкода, лише останній абзац має деяку корисну інформацію, проте, це дуже цінний орієнтир!
Шведка

1

Якщо це суто статичний контент, то вам просто потрібен чудовий кеш перед реальним веб-сервером, я використовую ZXTM від Zeus, але є багато інших варіантів.


У моєму випадку мова йде про десятки гігабайт матеріалів у будь-яких формах від крихітних зображень до великих флеш-документів. Керівництво тут було б недостатньо, я вважаю. Швидкість обслуговування - це те, що мені потрібно підвищити, саме тому ми встановлюємо сервер статичного вмісту. Вартість - це не проблема. Завдяки тому, що ZXTM звучить цікаво, поглянемо на це.
Шведка

звучить дуже схоже на наше налаштування, у нас є кілька концертів статики, і ці zxtms роблять гарну роботу, вони 64-бітні, тому ми просто вкладаємо 192 ГБ пам’яті в кожен, і це все робиться з оперативної пам’яті.
Chopper3

Це звучить шалено ефективно та потужно. Чи можете ви назвати ще детальну інформацію про конфігурацію та тип статики, яку ви обслуговуєте? Чи спробували ви порівняти з іншими налаштуваннями, чи цей варіант ви використовували під час керування?
Шведка

1

Я не читав цю статтю - здається, він не в режимі он-лайн, її пошук шукав саме тут - але лише перегляд одного графа, який Альваро розмістив у своєму блозі, змушує мене замислитися, чому саме цей формат Linux еталон був нахилений до інших серверів, ніж Cherokee. Сталося, що я включав номери версій серверів, і щось вразило мене дивним, тому я провів кілька досліджень:

Server   | Tested (Released)   | Current (Released)
---------+---------------------+--------------------
Apache   | 2.2.14 (2009-10-05) | 2.2.17 (2010-10-19)
Cherokee | 1.0.15 (2010-12-29) | 1.0.15 (2010-12-29)
Lighttpd | 1.4.26 (2010-02-07) | 1.4.28 (2010-10-22)
Nginx    | 0.7.65 (2010-02-01) | 0.8.54 (2010-12-14)

Блискуча нова версія Cherokee була поставлена ​​проти старих --- а в деяких випадках набагато старших --- випусків інших серверів. Тому я б не приділяв надто великої ваги результатам, тим більше, що найконкурентніший сервер, Nginx, мав великий реліз з моменту тестування версії.


Це надзвичайно корисне розуміння.
Ковтунник

0

погляньте

http://www.acme.com/software/thttpd/

paypal використовує його для подачі статичного вмісту.


1
Дякую, я міг би розібратися в цьому, але я неймовірно упереджений і упереджений до людей, які займаються "програмним забезпеченням" і не можуть потрудитися створити гідний сайт. Схоже, він застряг у 1992 році і ніколи не оновлювався. Крім того, вони ніколи не порівнювали його з провідними конкурентами, про яких я згадав, цікаво, чи зможу я десь знайти гідне порівняння ...
Swader
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.