Кабинет тормозит: 7 мест, где теряется p95

«Сайт вроде работает, а дилеры жалуются» — классика B2B-кабинета. Средний ответ API 400 мс, маркетинг спокоен, а у менеджера при обновлении остатков спиннер на 6 секунд. Смотреть нужно не среднее, а p95: порог, ниже которого укладываются 95% запросов. Именно хвост «съедает» повторные заказы и доверие к порталу.

Ниже — 7 мест, где теряется p95 в личном кабинете и B2B-портале. Это ответ на коммерческий запрос «медленно работает сайт» / «проверка производительности сайта» без абстрактного «оптимизируйте код».

Главное. Медленный кабинет почти никогда не лечится одним апгрейдом VPS. Сначала профиль: синхронная 1С, N+1, очередь без бэкоффа, тяжёлый SSR, файлы, отчёты в запросе, локи БД. Потом правки и замер. Нагрузку гоняем, когда понятно, что бьём.

Что такое p95 для владельца кабинета

Ответ сразу: p95 — это «почти все клики», а не «красивая средняя по логам». Если p50 = 200 мс, а p95 = 4 с, каждый двадцатый запрос — уже потерянное время менеджера или дилера.

В кабинете критичны не «главная» и не блог, а сценарии денег: логин, каталог с ценами, корзина/заказ, остатки, статусы отгрузок, выгрузки. Именно их и меряют при аудите производительности.

1. Синхронный вызов 1С или CRM в HTTP-запросе

Ответ сразу: пользователь ждёт не ваш Node/Go, а чужой SOAP/HTTP с таймаутом 5–30 с. Один медленный контрагент поднимает p95 всего кабинета.

• остатки и цены «в реальном времени» из 1С на каждый клик по карточке;
• создание заказа с синхронной записью в CRM до ответа «ОК»;
• нет таймаута/фолбэка — поток воркеров висит на внешних сокетах.

Лечение: кэш справочников и остатков с TTL, очередь на запись в 1С, ответ пользователю без ожидания полного обмена. Пилот одного потока обмена — быстрее, чем «переписать всю интеграцию».

2. N+1 в ORM и «тихие» десятки SQL на экран

Ответ сразу: список из 50 позиций при 1 + 50 запросах к БД даёт p95 в секундах уже на скромной нагрузке. CPU при этом может быть 30–40%.

Типичная картина: карточки заказов подтягивают контрагента, склады, статусы и вложения по одному. В среднем «всё ок», в пик утренней сверки — кабинет «тупит». Сначала EXPLAIN и eager-load / batch, потом уже Redis. Подробнее про кеш без нового железа — в статье про Redis и очереди.

3. Очередь без бэкоффа и без лимита ретраев

Ответ сразу: «вынесли в фон» не значит «ускорили». Если воркеры долбят упавшую 1С без паузы, растёт глубина очереди, пул соединений и косвенно — латентность API.

• ретраи без экспоненциальной паузы и jitter;
• нет dead-letter: яд ядовитых сообщений крутится часами;
• одна очередь на письма, отчёты и критичные заказы — шум давит важное.

Нужны приоритеты, лимиты конкурентности и алерт на глубину очереди — иначе фон становится вторым узким горлышком.

4. Тяжёлый SSR «на каждый заход»

Ответ сразу: серверный рендер большого кабинета с живыми ценами без кэша страницы/фрагментов превращает TTFB в секунды. Пользователь ещё не увидел таблицу — уже потеряли p95.

Имеет смысл: статичный каркас + клиентская подгрузка горячих блоков; CDN и кэш для публичных витрин; не гонять полный SSR каталога на каждый hit. «Медленный сайт» в Wordstat часто именно про TTFB/SSR, а не про «картинки не сжаты».

5. Файлы: PDF, сканы, выгрузки в том же запросе

Ответ сразу: генерация PDF счёта или zip-выгрузки синхронно в API — прямой путь к таймаутам и занятым воркерам. Один «тяжёлый» файл портит p95 всему пулу.

• отдать задачу в очередь, ответить «готовится», ссылка по готовности;
• хранилище и CDN для уже сгенерированных файлов;
• лимит размера и таймаут — иначе один дилер кладёт пул.

6. Отчёты «за период» внутри клика

Ответ сразу: агрегат за год по всем складам в HTTP — это отчётный сервис, не экран кабинета. Такие запросы держат локи чтения, жрут CPU БД и поднимают p95 соседним пользователям.

Вынести в фон или в read-реплику, материализовать суточные срезы, ограничить период по умолчанию. Если отчёт нужен «здесь и сейчас» — отдельный воркер и прогресс, не блокировка UI-потока.

7. Локи и длинные транзакции в БД

Ответ сразу: обновление остатков в одной большой транзакции при параллельных заказах даёт ожидание на lock — классика «иногда зависает на минуту». В логах средний SELECT быстрый, p95 — катастрофа.

• короткие транзакции, без «бизнес-логики» внутри;
• индексы под реальные фильтры кабинета (контрагент + дата + статус);
• не смешивать тяжёлый отчёт и запись заказа на одних таблицах без реплики.

Симптомы до падения — в пяти признаках скорой деградации: рост TTFB, полный пул соединений, swap, 5xx.

Как проверить производительность: порядок, а не «стресс сразу»

Ответ сразу: сначала профиль и топ узких мест, потом правки, потом нагрузка. Иначе стресс-тест покажет «упали», но не скажет, чинить 1С, SQL или SSR.

1. Зафиксировать p95 по 5–7 сценариям кабинета (не по главной).
2. Снять slow query, трейсы внешних вызовов, глубину очередей.
3. Закрыть 1–2 быстрых победы (N+1, таймаут 1С, вынос PDF).
4. Повторить замер; при необходимости — нагрузочное тестирование на целевой пик.

Ошибка №1: мерить только «среднее время ответа» и CPU. Боль сидит в хвосте и во внешних системах.

Сколько это стоит бизнесу

Минута спиннера у дилера — не «неудобство UI», а отложенный заказ и звонок менеджеру в WhatsApp в обход кабинета. На пике сезона хвост p95 умножается на рекламу и сверку остатков.

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

Нужен кабинет, портал или обмен с 1С? NineLab сдаёт личный кабинет B2B от 350 000 ₽, корпоративный портал от 200 000 ₽ и интеграцию 1С с сайтом от 200 000 ₽ — оценка 1–2 недели. Обзор: кабинеты, порталы и интеграции.

Что дальше

Снимем p95 по вашим сценариям: аудит производительности, нагрузочное тестирование, доработка кабинета или оценка Discovery.