Про pprof-server я не слышал. Но, если не ошибаюсь, это сервис-дискавери для pprof-серверов. Это не решает проблему анализа постфактум, которую я описывал в статье.
conprof — больше похож на profefe. Но про него я узнал только летом (через полтора года после начала работы над profefe). Я успел немного пообщаться с разработчиками на летнем GopherCon. Не знаю как сейчас, но тогда там была очень «сильная любовь» к форку TSDB из prometheus. Были сомнения, сможет ли, на практике, TSDB эффективно индексировать и отдавать pprof-файлы (db заточена под временные ряды, где значение — просто число, метрика, а не блоб в несколько мегабайт; примерно это же обсуждают в https://github.com/conprof/conprof/issues/26).
В свободное время пишу похожую штуку для Go — попробую «натаскать» от вас идей ;)
Расскажите немного про расходы на эксплуатацию: Есть ли вытеснение старых данных или только агрегация за день? Количество сервисов-пользователей / занимаемое место под хранилище и пр.
Было очень интересно прочитать, спасибо. Не уверен, что полностью понял часть про скорость работы реализованных индексов, конкретно:
> [..] То есть добавление индексов почти не потребляет ресурсы и практически не влияет на скорость применения модификаций.
При обновлении записи, лок над записью удерживается пока не обновятся ее «копии» во всех индексах? Не могли бы рассказать эту часть подробнее, почему реализованный механизм быстрее тех, что используется в «обычных SQL БД»?
Мы для кластеризации nodejs-процесов уже пару лет в нагруженном продакшне используем luster. В нем нет многих «плюшек» PM2, вроде мониторинга памяти, автоскейлинга воркеров и пр. (хотя есть API для написания собственных модулей), но есть возможность разделять процесс сервиса на группы воркеров (на разных TCP/UNIX-портах). Это позволяет, для одно проекта, поверх встроенной в nodejs балансировки в модуле cluster, использовать внешние балансировщики (например nginx или haproxy) для «размазывания» нагрузки по группам.
Про pprof-server я не слышал. Но, если не ошибаюсь, это сервис-дискавери для pprof-серверов. Это не решает проблему анализа постфактум, которую я описывал в статье.
conprof — больше похож на profefe. Но про него я узнал только летом (через полтора года после начала работы над profefe). Я успел немного пообщаться с разработчиками на летнем GopherCon. Не знаю как сейчас, но тогда там была очень «сильная любовь» к форку TSDB из prometheus. Были сомнения, сможет ли, на практике, TSDB эффективно индексировать и отдавать pprof-файлы (db заточена под временные ряды, где значение — просто число, метрика, а не блоб в несколько мегабайт; примерно это же обсуждают в https://github.com/conprof/conprof/issues/26).
Расскажите немного про расходы на эксплуатацию: Есть ли вытеснение старых данных или только агрегация за день? Количество сервисов-пользователей / занимаемое место под хранилище и пр.
> [..] То есть добавление индексов почти не потребляет ресурсы и практически не влияет на скорость применения модификаций.
При обновлении записи, лок над записью удерживается пока не обновятся ее «копии» во всех индексах? Не могли бы рассказать эту часть подробнее, почему реализованный механизм быстрее тех, что используется в «обычных SQL БД»?
mousedown, этот — поclickА даже с соблюдением graceful degradation «скорость движения корована приблизительно равна скорости самомго медленного верблюда»
Uint8Arrayможно вполне реализовать какfunction Uint8Array(n)для случая если браузер не поддерживает его нативно.