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

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

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

В частности, я создаю веб-сайт, который будет иметь медиа-сервер (Apache, обслуживающий статические файлы), сервер приложений (Apache, обрабатывающий файлы PHP), главный сервер базы данных и подчиненный сервер базы данных.

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

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

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

решение1

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

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

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

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

решение2

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

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

решение3

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

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

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

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

Связанный контент