Консультация по организации web-серверов

  • Автор темы Автор темы deonis
  • Дата начала Дата начала

deonis

Новичок
Консультация по организации web-серверов

Возникла идея web-проекта, в рамках которого возможно будет достигнута цифра в 1000-5000 запросов в секунду. Я так понимаю обычная связка веб-сервер + язык программирования (к примеру тот же php) тут уже не сработает.

Поскольку ничем подобным не занимались ранее, возможно кто-то подскажет как можно лучше организовать принимающие web-сервера для решения такой задачи. К примеру, надо ли писать свой сервер сидящий под nginx на каком-то порту и обрабатывающего приходящие запросы или такого рода задачи можно решить существующими технологиями?

Кстати, из опыта не подскажите сколько может выдержать одновременных запросов один web-сервер (апач+php) при грамотной настройке сервера и грамотном коде с учетом кешированием? При условии, что на этом сервере только эта связка работает, а все остальное (БД, memcached и т.д.) работает отдельно. Можно на примере существующего сервиса.

P.S. Тестировали только что сервер (nginx за ним апач с php) путем отправки 10 запросов в секунду к php скрипту выдающего лишь "hello word". Загрузка процессора поднялась до 60%. Правда, на сервере еще стоит и MySQL и memcached. Это вообще нормально или сервер слабый(или плохо настроен) и должен уметь обрабатывать больше одновременных запросов?

Спасибо.
 
В гугль: "php high load".
На одном сервере врядли кто-то держит 1000-5000 запросов в секунду. Разве что в пики. Или не на PHP.
 
не надо смотреть загрузку процессоров, надо смотреть хотя бы ab

-~{}~ 14.01.09 19:08:

> 1000-5000

статику (и "почти" статику) - легко.
 
deonis
Думайте, как паралелить это все. Без знания специфики приложения никто ничего посоветивать не сможет.

Сишный демон разрабатывать и поддерживать дороже, чем РНР-код. Тут все подробности только вы знаете.

Кстати, из опыта не подскажите сколько может выдержать одновременных запросов один web-сервер
Оно равно числу воркеров. Почти на всех проектах основной ресурс мешающий увеличить количество воркеров - память. Что у вас будет - хз (может вы интегралы решаете :).

P.S. Тестировали только что сервер (nginx за ним апач с php) путем отправки 10 запросов в секунду к php скрипту выдающего лишь "hello word". Загрузка процессора поднялась до 60%.
Что-то многовато. Опкод кэшер включен? iowait скачет во время теста?

UPD: "Почти на всех проектах" следует читать, как "Почти на всех проектах, в которых я участвовал".
 
> Почти на всех проектах основной ресурс мешающий увеличить количество воркеров - апач

fixed
 
> путем отправки 10 запросов в секунду к php скрипту выдающего
> лишь "hello word". Загрузка процессора поднялась до 60%.
Жесть) Что-то не так у тебя с сервером или ты врешь)
 
Автор оригинала: fixxxer
> Почти на всех проектах основной ресурс мешающий увеличить количество воркеров - апач
fixed
Интересно, а где-нибудь водятся результаты нормальных тестов nginx+apache vs nginx+php-fpm? Ну так чтобы по честному - льются несколько файлов, пользователи данные пишут, POST'ы всяческие, сервера в боевых порядках - клином, фалангой, каре.
 
Автор оригинала: Активист
> путем отправки 10 запросов в секунду к php скрипту выдающего
> лишь "hello word". Загрузка процессора поднялась до 60%.
Жесть) Что-то не так у тебя с сервером или ты врешь)
Смысл мне врать то :).
Значит действительно что-то не так с сервером. Спасибо, будем думать.

-~{}~ 15.01.09 12:33:

Автор оригинала: fixxxer
> Почти на всех проектах основной ресурс мешающий увеличить количество воркеров - апач

fixed
То есть, попытка создания своего простого web-сервера c внедрением в него обработки постопающих запросов, а к нему будет поступать только 2 разных типа запросов, долждно существенно увеличить количество одновременно выдерживающих запросов?

-~{}~ 15.01.09 12:42:

Автор оригинала: korchasa
deonis
Думайте, как паралелить это все. Без знания специфики приложения никто ничего посоветивать не сможет.
Архитектура внедрения кластера web-серверов уже заложена. Тут стал вопрос сколько этих web-сервров надо, чтобы выдержать ту нагрузку, что я написал. Вот я и думаю не дешевле ли будет написать своего просто демона.
На счет специфики, то коннект от пользователя к серверу планируется в двух случаях: первичное получение данных, то есть "инициализация" страницы и через минуту отправка ajax-запроса на поддержание активной сессии. Все остальные данные будут получаться с помощью доступа к статике, дабы их отдавал nginx.

Автор оригинала: korchasa
deonis
Сишный демон разрабатывать и поддерживать дороже, чем РНР-код. Тут все подробности только вы знаете.
Стрем в этом плане есть, но на самом деле, как написал выше - будет лишь два типа запросов - init и удержание сессии, по идее не так много работы :) ... по идее ... :)))

Автор оригинала: korchasa
deonis
Что-то многовато. Опкод кэшер включен? iowait скачет во время теста?
Пасиб, буду долбить админа в этом направлении.
 
> Вот я и думаю не дешевле ли будет написать своего просто демона.

дешевле будет напистать модуль для нжинкс,
тк лучше вы наврятли сделаете.
есть правда одно но, воркер не должен блокироваться,
на запросах в базу например и тп.
 
интересно, что никто не поинтересовался, что аффтар имеет в виду под словом запрос
ну, и вообще, откуда у него такие цифры
 
Автор оригинала: *****
интересно, что никто не поинтересовался, что аффтар имеет в виду под словом запрос
http-запрос от брузера к серверу.

Автор оригинала: ***** ну, и вообще, откуда у него такие цифры
какие именно?

-~{}~ 15.01.09 14:31:

Автор оригинала: dr-sm
> Вот я и думаю не дешевле ли будет написать своего просто демона.

дешевле будет напистать модуль для нжинкс,
тк лучше вы наврятли сделаете.
есть правда одно но, воркер не должен блокироваться,
на запросах в базу например и тп.
Большое спасибо за наводку.
Проработаем вариант с модулем под nginx
 
http-запросы бввают разные.
если это хит к картиночным серверам - это одно.
если аякс развминутный - это другое. совсем другое. обрабатывают их совсем разные сервера. зачем все смешивать?

На мамбе сейчас 73 тысячи онлайн. если каждый делает запрос раз в минуту, то это 1500 обращений в секунду.

сессии у вас, как я понимаю, не в мемкеше?
 
Автор оригинала: *****
http-запросы бввают разные.
если это хит к картиночным серверам - это одно.
если аякс развминутный - это другое. совсем другое. обрабатывают их совсем разные сервера. зачем все смешивать?
У нас второе. Во время этих запросов идет доступ к memcached на выборку данных сессии, один запрос к БД, а также возможна уставновка нескольких кук.

Автор оригинала: ***** На мамбе сейчас 73 тысячи онлайн. если каждый делает запрос раз в минуту, то это 1500 обращений в секунду.
Интересно сколько web-серверов обрабатывает эти запросы :).

Автор оригинала: ***** сессии у вас, как я понимаю, не в мемкеше?
В мемкеше, а разве есть другой способ их хранения при использовании кластера web-серверов? Не считая конечно БД.
Если так, то буду рад узнать где об этом можно почитать.
 
deonis
Да какая разница сколько, главное распараллелить, а железки не так дорого будут стоить :)
 
не ну если серьезно то кто же так измеряет.
во первых что касается исполнения пхп, надо мерить все потенциально длительные операции, на которых скрипт блокируется, это как правило обращения по сети к какому нить сервису - субд итд.
таймеры можно расставить хотя бы ручками, записывать в лог и потом агрегировать и смотреть чо тупит.
во вторых надо измерять запросы к серверу желательно эмулируя задержки в получении контента, и считать то же что выдает аб. в это же время логировать загрузку сервера.
имея три таких лога - из пхп, с клиентов и показатели нагрузки - можно уже начинать делать выводы
 
Я бы так шел
Есть сервер с X памяти. Прикидываем, сколько горячей статики этот сервер отдает (если он ее вообще отдает) - вычитаем - оставшаяся память почти вся наша.
Смотрим как сильно может распухать php (зависит от приложения), берем максимум, и делим свободную память - получаем максимальное число воркеров... допустим 50.
Максимальное, но не оптимальное... опять же зависит от приложения. Опять же можно экспериментом - запускаем эти 50 воркеров, натравливаем ab в 50 потоков на типичную страницу и смотрим что творится с сервером - смотрим на LA. Далее уменьшая число потоков доводим до ситуации когда LA где-то не более чем в 2 раза выше числа ядер. Получили число воркеров. Оставшаяся память - под кеш.
Далее, время выполнения типичной страницы знаем... ну и получаем 1/время*воркеры запросов в секунду.
Если вдруг окажется, что LA недостаточно высок при максимальном числе воркеров - значит скрипты очень долго чего-то ждут - прямой путь к оптимизации/кешированию.
 
Сверху