Это канонический вопрос о планировании емкости для веб-сайтов.
Связанный:
Какие рекомендуемые инструменты и методы планирования емкости для веб-сайтов и веб-приложений?
Пожалуйста, не стесняйтесь описывать различные инструменты и методы для различных веб-серверов, фреймворков и т. Д., А также передовой опыт, применимый к веб-серверам в целом.
Короткий ответ: на этот вопрос никто не может ответить, кроме вас.
Длинный ответ заключается в том, что сравнительный анализ вашей конкретной рабочей нагрузки - это то, что вам нужно предпринять самостоятельно, потому что это немного похоже на вопрос: «Какова длина отрезка строки?».
Простой одностраничный статический веб-сайт может быть размещен на Pentium Pro 150 и по-прежнему обслуживать тысячи показов каждый день.
Основной подход, который вам нужно предпринять, чтобы ответить на этот вопрос, - это пытаться это и посмотрим, что произойдет. Существует множество инструментов, которые можно использовать для искусственного давления на систему, чтобы увидеть, где она прогибается.
Краткий обзор этого:
В основном, чтобы протестировать какую-то нагрузку, вам нужно что-то протестировать. Настройте среду для тестирования. Если возможно, это должно быть довольно близко к вашему производственному оборудованию, иначе вам придется экстраполировать свои данные.
Настройте свои серверы, учетные записи, веб-сайты, пропускную способность и т. Д. Даже если вы делаете это на виртуальных машинах, это нормально, если вы готовы масштабировать свои результаты.
Итак, я собираюсь настроить виртуальную машину средней мощности (два ядра, 512 МБ ОЗУ, 4 ГБ жесткого диска) и установить мой любимый балансировщик нагрузки, haproxy внутри Red Hat Linux на ВМ.
У меня также будет два веб-сервера за балансировщиком нагрузки, которые я собираюсь использовать для стресс-тестирования балансировщика нагрузки. Эти два веб-сервера настроены идентично моим рабочим системам.
Вам понадобятся некоторые показатели для мониторинга, поэтому я собираюсь измерить, сколько запросов проходит на мои веб-серверы и сколько запросов я могу обработать в секунду, прежде чем пользователи начнут получать время ответа более двух секунд.
Я также собираюсь отслеживать использование ОЗУ, ЦП и диска на haproxy экземпляр, чтобы убедиться, что балансировщик нагрузки может обрабатывать соединения.
Как это сделать, во многом зависит от ваших платформ и выходит за рамки этого ответа. Возможно, вам потребуется просмотреть файлы журналов веб-сервера, запустить счетчики производительности или положиться на отчеты, предоставляемые вашим инструментом стресс-тестирования.
Несколько вещей, за которыми вы всегда хотите следить:
Вы также можете посмотреть на взаимоблокировки SQL, время поиска и т. Д. В зависимости от того, что вы конкретно тестируете.
Здесь все становится весело. Теперь вам нужно смоделировать тестовую нагрузку. Есть множество инструментов которые могут это сделать, с настраиваемыми параметрами:
Выберите число, любое число. Допустим, вы увидите, как система реагирует на 10 000 обращений в минуту. Неважно, какой номер вы выберете, потому что вы собираетесь повторять этот шаг много раз, увеличивая или уменьшая это число, чтобы увидеть, как реагирует система.
В идеале вы должны распределить эти 10 000 запросов по нескольким клиентам / узлам нагрузочного тестирования, чтобы один клиент не стал узким местом для запросов. Например, JMeter's Удаленное тестирование предоставляет центральный интерфейс для запуска нескольких клиентов с управляющей машины Jmeter.
Нажмите магию Идти нажмите кнопку и посмотрите, как ваши веб-серверы расплавляются и падают.
Итак, теперь вам нужно вернуться к вашим метрикам, которые вы собрали на шаге 2. Вы видите, что при 10 000 одновременных подключений ваш haproxy box почти не вспотел, но время отклика с двумя веб-серверами составляет чуть более пяти секунд. Это не круто - помните, ваше время отклика составляет две секунды. Итак, нам нужно внести некоторые изменения.
Теперь вам нужно ускорить работу вашего сайта более чем в два раза. Итак, вы знаете, что вам нужно либо увеличивать, либо масштабировать.
Чтобы увеличить масштаб, получите веб-серверы большего размера, больше оперативной памяти, более быстрые диски.
Для горизонтального масштабирования получите больше серверов.
Используйте свои показатели из шага 2 и тестирование, чтобы принять это решение. Например, если вы увидели, что во время тестирования дисковая задержка была огромной, вы знаете, что вам нужно увеличить масштаб и получить более быстрые жесткие диски.
Если во время теста вы увидели, что процессор загружен на 100%, возможно, вам нужно выполнить горизонтальное масштабирование, чтобы добавить дополнительные веб-серверы, чтобы снизить нагрузку на существующие серверы.
Нет общего правильного или неправильного ответа, есть только то, что подходит вам. Попробуйте увеличить масштаб, а если это не сработает, увеличьте масштаб. Или нет, решать вам и нестандартно мыслить.
Допустим, мы собираемся масштабировать. Итак, я решил клонировать два своих веб-сервера (это виртуальные машины), и теперь у меня есть четыре веб-сервера.
Начните снова с шага 3. Если вы обнаружите, что все идет не так, как вы ожидали (например, мы удвоили количество веб-серверов, но время отклика по-прежнему превышает две секунды), изучите другие узкие места. Например, вы удвоили количество веб-серверов, но по-прежнему имеете дрянной сервер базы данных. Или вы клонировали больше виртуальных машин, но поскольку они находятся на одном физическом хосте, вы только повысили конкуренцию за ресурсы серверов.
Затем вы можете использовать эту процедуру для тестирования других частей системы. Вместо того, чтобы задействовать балансировщик нагрузки, попробуйте напрямую обратиться к веб-серверу, или SQL-сервер с помощью инструмента тестирования SQL.
Планирование мощности начинается с измерения, в данном случае зависимости времени отклика от нагрузки. Как только вы узнаете, в какой степени программы замедляются с нагрузкой, что НЕ является линейной функцией, вы можете выбрать целевое время отклика, а затем узнать, какие ресурсы потребуются для достижения этой цели при заданном количестве нагрузки.
Измерение производительности всегда выполняется с помощью время единиц, как
Такие вещи, как% CPU и IOPS, зависят от системы, поэтому вы используете их только тогда, когда вы спланировали систему и измерили ее на этапе подготовки к производству, чтобы действовать как «суррогат» того, что вас волнует, времени.
Планирование мощностей - хлопотное животное. Это столько же науки, сколько и искусства (хотя определенно мрачное).
В лучшем случае вы принимаете обоснованные решения и фортуна / удача благоприятствуют вам, если реальность соответствует вашим предположениям. Если ваши потребности в допущениях соответствуют действительности, вы выглядите как мистический йог. К сожалению, если ваши предположения превышают реальность, вы, кажется, переусердствуете и потратите слишком много средств. К большому сожалению, если ваши предположения ниже возможной реальности (или неверны по другим причинам), вам не хватит мощности, которая вам нужна, и вам придется изо всех сил стараться смягчить сбои вашей стонущей инфраструктуры, из-за чего вы будете выглядеть так, как будто вы некомпетентны.
Никакого давления...
К сожалению, темное искусство планирования мощности - это нечто большее, чем можно разумно выразить в одном ответе на ошибку сервера; действительно, это тема, достойная книг.
Благо есть такая книга: "Искусство планирования мощности"
Чтобы расширить сообщение Марка Хендерсона, я пишу это специально для Apache. Если повторить то, что он сказал: «Короткий ответ: никто не может ответить на этот вопрос, кроме вас». Текст этого ответа во многом заимствован из моего ответа на аналогичный вопрос о Производительность сайта Drupal.
Apache возможно, один из (если не самый) самых популярных доступных веб-серверов. Это открытый исходный код, и он все еще активно поддерживается. Вы можете запустить его как в операционных системах Linux, так и в Windows, но он более популярен в мире Linux / Unix.
Вам следует никогда используйте готовую конфигурацию Apache. Вам всегда нужно настраивать Apache на свой сайт. Главный Конфигурация Apache файл в CentOS находится по адресу /etc/httpd/conf/httpd.conf, а основной файл конфигурации Apache в системах Ubuntu обычно находится по адресу /etc/apache2/apache2.conf. Дополнительные файлы конфигурации используются для таких вещей, как Виртуальные хосты.
Как и многие другие программы, Apache может быть гибким и настраиваться в соответствии с потребностями конкретного веб-сайта. Существуют разные модули мультиобработки что Apache можно настроить для привязки к сетевому порту, приема и обработки запросов.
В большинстве случаев в установках Apache по умолчанию, которые поставляются с серверами CentOS и Ubuntu, MPM "mod_prefork". Предполагается, что вы используете mod_prefork (если вы не уверены, то это более вероятно, но только вы можете это определить) Вот основы того, как его настроить:
MaxClients & ServerLimit переменные.Это, конечно, не окончательный ответ. Настройка вашего сервера Apache требует времени и опыта, чтобы добиться правильного результата.
Также я бы посоветовал поговорить с архитекторами и инженерами, которые проектировали / строили приложения, чтобы попытаться определить узкие места, единые точки отказа и лицензионные ограничения.