Требования к оборудованию

Основано на нагрузочном тесте 2026-08-03 (см. bench_results_summary.md в корне проекта):
5074 документа, 35197 операций складского учёта за 1 год, реальный код process_*_doc/
rollback_document/отчёты через HTTP. Тест шёл на одной конкретной машине — часть выводов
измерена, часть — обоснованная экстраполяция. Это явно разделено ниже.

Тестовая машина

Intel Core i7-4810MQ (2013, мобильный, 2.8GHz), 15GB RAM, SATA SSD (Kingston SA400).
Не топовое, не новое железо. База ims_bench весит 10MB при указанном объёме данных —
даже дефолтный innodb_buffer_pool_size=128MB (никем не настроенный) вмещает её с запасом.

Сценарий 1 — всё на машине пользователя (локальный сервер)

Что реально влияет на скорость

RAM — почти не влияет на этом масштабе. 10MB на год работы → экстраполяция: 10 лет истории
≈ 100MB, 50 лет ≈ 500MB. Любая машина с 2GB+ RAM закеширует всю рабочую базу целиком после
первого обращения. RAM здесь не бутылочное горлышко, а вопрос "хватает ли системе в принципе"
(ОС + MySQL + PHP + браузер одновременно на одной машине).

Диск — вероятно главный фактор, но SSD/HDD напрямую не сравнивался (нет прав дропнуть
OS-кеш в тестовом окружении). Логическое обоснование: обработка документа делает несколько
точечных обновлений таблицы складских остатков построчно — случайная запись, не последовательная. На HDD (~10мс
seek) документ с 3 строками — уже 30+мс только на позиционирование головки, до всякого
CPU/SQL. На SSD та же операция — микросекунды. Тест стабильно держал ~6-10мс на откат без
деградации на обычном SATA SSD.

CPU — низкие требования. Мобильный i7 2013 года держит самый тяжёлый отчёт (1.2с на 35к
операций) без напряжения — PHP однопоточный на запрос, SQL-запросы — простые индексные
выборки, не вычислительно тяжёлые. Современный бюджетный CPU (Celeron/Pentium N-серии
2020+, mini-PC за $150) по производительности ядра сопоставим или быстрее этого i7.

Минимальный порог — локальная установка

Вывод: для объёма данных, сравнимого с протестированным (тысячи документов в год,
десятки тысяч операций), практически любой современный компьютер с SSD справится — включая
"старое" оборудование 2013-2015 годов, если в нём стоит SSD. Единственный жёсткий запрет —
HDD.

Сценарий 2 — внешний (хостинг/VPS) сервер

Локальный тест НЕ покрывает этот сценарий напрямую — здесь появляются факторы, которых при
работе "всё на одной машине" просто нет. Часть пунктов ниже — не измерения, а структурные
риски, которые стоит проверить отдельным нагрузочным тестом перед реальным продакшн-хостингом.

Что меняется по сравнению с локальной установкой

1. Реальная многопользовательская конкуренция. Смысл внешнего сервера — доступ нескольких
   операторов одновременно. Локальный тест был строго последовательным (один "пользователь"),
   блокировки строк таблицы складских остатков/таблицы документов при одновременном проведении документов на одни и те же
   партии не проверялись вообще. Это главный неизвестный фактор — до отдельного теста с
   параллельными запросами нельзя обещать, что 5-10 одновременных операторов будут работать
   так же быстро, как последовательный тест показал.

2. Сетевая задержка (латентность). Каждое действие в UI — HTTP-запрос (API.call).
   Отчёты в full-режиме отдают тяжёлые ответы (до ~1.5MB HTML на Stock Turnover за год) —
   на медленном/дальнем канале это заметная задержка поверх времени генерации на сервере.
   Локально это было 0, на внешнем сервере — зависит от географии клиента и провайдера.

3. Продакшн веб-сервер обязателен. Тест использовал php -S (встроенный dev-сервер PHP) —
   он однопоточный и НЕ предназначен для реальной эксплуатации, тем более интернет-доступной.
   Для внешнего сервера нужен настоящий стек (nginx/Apache + PHP-FPM с пулом воркеров) —
   иначе даже 2-3 одновременных запроса будут выстраиваться в очередь.

4. Безопасность при выходе в интернет. Локально риск ограничен одной машиной. Внешний
   сервер требует: HTTPS/TLS обязательно (сейчас токен передаётся как query-параметр в URL
   отчётов — token=..., см. reports/_auth_guard.php — это приемлемо только под TLS,
   иначе токен виден в логах прокси/истории браузера), файрвол, закрытый доступ к
   config/database.local.php/logs/ снаружи.

5. Память под конкурентность. Каждый PHP-FPM воркер и каждое соединение MySQL держат
   свою память — при N одновременных пользователях требование к RAM растёт с N, а не
   остаётся плоским, как в однопользовательском локальном тесте. Число N, при котором это
   станет заметно, не измерено.

6. Надёжность и бэкапы — ответственность смещается. На своей машине человек сам следит
   за питанием/диском. На внешнем сервере это должен обеспечивать хостинг (SLA), но
   резервное копирование БД (ims) всё равно остаётся обязанностью проекта — см. правило
   "копия IMS2 на диск обязана включать SQL-дамп БД".

Минимальный порог — внешний сервер (VPS/хостинг)

Учитывая, что сама рабочая нагрузка (по данным локального теста) очень лёгкая — ограничения
здесь определяются не объёмом данных, а конкурентным доступом и требованиями к вебсерверу:

Тест конкурентности (2026-08-03) — вопрос закрыт эмпирически

Изначально этот вопрос был открытым (см. историю ниже) — проверено отдельно, через
nginx + PHP-FPM (не php -S), пул воркеров и CPU физически ограничены до 2 ядер
(taskset -c 0,1, pm.max_children=4) — честная симуляция VPS 2 vCPU, не всей тестовой
машины (8 ядер). Нагрузка — самый тяжёлый эндпоинт из раздела "Рост времени операций"
(Stock Document Turnover, full-режим, весь год), одновременные запросы через curl_multi
(scripts/bench_concurrency.php — замена ab/wrk, которых нет в системе без sudo).

Результат: пропускная способность выходит на потолок ~3 запроса/сек уже при
конкурентности 10 (пул из 4 воркеров насыщается) — дальше рост нагрузки не даёт ошибок,
только растёт очередь ожидания (задержка до ~7с при 20 одновременных запросах к самому
тяжёлому отчёту сразу). 0% ошибок на всех уровнях — деградация плавная (очередь), не
отказ.

Это искусственный наихудший случай — все "клиенты" одновременно бьют в САМЫЙ тяжёлый
отчёт. Реальная нагрузка от 5-20 компаний почти всегда — смесь лёгких операций
(проведение документа ~10мс) и редких тяжёлых отчётов, не 20 одинаковых тяжёлых запросов
разом. Вывод: 2 vCPU / 4GB достаточно даже в этом худшем сценарии.

Оговорка: тест — симуляция через taskset на локальной машине, не настоящий VPS
(виртуализация, соседи по хосту, реальная сеть — другие факторы). Перед реальным запуском
стоит повторить тот же тест (scripts/bench_concurrency.php) уже на купленном VPS — те же
10 минут, но на целевом железе.

Масштаб — важная оговорка

IMS2 — закрытая система для одной организации (склад/бизнес), не публичный сервис.
Речь не идёт о тысячах или даже сотнях одновременных пользователей — реалистичный диапазон
для этого класса системы — единицы, максимум первые десятки одновременных операторов
(кладовщики, кассиры, бухгалтер, менеджер). Рекомендации выше (2 vCPU, 2-4GB RAM) рассчитаны
именно на этот масштаб, а не на интернет-нагрузку. Открытый вопрос о конкурентности — это
"выдержит ли систему 10-20 одновременных операторов без деградации", а не вопрос
горизонтального масштабирования под тысячи клиентов. Если реальное число одновременных
пользователей известно заранее (например, не больше 5-10), минимальные требования из
таблицы выше можно считать достаточными без дополнительного теста — риск конкуренции растёт
не резко, а по мере приближения к десяткам одновременных операций записи на одни и те же
партии склада.