Производительность

Коротко

• Синхронизация (повседневная запись): одна изменённая заметка пушится за десятки миллисекунд даже на хранилище в 10 000 заметок; первый полный импорт 10 000 заметок — ~14 с на одном ядре.
• Отдача (горячий путь чтения): одна небольшая нода (Hetzner cpx32, 4 vCPU) отдаёт ~4 000 реальных страниц документации в секунду со 100 % успеха и p99 ~30 ms.
• Память: ~80 МБ на 100 заметок, ~1 ГБ на 10 000.
• Кеш анонимных страниц: бюджетный сервер за €6,49/мес (Hetzner cx23, 2 vCPU) держит ~8 500 зап/с gzip-страниц 10 минут подряд: 0 ошибок, 0 % CPU steal, ≈ €0,0003 за миллион запросов.

Получить честную цифру отдачи оказалось на удивление сложно — три ловушки замера, каждая стоит примерно 2×:

1. Dev-режим пересчитывает хэш каждого ассета на каждый запрос (~2× медленнее) → мерять на DEV=false.
2. Генератор нагрузки на той же машине ворует CPU у сервера (~2× медленнее) → запускать с отдельной машины.
3. Холодный кеш / один URL льстит результату → бить по многим реальным страницам с прогретым кешем.

Наш наивный первый замер был ~4× пессимистичен. Цифры ниже — после учёта всех трёх. Дальше — детали и графики.

Насколько быстра синхронизация хранилища и до какого размера оно может вырасти, прежде чем вы это почувствуете? Мы измерили мутацию pushNotes — именно её вызывает плагин Obsidian и CLI при каждой синхронизации — на хранилищах от 10 до 10 000 заметок.

Графики ниже — живые блоки datachart, которые читают CSV с сырыми результатами прямо из этого хранилища. Та же функция доступна и вам для ваших данных.

Методика

• Каждый прогон — свежий сервер с пустой базой SQLite, ограниченный 1 или 4 ядрами CPU (taskset + GOMAXPROCS).
• Синтетические заметки ~500 байт: frontmatter, заголовки, wikilink, список, блок кода.
• Первая загрузка — все N заметок одним вызовом pushNotes (одна транзакция записи).
• 1 заметка — типичная синхронизация: одна изменённая заметка в хранилище из N заметок (медиана из 3).
• 10% хранилища — пакетная синхронизация: N/10 изменённых заметок одним вызовом (медиана из 3).
• Память — RSS процесса сервера после прогона; пик — из /proc.
• Скрипт бенчмарка: scripts/bench-pushnotes.sh в репозитории.

Важный контекст: пока сервер обрабатывает push, он держит блокировку записи базы — остальные писатели (фоновые задачи, другие push'и) ждут в очереди. Поэтому «время push» здесь — это ещё и «сколько база заблокирована».

Первая загрузка: всё хранилище одним вызовом

Рост почти линейный: ~1,2 с на 1 000 заметок на одном ядре, ~14 с на 10 000. Четыре ядра сокращают время примерно вдвое: рендеринг заметок параллелится, запись в базу — нет.

Инкрементальная синхронизация: повседневный случай

Это то, что вы чувствуете каждый день: отредактировали заметку — плагин её отправил. Даже при 10 000 заметок push одной заметки занимает ~0,4 с на одном ядре и ~0,2 с на четырёх. Рендерер кеширует неизменённые заметки, поэтому стоимость растёт с размером хранилища (переиндексация), а не с объёмом изменений: push 1 000 изменённых заметок (10% хранилища в 10 000) занимает ~2,3 с на одном ядре — далеко не 1 000 × стоимость одной заметки.

Память

Сервер держит отрендеренные заметки в памяти: ~80 МБ на сотню заметок, ~180 МБ на тысячу, ~1 ГБ на десять тысяч. Учитывайте это при выборе хостинга — VPS с 1 ГБ памяти спокойно обслуживает хранилища до нескольких тысяч заметок.

Память с векторным поиском

При включённом векторном поиске (семантическое сходство, на основе модели эмбеддингов — например, bge-m3) сервер строит in-memory индекс поверх кеша заметок. Индекс хранит один вектор на заметку: bge-m3 даёт 1024-мерные float32-векторы, то есть каждая заметка занимает 4 КБ.

На маленьких хранилищах векторный индекс незаметен (40 КБ на 10 заметок). Он становится ощутимым от 1 000 заметок: +30–45 МБ. На 10 000 заметок добавляется ~40 МБ к базовому кешу — соответствует теоретическому расчёту 1 024 измерения × 4 байта × N заметок.

Сырые цифры

Замеры 2026-06-11 на 12-ядерной dev-машине ARM64 с ограничением через taskset, SQLite в режиме WAL, один процесс сервера. Ваши абсолютные цифры будут другими; форма кривых — нет.

Почему рендер страниц такой быстрый

Цифры выше — про операции записи. Чтение страниц — другая история: p50 времени ответа 3–6 мс при любом размере хранилища, даже под 10 одновременными пользователями.

Это не случайность — это архитектурный выбор. trip2g находится между статическим генератором и традиционной CMS:

• Статический генератор (Gatsby, Hugo, Eleventy): строит HTML-файлы на диск при деплое. Чтение мгновенное — просто отдаёт файл. Но каждое изменение контента требует полной пересборки — минуты для больших сайтов, без живого редактирования.
• Традиционная CMS (WordPress, Ghost): рендерит каждую страницу на каждый запрос — ходит в базу, подтягивает связи, прогоняет шаблоны. Гибко и живо, но каждый читатель нагружает базу данных.
• trip2g: рендерит HTML при записи (во время pushNotes) и хранит результат в памяти. Чтение отдаёт уже готовый HTML прямо из хэш-таблицы — без базы данных, без шаблонизатора на горячем пути. Стоимость рендера платится один раз при изменении контента и размазывается на всех читателей.

Держать тысячи отрендеренных страниц в оперативной памяти оказалось удивительно дёшево. Синтетическая заметка в 500 байт markdown превращается в ~800 байт HTML; 10 000 заметок — это примерно 8 МБ контента. Остальное из ~1 ГБ RSS при таком масштабе — Go runtime, WAL-буферы SQLite и поисковые индексы, а не кеш страниц. VPS за $5/мес с 1 ГБ памяти без проблем обслуживает хранилища в несколько тысяч заметок, не обращаясь к диску при чтении.

Есть куда двигаться дальше — сейчас архитектура рендерит заметки по отдельности, а финальную страницу (лейаут, инъекции) собирает на каждом запросе. Пре-рендер готовых страниц снизит задержку ещё сильнее. Но даже без этого trip2g уже на порядки быстрее традиционных CMS на аналогичном железе.

На какой маленькой ноде это крутится

Мы развернули trip2g на нескольких дешёвых ВМ и нагрузили каждую с отдельной машины (чтобы генератор не крал CPU у сервера), в production-режиме (DEV=false):

*Одно ядро держит ~500 rps страницы / (~43 КБ) на 100 % с p99 < 50 мс; колено ~600–700 rps, за ~900 задержка разваливается. Замерено с генератором в том же US-East (~23 мс) — первый прогон с генератором в Германии дал обманчивые «1000 rps», но тот трансатлантический канал 86 мс просто throttлил генератор, и дроплет не получал реальную нагрузку. Цены — list-прайс провайдеров.

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

Важнее сырых цифр два вывода.

Деплой не теряет ничего. Рестарт под живым трафиком — systemctl restart, пока летели запросы — уронил ноль соединений и на 2-ядерной Hetzner-ноде, и на $4-дроплете (20 000 / 20 000 и 12 000 / 12 000 ответов 200, без отказов). Слушающий сокет переживает рестарт через systemd socket activation: in-flight запросы ждут в очереди ядра пару сотен миллисекунд вместо отказа. Один сервер, без балансировщика, без простоя — см. zerodowntime.

Объектное хранилище не нужно. С локальным бэкендом (--storage-backend=local) trip2g держит ассеты и бэкапы на диске самого сервера — ни MinIO, ни S3. На $4-дроплете забутился, заняв ~57 МБ RAM. Самой дешёвой ВМ достаточно для настоящего сайта.

Что это значит для вас

• Хранилища до ~1 000 заметок: всё мгновенно — синхронизация занимает десятки миллисекунд.
• ~10 000 заметок на маленьком сервере: повседневные синхронизации по-прежнему меньше секунды, но первая загрузка всего хранилища занимает ~14 с на одном ядре. На это время база заблокирована для других писателей — большие хранилища лучше импортировать в тихие часы.
• Ядра ускоряют рендеринг, а не блокировку: 4-ядерный сервер вдвое сокращает большие загрузки. Но блокировка держится весь push в любом случае, поэтому много одновременных писателей выигрывают меньше, чем обещают сырые цифры.

Кеш анонимных страниц: 8 500 зап/с на машине за €6,49/мес

Архитектура кеша заметок выше отрендеривает HTML заранее и держит его в памяти, но gzip и несколько DB-запросов по-прежнему выполняются на каждый запрос. Оба эти расхода теперь устранены для анонимных читателей вторым слоем — кешем анонимных страниц: готовый gzip-ированный HTML хранится по ключу (путь, хост, версия заметки, конфиг, язык). Попадание в кеш — копирование байт из памяти. Рендер и gzip не запускаются.

Эффект: страница документации в default-темплейте раньше стоила ~28 мс/запрос (94% CPU уходило на синхронный per-request поиск «похожих заметок» — cosineSimilarity по всем эмбеддингам). Jet-лендинг стоил ~0,9 мс/запрос. После прогрева кеша обе страницы отдаются с одинаковой скоростью — ~9 000 зап/с. Кеш уравнивает дешёвые и дорогие страницы.

Бенчмарк: 2026-06-29, Hetzner shared-vCPU

Атака с cx33 по сети (разные машины).

12-секундный всплеск (максимальный темп): ~9 000 зап/с, CPU сервера ~78%, steal 0%.

10-минутный прогон на максимальном темпе:

Пять миллионов запросов, десять минут, ноль ошибок.

На графике ниже видно, как растёт задержка по мере приближения к насыщению.

p50 держится ниже 1 мс вплоть до ~6 000 зап/с. Колено — около 7 000–8 000 зап/с: p50 прыгает с 1,2 мс до 146 мс. Вблизи 9 000 зап/с машина насыщается. Success-rate оставался 100% на всём диапазоне: под перегрузкой сервер деградирует по задержке, не отказывая в обслуживании.

Стоимость: 8 557 зап/с ≈ 739 млн запросов в сутки на машине за €6,49/мес — ≈ €0,0003 за миллион запросов, или около €0,29 за миллиард. Для любого реального трафика стоимость одного запроса к обслуживанию округляется до нуля.

Сравнение до/после (12-ядерная dev-машина, одна страница): страница документации в default-темплейте ускорилась с 421 до 8 504 зап/с после прогрева кеша — рост в 20 раз. CPU при попадании в кеш упал с ~95% до ~0%.