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

Каковы недостатки скорости при использовании нескольких серверов для обслуживания веб-сайта?

Я знаю, что на эти вопросы сложно ответить :) Но я хочу получить какое-то представление о влиянии разделения сервисов на разные серверы.

В частности, я настраиваю веб-сайт, на котором будет медиа-сервер (apache, обслуживающий статические файлы), сервер приложений (apache, обрабатывающий файлы php), главный сервер db и подчиненный сервер db.

Я собирался запустить memcached как на сервере мультимедиа, так и на сервере приложений в качестве общего пула, но мне было интересно, дорого ли это (с точки зрения времени и ресурсов)? Очевидно, что каждый раз, когда запрашивается вызов memcached (с сервера приложений), он должен установить TCP-соединение с медиа-сервером, определить, где находятся результаты, а затем вернуть их.

Для такой небольшой настройки веб-сайта было бы лучше увеличить оперативную память на сервере приложений, а НЕ объединять memcached между серверами? Или разница настолько мала, что не стоит беспокоиться?

Несмотря на то, что я использовал memcached в качестве примера, я бы предпочел, чтобы ответы были достаточно общими, поскольку тот же сценарий можно было бы применить к другим службам (например, к базе данных).

Если это небольшой веб-сайт, я думаю, что такой уровень оптимизации является излишним.

Но есть один способ узнать наверняка: Попробуй это.

Мы использовали WCAT в прошлом, чтобы отвечать на подобные вопросы в прошлом. Это отличный инструмент, чтобы увидеть, как сайт будет работать при различных нагрузках. JMeter еще один отличный инструмент для чего-то подобного.

Например, используя WCAT, мы решили получить отдельный сервер Hyper-V для размещения нашей виртуальной машины БД отдельно от виртуальной машины нашего веб-приложения (в данном случае Fogbugz). Тест показал, что даже при небольшом количестве одновременных пользователей наличие виртуальной машины БД на том же компьютере, что и виртуальная машина приложения, делало приложение непригодным для использования (узким местом был ЦП).

Нужно ответить на несколько вопросов, чтобы лучше ответить на ваш.

  • Это единый веб-сайт?
  • Использует ли он интенсивные ресурсы (тяжелое программирование на стороне сервера, потоковое видео и т. Д.)?
  • Вы просто используете видео, db и php / .net?
  • Насколько хорошо настроены серверы?
  • Какая скорость у жестких дисков и в конфигурации рейда?
  • Сколько процессоров?
  • Сколько оперативной памяти?
  • Вы используете сетевые устройства и коммутаторы 100 МБ или 1000 ГБ?
  • Какая у вас скорость восходящего потока?
  • Ваша ОС оптимизирована и оптимизирована?

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

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

Но когда я говорю, что подозреваю, что это может увеличить задержку отдельного запроса, я имею в виду величину от долей миллисекунды до нескольких десятков миллисекунд, в зависимости от настроек вашей сети. Если ваш сайт достаточно загружен, это будет значительно перевешено преимуществами скорости выполнения меньшего количества обращений к БД при вдвое большем объеме кеша. Если медиа-сервер и сервер приложений имеют примерно одинаковое оборудование, вполне вероятно, что ваш сервер приложений будет сильно загружен ЦП, а ЦП медиа-сервера будет довольно простаивать, а это означает, что вы можете получить максимальную производительность, используя memcached только на медиа-сервер, а не сервер приложений.

Единственный способ быть уверенным в оптимизации - это протестировать. Тестирование, эталонный тест, профиль и т. Д. Без тестирования вы никогда не узнаете, улучшаете ли вы производительность или ухудшаете ее. Запускайте сквозные тесты (другими словами, смоделированные веб-клиенты, выполняющие все запросы файлов, которые будет выполнять настоящий веб-клиент) с реалистичным набором пользователей (чтобы вы получили правильное сочетание попаданий и промахов в кеш), как для умеренных грузы и грузы «мы только что получили». Автоматизируйте свой тест, чтобы его можно было легко повторить. Протестируйте с memcached на обоих / всех серверах, только на одном сервере, только на другом сервере, с большим количеством ОЗУ на одном сервере, чем на другом и т. Д.