Почему приложения e-commerce могут «упасть» в эту черную пятницу — ТОП-9 причин

adminComments off.

Только представьте, сколько ваших потенциальных покупателей уже предвкушают одну из главных распродаж года. После всплеска онлайн-активности, связанной с карантином, когда онлайн-продажи стремительно росли, а вместе с ними и нагрузка на ваши сервисы, приложения e-commerce ожидает еще одно испытание на прочность.В преддверии Черной пятницы большинство компаний тестируют производительность своих приложений. Многие выбирают имитацию нагрузки предыдущего года и воспроизводят в тестовых средах клиентскую активность на уровне прошлогодней Черной пятницы. В то время как 75% узких мест можно обнаружить и устранить при тестировании, к сожалению, некоторые из проблем обнаруживаются только в производственной среде. Это связано с тем, что приложения слишком сложные, чтобы их можно было тестировать в реальных сценариях. Например, сегодня большинство приложений e-commerce охватывают более 500 серверов, распределенных по множеству сетей и поставщиков услуг.

Что же может пойти не так и на какие моменты стоит обратить внимание, чтобы не разочаровать клиентов и не потерять прибыль и репутацию?

Вот 9 основных причин, из-за которых e-commerce-приложения могут «упасть» в эту Черную пятницу:

1. Пул подключений к базе данных
Почти каждая транзакция при оформлении заказа будет взаимодействовать с одной или несколькими базами данных. Поэтому соединения с этим ресурсом критически важны и именно на этом уровне часто возникают проблемы, когда количество параллельных транзакций зашкаливает. Большинство серверов приложений поставляются с установленной по умолчанию конфигурацией пула соединений в пределах от 10 до 20. Если учесть, что пропускная способность транзакций для приложений e-commerce может легко превысить 100 тыс. транзакций в минуту, легко понять, что конфигурации пула по умолчанию не достаточно. Когда пул соединений с базой данных исчерпывается, входящие запросы онлайн-заказов просто зависают в ожидании или отклоняются в связи с тайм-аутом, пока соединение снова не станет доступным.
Например, как на этом скриншоте:

2. Отсутствующие индексы баз данных
Эта первопричина проблем в некоторой степени связана с исчерпанными пулами соединений. Медленно выполняющиеся операторы SQL дольше удерживают соединение с базой данных, поэтому пулы соединений не обрабатываются с нужной скоростью, поскольку запросы занимают больше времени. Причина номер 1 медленных операторов SQL — это отсутствие индексов в таблицах базы данных, которое часто вызвано недопониманием между пишущими SQL разработчиками и администраторами баз данных, которые настраивают и поддерживают схемы базы данных. Классическое выполнение запроса «full table scan» подразумевает, что транзакция и операция базы данных должны читать все данные в таблице, прежде чем будет получен результат. Вот пример того, как это выглядит в AppDynamics:

3. Взаимная блокировка кода
Высокий уровень параллелизма транзакций часто приводит к тому, что потокам сервера приложений приходится больше бороться за ресурсы и объекты приложения. Большинство приложений e-commerce имеют некоторую форму атомарности, встроенную в их транзакции, поэтому объемы заказов и запасов контролируются, пока тысячи пользователей «охотятся» на специальные предложения и низкие цены. Если доступ к ресурсу приложения не управляется должным образом, некоторые потоки могут оказаться в тупике, а это часто может привести к зависанию и тайм-ауту сервера приложений и всех его пользовательских транзакций. Один из примеров такого сценария произошел в прошлом году, когда клиент e-commerce использовал небезопасный кэш-поток. Три потока пытались выполнить получение, установку и удаление в одном и том же кэше одновременно, в результате чего возникла взаимная блокировка кода, которая повлияла на более чем 2,5 тыс. транзакций проверки, как показано на скриншоте:

4. Исключения тайм-аута сокета
Проблемы со связью с сервером являются очевидной основной причиной «падений». Если проверить журналы сервера с помощью Sumologic или Splunk, вероятнее всего, можно будет увидеть сотни таких событий. Они представляют собой сетевые проблемы или сбои маршрутизации, когда транзакция оформления заказа пытается связаться с одним или несколькими серверами в инфраструктуре приложения. В большинстве случаев службы, к которым вы подключаетесь, не принадлежат вам, например: ресурсы поставщика услуг доставки, обработчика кредитных карт или средства обнаружения мошенничества. В дни с высокой посещаемостью, такие как Черная пятница, не только ваш сайт испытывает всплеск трафика — часто целые сети переполняются из-за высокого спроса. По прошествии некоторого времени (часто 30-45 секунд) транзакция оформления заказа просто завершится по тайм-ауту и выдаст пользователю ошибку. Нет подключения = нет дохода. Вот пример того, как это выглядит:

5. Сборка мусора
Кэш — это простой способ ускорить работу приложений. Чем ближе данные к логике приложения (в памяти), тем быстрее оно выполняется. Поэтому неудивительно, что по мере того, как память становится больше и дешевле, большинство компаний внедрили ту или иную форму кэширования в памяти, чтобы исключить доступ к базе данных для часто используемых результатов. Настали дни 64- и 128-гигабайтных куч, а это означает, что влияние таких вещей, как сборка мусора, стало более «опасным» для конечных пользователей. Сохранение кэш-данных и эффективное создание/сохранение пользовательских объектов в памяти приобретает первостепенное значение для устранения частых циклов сборки мусора. То, что у вас есть гигабайты памяти, не означает, что вы можете легкомысленно относиться к вопросам создания, сохранения и уничтожения объектов. Вот несколько скриншотов, которые показывают, как сборка мусора может «убить» ваше приложение e-commerce:

6. Транзакции с высокой загрузкой ЦП
Не секрет, что неэффективная логика приложения потребует больше циклов ЦП, чем эффективная логика. К сожалению, в прошлом самое популярное решение проблем снижения производительности заключалось в том, что поставщикам e-commerce приходилось покупать больше серверов. Больше серверов = больше мощности = больше пропускной способности транзакций. Хотя этот расчет звучит хорошо, в действительности не все транзакции e-commerce связаны с процессором. Добавление дополнительной мощности просто маскирует неэффективный код в краткосрочной перспективе и может стать причиной лишних расходов значительных сумм в долгосрочной. Если определенные транзакции в e-commerce-приложении перегружают или «сжигают» процессор, вы можете подумать об их настройке, прежде чем подписывать очередной счет на покупку нового сервера. Например:

7. Сторонние веб-службы
Если ваше приложение e-commerce построено на распределенной архитектуре SOA, у вас будет несколько слабых мест. Особенно, если некоторые из услуг предоставляются третьей стороной, и у вас нет полной видимости в этих сервисах. Например, большинство услуг по авторизации платежей и кредитных карт предоставляется сторонними поставщиками, такими как PayPal. Если эта служба замедляется или выходит из строя, транзакции оформления заказа не могут быть завершены. Следовательно, вам необходимо строго контролировать эти службы, чтобы при возникновении проблем иметь возможность быстро определить, с чем связана проблема: с вашим кодом, подключением или чьим-то сбоем. Вот пример того, как AppDynamics может помочь вам контролировать сторонние веб-службы:

8. Плохой рекурсивный код
Этот пункт похож на №6, при этом такая проблема сжигает время, а не ресурсы. Например, многие транзакции e-commerce будут запрашивать данные одновременно из нескольких источников (кэшей, баз данных, веб-сервисов). Каждый из этих кругов может быть дорогостоящим и может занимать время. Случалось, что одна транзакция поиска e-commerce вызывала одну и ту же базу данных несколько раз вместо выполнения одной операции с использованием хранимой процедуры в базе данных. Рекурсивные удаленные вызовы могут занимать всего по 10-50 миллисекунд каждый, но если они вызываются несколько раз за транзакцию, они могут добавить целые секунды к опыту вашего конечного пользователя. Например, вот та поисковая транзакция, которая заняла несколько секунд и сделала 13 тыс. обращений к базе данных:

9. Изменение конфигурации
Как бы нам ни хотелось думать, что производственная среда «заблокирована» процессом управления изменениями, это не так. Случаются сбои, люди делают ошибки, и исправления иногда применяются в спешке в 2 часа ночи 😉. Конфигурация сервера приложений может быть чувствительной, как и сети, или любые другие элементы инфраструктуры. Возможность аудита, составления отчетов и сравнения изменений конфигурации в вашем приложении дает вам мгновенную информацию о том, что конкретное изменение могло привести к поломке вашего приложения e-commerce. Например, AppDynamics может записывать любое изменение сервера приложений и показывать вам время и значения, которые были обновлены, чтобы помочь соотнести изменения с замедлением и отключениями, как, например, на этом скриншоте:

Кроме того, AppDynamics также может отслеживать доход и производительность ваших кассовых транзакций с течением времени, что помогает командам DevOps отслеживать и предупреждать о состоянии бизнеса:

Соотношение доходов и производительности
Еще одна хорошая новость: AppDynamics Pro может выявить все вышеперечисленные дефекты за считанные минуты. Можно воспользоваться бесплатной пробной версией и оценить эффективность решения.

Posted in: Блог
© 2018 Winncom Technologies. Все права защищены.
Winncom Technologies © 2021

ОСТАВЬТЕ ЗАЯВКУ И ВАМ ПЕРЕЗВОНЯТ

*поля обязательны для заполнения.

ОСТАВЬТЕ ЗАЯВКУ И ВАМ ПЕРЕЗВОНЯТ

*поля обязательны для заполнения.

ПОДПИШИТЕСЬ НА НАШУ РАССЫЛКУ

  • Безопасность
  • Построение сети
  • ЦОД
  • Беспроводные решения
  • Видеоконференцсвязь
  • Оборудование
  • Сервисное обслуживание
  • Управление проектами под ключ
  • Все

*поля обязательны для заполнения.