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

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

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

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

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

Нужны несколько вопросов, отвеченных для лучше ответа на Ваш.

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

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

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

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

Единственный способ быть уверенным в оптимизации состоит в том, чтобы протестировать. Тест, сравнительный тест, профиль, и т.д. Не тестируя Вы никогда не будете знать, делаете ли Вы производительность лучше или делаете ее хуже. Запущенные сквозные тесты (другими словами, моделируемые веб-клиенты, выполняющие все запросы для файлов, реальный веб-клиент был бы) с реалистическим соединением пользователей (таким образом, Вы получаете правильное соединение удачных обращений в кэш и промахов), и для умеренных загрузок и ", мы просто получили slashdotted" загрузки. Автоматизируйте свой тест, таким образом, это легко повторяемо. Тест с memcached на и/всех серверах, только на одном сервере, только на другом сервере, с большим количеством RAM на одном сервере, чем другой, и т.д...