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

Оценка ограничений параллелизма для архитектуры AWS под управлением WordPress

Я пытаюсь оценить количество одновременных пользователей, которых может выдержать установка WordPress AWS (которая должна быть высокодоступной и поддерживать огромные нагрузки). Меня просят дать свободный диапазон, который, я бы сказал, мы можем гарантировать (они спросили парня, который плохо знаком с DevOps ...).

Архитектура выглядит следующим образом:

Некоторые условия по заявке:

Очевидно, цель состоит в том, чтобы иметь «разумное» время отклика, хотя мне не сообщили о диапазоне.

По одновременные пользователи Я имею в виду одновременные петиции или хиты. Я бы с удовольствием протестировал его, но, к сожалению, мне нужно много платных ресурсов.

Я действительно не знаю, какое обоснование здесь можно применить. Самая полезная вещь, которую я нашел до сих пор, это этот - однако условия совсем другие, и мы не можем брать числа и линейно их масштабировать. Автор сообщения измерил это с 18 t2.medium инстансов, работающих на 60%, можно запустить WP с 90 RPS и сохраняя время отклика примерно 350 мс. Распространение этого вывода на мою архитектуру ускользает от моего понимания.

В идеале, помимо ответа на мою проблему, я хотел бы получить метод, позволяющий получить правильные ответы на эти вопросы.

Обычно нас не спрашивают, сколько пользователей может выдержать данная архитектура, вместо этого нас спрашивают, какая архитектура нам нужна, чтобы выдержать данное количество пользователей. Разве это не более важный вопрос?

Так или иначе, пара замечаний:

  • Если вы проектируете свою архитектуру так, чтобы действительно масштабируемый на всех уровнях - доставка контента (Cloud Front), веб-серверы (без сохранения состояния, одноразовые), хранилище файлов (EFS, S3), база данных (например, Aurora, реплики только для чтения) - тогда вам не нужно слишком заботиться о том, сколько пользователей конкретная конфигурация может поддерживать. Если спрос ниже или выше, архитектура просто масштабируется для удовлетворения спроса.
  • Кажется, что ваша архитектура находится на правильном пути к масштабируемости, поэтому я думаю, что лучший способ - это подтвердить концепцию и сделать профессиональное нагрузочное тестирование. Есть компании, которые могут делать это из географически удаленных мест. Это покажет вам, как работает ваш дизайн, и оттуда вы сможете интерполировать различные конфигурации, необходимые для различных одновременных номеров пользователей.

  • Слово предупреждения о Типы инстансов T2 - они используют так называемые Кредиты CPU что заставляет их быстро бегать в течение короткого периода времени, а затем они замедляются. Когда они бездействуют, они снова накапливают эти кредиты и в течение некоторого времени могут снова работать быстрее. Это отлично подходит для пиковых нагрузок, но для продолжительной нагрузки вам будет лучше, например, Типы инстансов M5 (например, m5.large) - они обеспечивают стабильную производительность.

  • Лучше иметь большее количество меньших экземпляров (например. 20x m5. Большой) вместо меньшего количества больших экземпляров (например, 5x m5.2xlarge) - масштабирование более плавное, производительность диска лучше, отказ одного узла не оказывает такого большого влияния и т. д.

  • Рассмотрите возможность использования Спотовые экземпляры и Спот-флот для дополнительной экономии затрат на ваш экземпляр.

  • Вы упомянули, что служите некоторым публикации - если это статические PDF-документы, лучше хранить их в S3 и иметь CloudFront читает их прямо из S3 вообще не просматривая свой WordPress. Если они не являются общедоступными и нуждаются, например, в подписка посмотрите на Подписанные URL-адреса CloudFront / S3. Это значительно снизит нагрузку на ваши серверы WordPress.

Надеюсь, это поможет :)