Вебрік як сервер виробництва проти тонких чи єдинорогів?

117

Здається, що це зрозуміло, що ви не повинні використовувати Webrick в якості виробничого сервера, але я не можу знайти ніде згадування, чому. Здається, що консенсус такий: "Вебрік добре для розвитку, але Тонкий або Єдиноріг - це вибір для виробництва, періоду".

Я шукав домашню сторінку тонкого сервера, і він говорить про запити / секунду, але я не дуже розумію графік, оскільки анотації немає.

Чи може хто-небудь повідомити мені, чому я повинен використовувати Thin або Unicorn порівняно з Вебріком? Чи є якась користь від використання Webrick для розвитку? Я використовую Webrick, оскільки він поставляється з рейками, і я думаю, що має бути причина, чому це за замовчуванням.

Я використовую Heroku до речі.

— Влад
джерело

Його повільність в порівнянні з іншими, як Монгрель.

— Удай

38

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

— Влад

24

Це гарне запитання.

— justingordon

29

Такі питання НЕ слід закривати. Вони корисні і корисні. Вся самоназначена поліція щодо вмісту повинна відмовитися.

— Кен Сміт

22

Я виявив це, гуглившись "Чому не використовувати WEBrick у виробництві?" тому що це питання, на яке я хочу відповісти. Я не хочу використовувати WEBrick у виробництві, але мені дуже прикро, що всі кажуть: "Очевидно, що це не для виробництва®". Це насправді не так очевидно - якби воно було, люди не досліджували б це питання, перш ніж нарешті запитати StackOverflow, як @Vlad вказує, що він це зробив. Прийнята відповідь корисна; принаймні вказує на деякі відсутні функції. Дотично, наполягаючи на тому, щоб питання було закрито, оскільки ви вважаєте, що це суперечка, не надаючи власної відповіді, не корисно.

— Джастін Форс

42

Пара важливих причин

написано в Ruby (див. http://github.com/ruby/ruby/tree/trunk/lib/webrick )
Відредагований він не має багатьох функцій, яких зазвичай потрібен виробничий веб-сайт, як, наприклад, декілька працівників (зокрема, попереднє розгортання, управління життєвим циклом, асинхронна обробка тощо), перенаправлення, переписування тощо

Коли я згадую про переадресації / переписування, я маю на увазі той факт, що за допомогою Webrick вам доведеться обробляти переписування на іншому шарі (Rack, Sinatra, Rails, користувацький код Webrick тощо). Для цього потрібно виконати додаткові рубінові "обробники", щоб виконати код перезапису. Для сайту з низьким рівнем трафіку це може бути нормально, оскільки у вас, можливо, попередньо прогріті процеси не роблять нічого. Однак для сайту з більш високим трафіком це додаткове навантаження на сервер для того, що сервери на передньому кінці (Apache, Nginx тощо) можуть обробляти, не закручуючи Ruby *, і, ймовірно, набирають швидкість.

* наприклад, якщо ви працюєте за балансиром навантаження, ви можете перенаправити весь перезаписаний трафік на сервер, на якому не встановлений рубін, а ваші основні сервери керують лише основним трафіком. Цей трафік перезапису може бути пов’язаний із змінами сайту для SEO або чимось подібним. Іншим випадком буде сайт, який містить декілька компонентів, і, можливо, один розділ - це Rails, інший - PHP, і для обох потрібні переписування (тобто перепишіть старі шляхи PHP до Rails)

— Джим Девілл
джерело

Чи не можна використовувати delay_job для обробки декількох працівників на Heroku, незалежно від того, який сервер ви використовуєте?

— Влад

Так, delay_job не пов’язаний з Webrick, якщо тільки у ваших робочих місцях не використовується API Webrick (це, чесно кажучи, кодовий запах).

— Джим Девілл

Я маю на увазі переадресації поза стеком Ruby. Як і переадресації стилю mod_rewrite. Технічно ви можете перенаправляти всередину Rack або Rails, або, можливо, навіть Вебрік (я можу помилятися), але для цього потрібен початковий рубін, який порівняно повільний проти Apache або Nginx

— Jim Deville

1

@JimDeville - Єдиноріг також написаний у Ruby

— Yarin

1

github.com/defunkt/unicorn/tree/master/ext/unicorn_http значна частина Єдинорога знаходиться в С

— Джим Девіл

4

WEBrick також не може працювати з більш довгими URI, якщо вони перевищують 2083 знаків, ви побачите збій. У тонких немає цих проблем, що зробило її перевагою - вже в розвитку.

— Майкл Шмітц
джерело

Крім того, Webrick втратив зв’язок і автоматичне відключення, коли на моєму досвіді я розробляю програмне забезпечення, і коли я вибрав WeBRICK в Heroku PaaS, автоматичне відключення компенсується високою швидкістю автоматичного включення (запускається автоматично через архітектуру Heroku )

— Даніель Антоніо Нуньес Кархуайо

3

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

Якщо ваш сайт робить щось, що вимагає часу, наприклад, надсилає електронні листи або створює PDF-файли, вам слід зробити WEBrick багатопотоковою . Ви хочете обробляти кілька запитів одночасно.

— Новичок
джерело

1

У минулому були проблеми з безпекою, але, здається, великою причиною є те, що це дійсно повільно порівняно з серверами, призначеними для виробництва.

— Бретт Геннінг
джерело

4

Ви бачили статистичне порівняння? Я також чую, як люди говорять про це (і це, мабуть, правда), але насправді не можу знайти реальне порівняння статистики ніде в Інтернеті ...

— Влад,

3

Я не думаю, що ніхто насправді орієнтується на Вебріка, оскільки він не призначений бути виробничим сервером. Єдиноріг, тонкий або пасажир добре підтримуються і набагато кращі варіанти

— Джим Девіл

0

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

— Артур Беляєв
джерело

Це не одна різьба. Або це так само, як реалізована будь-яка сучасна мова скриптів (з GIL). Але доступ до бази даних та IO у webrick повністю багатопоточний.

— Лотар