Сколько пользователей выдержит система: как считают нагрузку

Почему это решают до первой строки кода

Почти каждая переделка, за которой к нам приходят, началась одинаково: систему спроектировали под десять пользователей, а через два года в ней работает триста.

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

Поэтому неудобные вопросы задаются в начале, даже если заказчику кажется, что «нам столько не нужно».

Какие вопросы задают на проектировании

Сколько человек работает одновременно в пиковый час? Не сколько всего сотрудников, а сколько реально нажимают кнопки в 10 утра понедельника.

Сколько документов в день? Двадцать заказов и две тысячи — это разные требования к спискам, поиску и отчётам.

Сколько данных накопится за три года? Таблица, которая прекрасно работает на десяти тысячах строк, на десяти миллионах ведёт себя иначе.

Что происходит в сезон? У многих компаний нагрузка неравномерна: декабрь или конец месяца дают пик в несколько раз выше среднего.

Что должно работать при отказе внешней системы? Если 1С недоступна, продолжают ли работать продажи?

Три ошибки, которые не видно на тестовых данных

Отчёт, который читает всю историю при каждом открытии. На сотне записей мгновенно, на годовом объёме — минуты и нагрузка на базу.

Список без постраничной выдачи. Работает, пока позиций двести. На двадцати тысячах страница просто не открывается.

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

Ни одна из трёх не проявляется на демо-данных. Все три видны на реальном объёме — поэтому и планируют под реальный объём с самого начала.