Назад | Перейти на главную страницу

Рекомендуемый серверный стек

Мы выполняем около 1000 запросов в секунду на нашем веб-сервере, и есть уровни кеширования и балансировки, прежде чем он достигнет окончательного стека LAMP. У нас есть 6 серверов Apache (Prefork MPM; 2.2.12) + PHP (5.3.2) с общим кешем памяти для обслуживания последнего запроса в случае, если это не попадет на лак. Теперь мы столкнулись с проблемой масштабирования. Мы очень критично относимся к времени отклика, и наш обратный прокси отключается от серверной части, если серверная часть не отвечает в течение секунды. При увеличении количества запросов в секунду мы сталкиваемся со все большим количеством ошибок восходящего потока, и наши машины LAMP не могут принять нагрузку.

Мы переосмысливаем новую серверную архитектуру и ищем хорошие альтернативы.

Здесь нет статических изображений / статического содержимого. На эти серверы поступают только 4 запроса (3 для сбора данных, 1 для сбора данных - динамический файл размером не более 2 КБ)

Смотрим на Apache (worker MPM) + PHP CLI nginx + PHP FPM

Мне интересно, есть ли хорошие учебные пособия или отчеты по тестированию, на которые я могу ссылаться, и есть ли какие-либо другие конфигурации, которые я мог бы сделать

Спасибо Спарш Гупта

Это очень мало информации для серверного стека:

  • вы просите рекомендации по аппаратному или программному обеспечению (при условии, что программное обеспечение)
  • Зачем вышедшие из строя серверы? (ЦП, сеть, дисковый ввод-вывод - это выход из строя восходящего потока - прочтите базу данных или любой другой вид сохраняемости, который у вас есть)
  • кажется, ты умеешь изящно терпеть неудачу. Вы все равно делаете это, если вы тайм-аут в течение секунды и что-то вернете. У вас должны быть цифры:
    • Насколько возможен отказ?
    • Когда (дата / время и количество запросов) вы прошли приемлемую частоту отказов?

Мне интересно, есть ли хорошие учебные пособия или отчеты по тестированию, на которые я могу ссылаться, и есть ли какие-либо другие конфигурации, которые я мог бы сделать

Пожалуйста, не полагайтесь на тесты, которые кто-то сделал в другом варианте использования. Пожалуйста, сделайте тесты для ваш данные, ваш поведение клиента, ваш система

Могу я предположить, что:

  • сбор данных == POST (или что-то, что хранит данные на сервере)
  • отправка данных == GET (ответ клиентам)

На самом деле это не имеет значения, но пробовали ли вы отделить «собирающие» серверы от «отправляющих» серверов?

Кэширование клиента, похоже, не помогает в вашем случае, поскольку часть сбора невозможно кэшировать.

Дикие догадки об архитектуре приложения (с точки зрения программного обеспечения):

Вы используете что-то вроде APC?

Если это возможно для вашего приложения, я бы рекомендовал переключиться на асинхронную модель.

Очень грубый:

  1. Просто отправьте «сборные» задания в очередь и
  2. немедленно отправить обратно HTTP 202 с установкой content-location в том месте, где вы ожидаете появления контента (или 302/303 с location, если клиенты являются браузерами)
  3. Пока у вас нет сообщения от рабочих, просто верните 200 с некоторым содержимым по умолчанию и
  4. если он закончен 200 с фактическим содержанием

Аппаратная мудрость:

Трудно сказать, но кажется, что простое добавление дополнительных серверов Apache может решить проблему. У вас уже есть 6, почему бы просто не добавить еще и покончить с этим - сделать некоторые расчеты, если время разработчика или оборудование дешевле, не должно быть слишком сложным. В любом случае: я бы не выбрасывал сразу «старый» сервер, просто назначил им более низкий приоритет в вашем балансировщике нагрузки.

Также вы упомянули «обратный прокси» (единственное число), пробовали ли вы масштабировать этот уровень?

В целом я бы сказал: у вас есть возможность масштабироваться, добавляя к нему больше серверов LAMP. Почему бы тебе просто не сделать это?