{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

Имеет ли смысл решать вопрос нагрузки в приложении?

Денис Гордиенко, руководитель Bright Mobile, о нагрузке на примере приложения для оптовых покупателей цветов.

Решил рассказать про опыт разработки приложения для оптового дистрибьютора цветов в Краснодаре и вопросе нагрузки на БД. Отличие от большинства «цветочных» приложений в том, что оно сделано не для конечных покупателей, а для розничных продавцов, которые оформляют заказ удалённо, либо приезжая на базу.

Идея приложения

Проблема заключается в том, что цветы — это очень сезонный товар, ценники меняются постоянно, а переклеивать цены на огромном складе — это большие затраты на зарплату сотрудников. Вместо этого, товары обклеели штрихкодами и приложение выполняет сразу две функции: во-первых, это каталог, во-вторых, сканер штрих-кодов, который подтягивает цену из 1С.

Каталог отображает все цветы сразу или группирует их по типу. В каждой из лент можно добавить выбранные позиции в корзину и указать их количество (цена указана за определённую партию), отметить, что заказывается сейчас, отложить остальное на потом – и отправить заказ менеджеру на обработку.

Физически около каждого товара на базе размещён штрих-код, чтобы не нужно было постоянно переклеивать ценники. С помощью сканера приложения можно отсканировать нужный товар, после чего он автоматически добавляется в виш-лист.

Для рассылок, акций, предложений и новостей предусмотрена новостная лента. Также в приложении имеются история сканирования, где можно посмотреть предыдущие заказы, и меню с прочей информацией о компании: адрес, телефон, ссылки на социальные сети и т.д.

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

Багфикс ленты товаров

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

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

Технологии

Для начала приведу список технологий, на которых делалось приложение:

  • Сборка Ionic.Framework
  • БД FireStore
  • Push — FCM
  • Обмен данных с 1C — Node.JS
  • Авторизация — Firebase Authentication

Кроссплатформенная сборка дала плюсы в скорости и цене разработки. Требования к телефону у бизнес-приложения низкие и переплачивать за натив смысла нет. БД выбрана для работы в режиме реального времени — приложение держит соединение с базой по сокету и моментально получает обновления. Авторизация от Firebase даёт 10 тыс бесплатных СМС, что более чем достаточно для планируемой клиентской базы.

Пропадание списка товаров

При прямом получении списка товаров стали вываливаться из 50 тыс чтений в сутки бесплатного тарифа. Собственно, багом это назвать сложно, т.к. решается переводом на платный тариф.

К слову, у программистов всегда чешутся руки пооптимизировать запросы. Это хорошо, но важно понимать экономическую целесообразность. К примеру, при плановой нагрузке в 200 тыс чтений оплата составит $0,06 за 100 тыс чтений. То есть в сутки $0,09, это $2,7 в месяц.

Выгоднее платить по 167р в мес на платном тарифе, чем дополнительно заложить 40 часов разработчика на кеширование и пакетные запросы. Если ориентироваться на стандартную ставку в 1200р в час, то это добавило бы лишние 48 000р в бюджет.

Когда делать оптимизацию?

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

Предположим, что бизнес пошёл резко в гору и ежемесячно количество пользователей приложения увеличивается. Соответственно, незначительные 167р на текущем этапе будут постоянно расти. Обычно, сравнивая облачный FireStore коллеги приводят как альтернативу собственный сервер. Мол там нет аналогичной тарификации и можно не париться по количеству запросов.

Оставляю за скобками стоимость создания и развёртывания серверной архитектуры. Самый минимальный VDS можно взять примерно за 400р ($6,67) в мес, «нормальный» сервер — в районе 4000р ($66,67) в мес.

Адекватно задумываться об оптимизации было бы на этапе, когда эта самая оптимизация давала значительную выгоду перед арендой собственного сервера. То есть когда количество запросов к БД будет от минимальных 100 000 х $6,67 / $0,06 = 11 111 111 до «нормальных» 100 000 х $66,67 / $0,06 = 111 111 111.

111 миллионов запросов это достаточно абстрактная для бизнеса цифра. Поэтому переведём на заказы. В среднем, на одного пользователя, в этом приложении, чтоб он вдумчиво посидел и оформил корзину нужно 200 запросов к БД. То есть дойдя до платежа в 4000р в мес, клиент получит 10%(средняя конверсия в оплату) х 555 555 = ±55 555 заказов.

Получается за 50 тыс заказов нужно заплатить 4000р. Думаю, что загорая на Бали от такого количества денег, владелец приложения найдёт эту сумму.

0
59 комментариев
Написать комментарий...
Ринат Г.

Эм... честно говоря, судя по стэку это кусок говна запиленный на коленке, так что блин какая оптимизация, к этому дерьму такое слово не применимо. Зато очень дешево наверное. Ну помучаются, попользуются, потом закажут уже нормальную реализацию как это обычно и бывает.

Ответить
Развернуть ветку
Иван Шамаль

А какой бы стек выбрали Вы для такого проекта?

Ответить
Развернуть ветку
3 комментария
Dmitry Ds

Сервер от 200 р (Linux). На нем спокойно запускается MongoDB и API на NodeJS.

 
Работы по разработке совсем не намного больше, но в отличие от firebase - ПО полностью под контролем. 

На мой взгляд Firebase только для прототипирования (и то не до конца такое понимаю), особенно в свете возможных санкций, а так же рубильника РКН.

Ответить
Развернуть ветку
Yuri Trenin

Мой голословный ответ на заголовок поста.

Для b2b проекта на ранней стадии преждевременные оптимизации естественно не имеют смысла. Тем более, что в адекватном проекте клиент всегда будет иметь встроенную телеметрию, которая не даст проспать момент ухода латенси бэка в красную зону. В этом случае, пожалуйста, хоть десять облаков, saas, paas, faas, maas и любой ass на выбор создателей. Вероятность выжить все равно в районе 5%.

Все становится намного интереснее когда ты изучаешь разбивку костов более-менее популярного проекта,  который уже вроде бы и выжил, но развивал кодовую базу в упоре на облака. Опуская постоянную борьбу ops-стафа с латенси на чужой бесконтрольной территории с узлами имеющими отвратительный интерконнект и неспособными обработать единый стэйт проекта на одном узле, мы увидим шокирующие адекватного CFO счета от ажура, авса и прочих гулов в  30-35% от operational costs.  Упс, технологический и экономический тупик для любителей облаков.

И когда ты считаешь затраты на серверную стойку пусть даже не нового железа, но с сильным интерконнектом на 40 Gbe для изначально правильно выбранной архитектуры с in-memory db и даже пусть отстающей персистенцией на энергонезависимые носители, то понимаешь, что ее срок окупаемости  - 1 месяц начислений от облаков. Полный и быстрый контроль над всей инфраструктурой и правильный Ux для клиентов, как минимум с точки зрения латенси. Как же хорошо жить! В мечтах.

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Вы всё круто написали, но пример из статьи - это офлайн бизнес, а не сферический стартап в вакууме.
 
Я и показывал, что если заказы идут, то не жалко и на облако, а если нет, то нужно либо оптимизировать запросы, либо идею. 

Ответить
Развернуть ветку
7 комментариев
Николай Демидов

На одном теряешь,на другом выигрываешь.

Облака и managed инфраструктура значительно снижает затраты на админов и повышает надежность.
На небольших нагрузках стоимость исчезающе мала, на больших позволяет гибко скалироваться исходя из потребностей. Кто мне будет на выходные демонтировать стойку в хейтцнере?
И кучи кучи других многократно описанных преимуществ клауда по сравнению со своим железом.

Если вы уже не ИП Пупкин, который может позволить себе упавший на день сайт, но ещё не гигант, который может позволить себе несколько своих датацентров и армию админов, то прямая дорога в iaas, baas, faas и другие *aas.

Ответить
Развернуть ветку
Bulat Ziganshin

есть дешёвые облака, у того же хетцнера они по цене как обычные сервера. а всякие aws стартапы используют за счёт бесплатного tier для стартапов, там 100 тыщ выдаётся. прожираешь их и тогда уже уходишь на свои мощности :)

Ответить
Развернуть ветку
3 комментария
PV

С одной стороны облака дороже сейчас но если смотреть лет на 5-10 вперёд то скорее всего обычного хостинга не останется а хостингом станет облако. Лучше начинать готовится заранее. Например какой то ентерпрайс до сих пор может пользоваться Java 1.6-1.7 и платить Ораклу огромные деньги за поддержку потому что вовремя не перешли на новую версию не видя в этом пользы. Так же точно с меинфреймами которые выбирались потому что когда то были выгодней обычных серверов а сейчас их поддержка обходится миллионы. Универсальное решение найти сложно. 

Ответить
Развернуть ветку
Bulat Ziganshin

откройте для себя хетцнер - там цены будут от 200 р. за vm с 2 GB до 2000р. за сервер с 32 ГБ

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Тут вопрос больше в цене "напилить серверную часть с нуля". В FireStore делать пришлось чуть больше интеграции с 1С, остальное заложено в API

Ответить
Развернуть ветку
3 комментария
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Николай Демидов
 Горький опыт 
 налететь на деньги проснувшись утром после "хорошего" трафика

Интересно, почему многие боятся и не понимают облаков?
Много трафика? Возросшая нагрузка?
Так это же замечательно. Много клиентов, которые несут деньги. И сервисы отработали как надо переварив пиковую нагрузку.

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

Ответить
Развернуть ветку
12 комментариев
Денис Гордиенко
Автор

1. Архитектурой предполагалось, что БД в этом приложении больше используется как хранилище, при этом жёстких требований к реалтайму нет. Если не вдаваться в нюансы, то при использовании FireStore проще будет сделать фильтры по товарам, чем в FireBase.

2. Гуглил ещё когда делали RTPlatform, нашёл две типичные проблемы - когда программист не держит соединение, а для каждого запроса добавляет подключение/отключение от БД (болезнь собственного сервера, когда важно думать над тем, чтоб не загрузить ресурсы железа), получается ддос подключениями и солидный чек. Второе - когда идут не оптимизированные запросы. У нас недавно на багфиксе панели администратора одного приложения выяснилось, что программист, чтобы выдать в админке список пользователей, шпарит по каждому отдельный запрос. Соответственно, запрос страницы админки на 100 пользователей съедает 100 запросов. Естественно, переделывали на пакетный запрос. Обычно все такие беды проверяются на тестах и отладке, когда анализируется трафик к БД. 

Ответить
Развернуть ветку
Виталий Подольский
. Кроссплатформенная сборка дала плюсы в скорости и цене разработки.

Интересно, сколько по времени эта разработка заняла? Интересно оценить прирост в скорости относительно нейтива.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

С учётом вёрстки кастомного дизайна полтора мес

Ответить
Развернуть ветку
18 комментариев
56 комментариев
Раскрывать всегда