среда, 20 мая 2009 г.

The costs of performance failures

Все мы знаем о том, что экономить на проведении нагрузочного тестирования дорого. Я уверен, когда большинство людей говорят "дорого" они не совсем ясно представляют о каких суммах идет речь. Давайте рассмотрим простой пример во сколько обходятся "лишние" секунды ожидания для бизнеса. Допустим, есть бизнесмен Петя, который занимается продажей товаров в интернете, у интернет магазина Пети есть бек энд приложение в котором собственно и происходит обработка заказов. Основные бизнес транзакции в этом приложении :

1) Открытие заявки на товар (Open request)
2) Поиск товара (Search Item)
3) Бронирование единицы товара (Check out item)
4) Подтверждение продажи, снятие определенной суммы с кредитной карточки клиента (Pocess credit card)

Как-то Петя решил изменить дизайн своего детища и заодно добавить функционал в бек энд приложение. Петя хочет сделать все задуманное потратив как можно меньше средств. Он находит компанию , которая сделает новый дизайн быстро и при этом на 20% дешевле чем у конкурентов. При этом Петя не догадывается, что скидка в 20% просто так ниоткуда не берется, очевидно что на чем-то экономят .... В общем Петя соглашается и в итоге получает абсолютно новый магазин с хорошим дизайном и новым функционалом бек энд приложения.

Начались рабочие будни, появляются первые проблемы, оказывается новое бек энд приложение работает медленней. Петя и сотрудники "на глаз" прикидывают насколько ухудшилась производительность по четырем основным транзакциям. И получают следующее:

Открытие заявки на товар (Open request) + 4 секунды
Поиск товара (Search Item) + 7 секунд
Бронирование единицы товара (Check out item) + 6 секунд
Подтверждение продажи, снятие определенной суммы с кредитной карточки клиента (Pocess credit card) + 10 секунд

Прикинул Петя и решил : " не беда, подумаешь каких-то несколько секунд, на перекур больше уходит....." В Петином магазине работают 10 продавцов, которые обрабатывают заявки. Средняя зарплата продавца $35 в час, а средняя цена продаваемого товара $40. Каждый сотрудник в день выполняет следующее к-во транзакций:

Open request - 50 транзакций/день
Search item - 180 транзакций/день
Check out item - 30 транзакций/день
Process Credit card - 30 транзакций/день

Потеряное время в день по транзакциям для одного сотрудника составляет:

Open request - 50 * 4 сек = 200 сек
Search item - 180 * 7 сек = 1260 сек
Check out item - 30 * 6 cек = 180 сек
Pocess credit card - 30 * 10 = 300 сек

В сумме получаем 1940 сек ~ 30 минут простоя в день. Исходя из того что зарплата сотрудника $35 в час, получается, что Петя платит ежедневно ~$17 каждому сотруднику просто так, в самом прямом смысле. Соответственно для 10 сотрудников дневной убыток $175, в месяц это $4200, в год ~$50k. Как видим сумма получилась немаленькая, скорее всего, больше той которую Петя потратил на обновление своего магазина. Но это еще не конец его убыткам. Поскольку, транзакции выполняются дольше это равнозначно тому, что их к-во в дневном эквиваленте будет меньше, а значит будет меньше продано товаров, как результат потерянный доход от реализации товаров (так называемый lost income), который значительно больше предыдущих сумм.

Итак есть потерянных пол часа за которые сотрудник обычно продавал ~2 товара (30 в день), как уже было сказано средняя цена товара $40, 2*$40 = $80 итого для 10 сотрудников потерянный доход $800 в день, $24k месяц....

Вывод:

Очевидно, что в погоне за нужным функционалом и красивым GUI, нельзя "забивать" на тестирование производительности приложения(как показывает практика "забивают" многие), это как минимум, в идеале, конечно, желателен полноценный performance engineering процесс. Если у вас есть более-менее серьезное веб приложение, то вопрос о целесообразности тестирования под нагрузкой стоять не должен.

Комментариев нет:

Отправка комментария