Настройка и тестирование под 50 000 запросов в минуту

Зачем блочить поток, работающий с клиентом?

Ну круто. Только почему действительно крупные игроки на рынке все как один переезжают на nginx?

Гибкость и нетребовательность к ресурсам. Ну плюс, очень удобная интеграция самодельных функций в парсер URI и обработку переменных.

Зачем? Ну вот зачем тащить весь этот ворох апачевого мусора, со всякими оверрайдами в систему, задача которой - принять запрос от клиента, и спихнуть в обработчик динамики?

Впрочем, ладно - я прекрасно понимаю, что истинное мнение хрен оспоришь. Нравится вам апач - пользуйтесь апачем :) У меня его уже года три как нету нигде, и слава богу.

далеко не все вещи на свете нужно делать асинхронно.

кроме того, при работе с nginx+mysql блокировки тоже будут.

ребят, объясните несведущему в чем разница апача и ngiixa 🍻

Апач более медленный, так как имеет больше функций. (например модуль PHP)

Ngix выдерживает больше запросов в секунду, так как специально для этого разработан.

zexis добавил 04.12.2009 в 12:11

Берите самое лучшее и проверенное.

Железо либо supermicro, либо интел.

10-й рейд.

RAM - 4 Гб или более.

Конкретные рекомендации можно дать только после того как вы определитесь с архетиктурой.

Интересный вопрос - использовать серверное железо или от настольного ПК.

Зависит от вашего кошелька.

Если серверное, то за ту же производительность заплатите раза в 2-3 дороже.

Хотя и хорошее железо настольного ПК может тоже работать в режиме 24х7 годами.

Я как то размещал (6 лет назад) в качестве сервера обчный домашний компьютер (MB Intel, CPU -p4 2.8 Гц) в датацентре.

2 года проработал без проблем.

Потом заменил его на настоящий сервер Supermicro.

апач - другой. это более стабильный в отношении апи конструктор (как и nginx) для

серверов (не обязательно HTTP). только в отличие от nginx - там не

навязывается единственно правильная модель конечного автомата. есть разные

MPM модули, включая гибридный mpm-event:

http://httpd.apache.org/docs/2.2/mod/event.html

который сопоставим с nginx по производительности на аналогичных

задачах (проксирование, раздача статики).

а mod_php тянуть в апач никто не заставляет. у многих гораздо лучше работает

тредовый апач (mpm-worker) + fastcgi.

цифирь имеет смысл, если он статику раздает :) а на его обычной задаче - он прокси,

пресловутое "число запросов в сек" не им одним определяется.

Outsourcenow (если я правильно понял) имел в виду его именно в контексте прокси,

где "бакендом" именно "база данных" является (и скорее всего, не SQL)

и используются неблокирующие сокеты.

Спасибо всем за ответы. Очень познавательно.

Еще парочка вопросов:

1. Обязательно ли базу и апач\nginix разносить по разным серверам при высокой нагрузке? Как должны эти серверы соединяться?(в одном датацентре кабелем?:))

2. В каких случаях производительность упирается в канал?

3. Насколько важно нахождение сервера в той же стране, что и пользователи?

4. Можете ли привести пример, когда для какого нибудь приложения используются ведущие и ведомые сервера? (слышал какой то телеком использует по ведущему серверу для базы и апача и по 2-м ведомым к ним). Какие еще типы бывают?(где мелькало "стабилизационный")

А php-скрипт многое делает?

Борис, выше выяснили - что крайне немного: split + mysql insert

Ага, перечитал тему, где-то половина ее ускользнула от меня при первом прочтении :((

В принципе, мне тоже кажется, дергать php нецелесообразно, и можно написать модуль для nginx, который будет делать это. Правда, там придется писать асинхронный коннектор к БД, что очень бажно и затянется.

Если справляется один сервер, то лучше делать на одном.

Так как не будет расходов на пересылку по сети между серверами.

Можно сервера соединить отдельным проводом, если есть свободные сетевые карты и настроить маршрутизацию.

А можно и не соединять их напрямую, а просто подключить к интернету.

Если канала не хватает

На 0,2-0,5 секнды будет быстрее ответ серверера.

Ведущий и ведомый сервера используются в MySQL.

Запись данных производится только на ведущий сервер.

А чтение производится с любого сервера.

Ведущий реплицирует данные в ведомые сервера, через какой то промежуток времени.