Это канонический вопрос о планировании мощности для веб-сайтов.
Связанный:
Каковы некоторые рекомендуемые инструменты и методы планирования емкости для веб-сайтов и веб-приложений?
Пожалуйста, не стесняйтесь описывать различные инструменты и методы для различных веб-серверов, фреймворков и т. Д., А также рекомендации, применимые к веб-серверам в целом.
Ответы:
Краткий ответ: никто не может ответить на этот вопрос, кроме вас.
Длинный ответ заключается в том, что сравнительный анализ вашей конкретной рабочей нагрузки - это то, что вам нужно предпринять самостоятельно, потому что это немного похоже на вопрос «Как долго это кусок строки?».
Простой одностраничный статический веб-сайт может быть размещен на Pentium Pro 150 и по-прежнему обслуживать тысячи показов каждый день.
Чтобы ответить на этот вопрос, вам нужно использовать базовый подход и попытаться выяснить, что происходит. Существует множество инструментов, которые вы можете использовать для искусственного давления на вашу систему, чтобы увидеть, где она прогибается.
Краткий обзор этого:
По сути, для того, чтобы проверить некоторую нагрузку, вам нужно что-то проверить. Настройте среду для тестирования. Если это возможно, это должно быть довольно близкое предположение к производственному оборудованию, иначе вам придется экстраполировать ваши данные.
Настройте свои серверы, учетные записи, веб-сайты, пропускную способность и т. Д. Даже если вы делаете это на виртуальных машинах, это нормально, если вы готовы масштабировать свои результаты.
Итак, я собираюсь настроить виртуальную машину средней мощности (два ядра, 512 МБ ОЗУ, 4 ГБ HDD) и установить свой любимый балансировщик нагрузки haproxyв Red Hat Linux на виртуальной машине .
У меня также будет два веб-сервера за балансировщиком нагрузки, которые я собираюсь использовать для стресс-теста балансировщика нагрузки. Эти два веб-сервера идентичны моим живым системам.
Вам понадобятся некоторые показатели для мониторинга, поэтому я собираюсь измерить, сколько запросов поступает на мои веб-серверы, и сколько запросов я могу обработать в секунду, прежде чем пользователи начнут получать время ответа более двух секунд.
Я также собираюсь отслеживать использование ОЗУ, ЦП и диска в haproxyэкземпляре, чтобы убедиться, что балансировщик нагрузки может обрабатывать соединения.
Как это сделать, во многом зависит от ваших платформ и выходит за рамки этого ответа. Вам может понадобиться просмотреть файлы журналов веб-сервера, запустить счетчики производительности или использовать возможности отчетов инструмента стресс-тестирования.
Несколько вещей, которые вы всегда хотите контролировать:
Вы также можете посмотреть на взаимоблокировки SQL, время поиска и т. Д. В зависимости от того, что именно вы тестируете.
Здесь все становится веселее. Теперь вам нужно смоделировать тестовую нагрузку. Есть много инструментов, которые могут сделать это, с настраиваемыми параметрами:
Выберите номер, любой номер. Допустим, вы увидите, как система отвечает 10 000 обращений в минуту. Неважно, какой номер вы выберете, потому что вы будете повторять этот шаг много раз, настраивая его вверх или вниз, чтобы увидеть реакцию системы.
В идеале вы должны распределить эти 10 000 запросов по нескольким клиентам / узлам нагрузочного тестирования, чтобы один клиент не стал узким местом запросов. Например, удаленное тестирование JMeter предоставляет центральный интерфейс для запуска нескольких клиентов с управляющего компьютера Jmeter.
Нажмите волшебную кнопку « Перейти» и наблюдайте, как веб-серверы тают и вылетают.
Итак, теперь вам нужно вернуться к показателям, которые вы собрали на шаге 2. Вы видите, что при 10000 одновременных подключений ваш haproxyящик едва ли потеет, но время отклика с двумя веб-серверами составляет всего пять секунд. Это не круто - помните, ваше время отклика составляет две секунды. Итак, нам нужно внести некоторые изменения.
Теперь вам нужно ускорить ваш сайт более чем в два раза. Итак, вы знаете, что вам нужно либо увеличить, либо уменьшить масштаб.
Чтобы увеличить масштаб, получите больше веб-серверов, больше оперативной памяти, более быстрые диски.
Чтобы масштабировать, получите больше серверов.
Используйте свои показатели из шага 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 занимает много времени и требует опыта, чтобы разобраться.