Проблемы с производительностью приложений — контрольный список

Ваше веб-/мобильное приложение или другое решение не работает? Вот контрольный список, чтобы убедиться, что вы оптимизировали все возможное, и помочь вам устранить ошибки.

  1. Cloudwatch — проверьте использование ЦП, близко ли оно к установленному пределу? Установлены ли будильники? Проверяйте вход и выход из сети — есть ли всплеск полученных байтов? (Если использование вашего диска составляет менее 40%, вы можете сократить количество дисков вдвое. Если оно превышает 80%, у вас могут возникнуть проблемы с производительностью.)
  2. Проверьте системные журналы на предмет исчерпания памяти или ошибок переполнения диска — вы можете увидеть такие ошибки, как «oom-killer» или «failure to fork».
  3. У вас есть правильный тип экземпляра для рабочей нагрузки? Сколько раз одни и те же типы экземпляров продолжают использоваться, но рабочая нагрузка ИЗМЕНЯЕТСЯ…

https://aws.amazon.com/ec2/instance-types/

  1. Общее назначение (пример: T2 или M5): подходит для веб-серверов и репозиториев кода. Простые веб/мобильные приложения. Где рабочие нагрузки достаточно постоянны.
  2. Взрывная производительность — проверьте их для электронной коммерции или требований, при которых вы можете столкнуться с скачками производительности.
  3. Оптимизация для вычислений: потоковая передача видео или аналитика больших данных — проверьте тип экземпляра, так как каждый из них оптимизирован для конкретных случаев использования, например для обработки графики.
  4. Оптимизация для памяти: большие наборы данных в памяти с использованием RDS, Cassandra — проверьте, нужны ли вам резервные копии твердотельных хранилищ, поскольку данные могут быть потеряны для некоторых типов экземпляров, которые не сохраняют данные.
  5. Экземпляры, оптимизированные для хранения — это может сэкономить вам $$ в случае, если вам приходится хранить данные в течение многих лет, например, для периодического соответствия требованиям и аудита.
  6. При выборе экземпляра учитывайте следующее: операционная система, количество ядер ЦП, объем системной памяти (ОЗУ), требования к хранилищу, ядра графического процессора и требования к пропускной способности сети. Что-то в списке требований не соответствует приобретенному вами экземпляру?
  7. У вас смонтирован том EBS? Достигнуто ли ограничение по IOPS или пропускной способности?
  8. Балансировщики нагрузки: есть ли у вас проблемы с сетевым подключением? Возможно, стоит проверить ваши балансировщики нагрузки.
  9. Балансировщики нагрузки. У вас высокий уровень использования ОЗУ на серверных экземплярах?
  10. Балансировщики нагрузки: у вас высокая загрузка ЦП на серверных экземплярах?
  11. У вас есть правильная конфигурация веб-сервера?
  12. Убедитесь, что разрешение DNS не влияет на задержку.
  13. Проверьте целевое время отклика для балансировщика нагрузки приложения — если значение высокое, это может быть проблема с серверными экземплярами.
  14. Для серверных инстансов с высокой загрузкой ЦП вам может понадобиться более крупный тип инстанса — вам также может потребоваться пересмотреть свою архитектуру в течение более длительного времени, если она настроена на значительный рост и вы используете монолитное решение.
  15. Производительность БД: убедитесь, что у вас есть правильные типы данных и нет неэффективности, которая создает проблемы.
  16. Производительность БД: отсутствие индексов также может быть причиной снижения производительности из-за чрезмерных, неправильных или отсутствующих индексов.

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

Экземпляры подходящего размера по соображениям стоимости:

https://www.concurrencylabs.com/blog/5-steps-for-finding-optimal-ec2-infrastructure/

Краткое руководство по учету масштаба:

  1. Горизонтальное масштабирование (автоматическое масштабирование) — добавление экземпляров, позволяющих масштабировать рабочие нагрузки — в случае использования контейнерной архитектуры микросервисов это идеальный вариант.
  2. Разделение (разделение) вашей БД, чтобы частые запросы не выполнялись по всей БД для получения результата.
  3. Отделение чтения от записи — CQRS, поэтому использование Cassandra DB, например, для записи и Elastic search для чтения. Это не всегда уместно в зависимости от ваших требований.
  4. Балансировка нагрузки — убедитесь, что это настроено для обработки скачков требований к производительности.
  5. Реплики чтения в инстансах БД — к RDS и БД Aurora на Aurora можно добавить до 15 повторений чтения.
  6. Подумайте, должно ли ваше решение быть HA или отказоустойчивым — лишь немногие решения должны быть отказоустойчивыми, если только вы не работаете в среде с высоким уровнем соответствия требованиям, такой как банковское дело или здравоохранение.
  7. Кэширование ваших чтений в БД, где это возможно.
  8. Оптимизируйте свои запросы — на самом деле это случай изучения ваших бизнес-требований и того, как ваши запросы были настроены, и проверки того, насколько эффективно было реализовано то, что было реализовано. В девяти случаях из десяти есть что оптимизировать.
  9. Стоимость и масштабирование часто являются балансом — обеспечение правильного размера ваших решений может потребовать практики. Убедитесь, что ваш мониторинг настроен так, чтобы вы могли устранять неполадки и оптимизировать затраты по мере того, как вы набираете опыт работы с решением.
  10. Для пакетных рабочих нагрузок — большие пакетные рабочие нагрузки, возможно, придется разбить на более мелкие. Однако, если вам требуется много места для хранения и параллельной обработки, тогда пакетная обработка — просто неправильное решение, и вам нужно будет подумать о перестройке архитектуры с помощью таких решений, как Hadoop.

Некоторые советы:

https://medium.com/@i.gorton/six-rules-of-thumb-for-scaling-software-architectures-a831960414f9