Имеет ли смысл решать вопрос нагрузки в приложении?
Решил рассказать про опыт разработки приложения для оптового дистрибьютора цветов в Краснодаре и вопросе нагрузки на БД. Отличие от большинства «цветочных» приложений в том, что оно сделано не для конечных покупателей, а для розничных продавцов, которые оформляют заказ удалённо, либо приезжая на базу.
Комментарий недоступен
Горький опыт
налететь на деньги проснувшись утром после "хорошего" трафика
Интересно, почему многие боятся и не понимают облаков?
Много трафика? Возросшая нагрузка?
Так это же замечательно. Много клиентов, которые несут деньги. И сервисы отработали как надо переварив пиковую нагрузку.
А используй вы неклауд, у вас были бы фиксированные расходы на серверы, да, но под нагрузкой сервер вряд-ли выжил, компания не получила бы клиентов, а админов поднимали бы ночью, что бы что-то сделать. Чем оно лучше?
1. Архитектурой предполагалось, что БД в этом приложении больше используется как хранилище, при этом жёстких требований к реалтайму нет. Если не вдаваться в нюансы, то при использовании FireStore проще будет сделать фильтры по товарам, чем в FireBase.
2. Гуглил ещё когда делали RTPlatform, нашёл две типичные проблемы - когда программист не держит соединение, а для каждого запроса добавляет подключение/отключение от БД (болезнь собственного сервера, когда важно думать над тем, чтоб не загрузить ресурсы железа), получается ддос подключениями и солидный чек. Второе - когда идут не оптимизированные запросы. У нас недавно на багфиксе панели администратора одного приложения выяснилось, что программист, чтобы выдать в админке список пользователей, шпарит по каждому отдельный запрос. Соответственно, запрос страницы админки на 100 пользователей съедает 100 запросов. Естественно, переделывали на пакетный запрос. Обычно все такие беды проверяются на тестах и отладке, когда анализируется трафик к БД.