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

Способы оптимизации производительности веб-сайтов WordPress, Amazon EC2 Apache и RDS MySQL

У меня 6 веб-сайтов WordPress, работающих на одном экземпляре EC2. Все веб-сайты подключаются к базам данных в одном экземпляре RDS.

Ранее сегодня трафик на крупнейший веб-сайт достиг пика, и экземпляр RDS стал узким местом - загрузка ЦП составляла 100% в течение более часа. Это повлияло на все мои веб-сайты, поскольку они загружались целую вечность.

Что из следующего будет иметь наибольшее значение, чтобы я в первую очередь потратил время и силы, чтобы предотвратить повторение такой проблемы?
(Я буду работать над всем позже, мне просто нужно расставить приоритеты сейчас)

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

Дополнительная информация:

Что я уже сделал:

Использую ли я свои ресурсы расточительно или их просто недостаточно для моих веб-сайтов - или, скорее, как мне самому ответить на этот вопрос?

Запуск всего на одном экземпляре EC2 лишает вас смысла облачного развертывания: возможность автомасштабирования и самовосстановления. Как я уже писал ранее, автомасштабирование - это сердце и душа AWS, и если вы его не используете, вам лучше использовать традиционный сервер co-lo или VPS. Было бы и дешевле, и долговечнее.

Я только что завершил развертывание AWS, которое очень похоже на ваши потребности. Клиент запускает три довольно объемных сайта Wordpress (трафик немного больше, чем у вас). Конфигурация выглядит так:

  • Все в VPC для дополнительной безопасности. VPC содержит шесть подсетей в двух зонах доступности (AZ)
  • Elastic Load Balancer, охватывающий две подсети / зоны доступности.
  • Группа автомасштабируемых (AS) экземпляров m1.small служит уровнем приложения. Существует минимум два сервера приложений и максимум 10, в зависимости от нагрузки трафика. В нормальном режиме он работает всего с двумя, а средняя загрузка ЦП постоянно ниже 15%. Группа AS масштабируется вверх и вниз с двумя экземплярами одновременно, по одному в каждой зоне доступности.
  • Каждый экземпляр приложения запускает Nginx + PHP-FPM + APC. Перед этим стеком у меня установлен Varnish для дополнительного кэширования.
  • Небольшой экземпляр RDS с несколькими зонами доступности в двух частных подсетях. Даже при чрезвычайно высокой загрузке трафика его почти не трогают из-за большого количества кэширования на стороне приложения.
  • Статические ресурсы обслуживаются из Cloudfront, чтобы еще больше снизить нагрузку на серверы приложений.
  • Файлы хранятся на паре зеркальных узлов Gluster, каждый в отдельной зоне доступности для целей высокой доступности. Плавающий эластичный IP-адрес назначается одному из узлов, что дает вам SSH или SFTP-доступ к фактическим файлам Wordpress. Узлы являются частью его собственной группы AS, поэтому, если бы файловый сервер умер, он был бы автоматически убит и создан заново. При загрузке он повторно подключает том, содержащий файлы Wordpress. Автоматическое резервное копирование выполняется с помощью серии почасовых снимков томов.
  • Экземпляр t1.micro служит шлюзом NAT для экземпляров в частных подсетях.

Эта конструкция не имеет единой точки отказа *, автоматически восстанавливается в случае смерти экземпляра и достаточно умен, чтобы увеличивать или уменьшать масштаб в зависимости от потребности в ресурсах. Общая стоимость: около 200 $ / мес. если вы решите приобрести инстансы, зарезервированные на 1 год.

Я работаю над включением этой конфигурации в комбинацию шаблона CloudFormation и сценариев cloud-init / Python, которые автоматически извлекаются из Github при загрузке. По сути, это позволит любому нажать кнопку, подождать около часа, а затем вернуться, и вся эта среда будет ждать. Надеюсь, что к концу года это закончим. Если вы хотите получить копию шаблона, отправьте мне электронное письмо по адресу «jamie» на веб-сайте, указанном в моем профиле.

* Экземпляр NAT является SPoF, но это в первую очередь ограничение VPC. И это некритичный компонент, который может выйти из строя и не повлиять на приложение.