Все, думаю данный этап готов. Остальное после появления редиса

Ну, вот вроде бы все что думали на этом этапе - сделанно

Итак я поднял продовый image локально, и он ругается той же самой ошибкой, хотя во debug:container показывает ,что в адаптер приходит правильный конфиг, этот конфиг не срабатывает, когда адаптер оказывается внутри пула. Может оставить ка кбыло до введения редиса?

Влили в неё tndt-40, в целом здесь все готово как только решим проблемы с кешами на тесте и проде

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

Это все решаемо, но надо модернизировтаь евенты, куча работы, которая сейчас малоактуальна.

Да, базово в DocEvent/TaskEvent нет указания с кого на какое состояние переходит, поэтому пересчитать цифры на лету не выйдет. Например документ стал архивным, это обычный документ убрали в архив или устаревший решили не обновлять?

Но вобще у нас и так МР конский, можно отложить

Вобще говоря это проекты меняют количество раз в полгода, а задачи/докуенты по идее несколько раз в день. У нас сейчас от нескольких раз в месяц до нескольких в день. Т.е. их хорошо бы пересчитывать на лету.

В целом теперь ttl можно ставить, если не в бесконечность, но бизко к тому.

Ну вот, сделали подписчика, активность и количество комментариев он пересчитывает, а задачи, документы и проекты удаляет из статистики для пересчета

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

В целом либо мы сейчас

• делаем сабскрайбер пересчитывающй статистику,
• делаем сабскрайбер просто сбрасыающий кеш
• откладываем это до внедрения редиса, и ставим маленькие ттл.

Сделали базовое кеширование, надо определиться с его ttl. По сценариям использования чаще всего кеш может жить днями пока мы что-нибудь не поменяем и не захотим посмотреть как действие повлияло на работу. Т.е. по хорошему надо бы делать кеши с длинным ттл, но сбросом по действию (или даже пересчету при действии)

А уж CommonStat вобще объект конкретной страницы, и потому ViewModel. Как и его сборка обязаность контроллера, а не сервиса.

Думается процессоры должны хранить голые цифры. А отображение будет само решать, проценты из этого делать, прогресс. pie или что еще. Наверное и выходные бизнес-объекты надо делать более абтрактными

И так, все показометры, которые мы не очень сложно можем посчитать, и за которыми обычно лезем, мы вывели. Очеталась оптимизация всего этого. Какие значения храним, когда превращаем в проценты

Кажется, что id в объекте рассчитанной статистики не нужен. Да и в целом надо подумать над ними, ведь их мы будем сериализовать

Кстати с uptime, в итоге реализовали вариант с выводом stat /proc/1 он вроде бы работает корректно

Кстати, когда мы обдумывали систему статистики ранее, мы полагали, что каждое число будет атомарным, и расчетчки не будут знать, что кто-то из них строит диаграммы. А тепрь привязываемся к месту получения. Впрочем так есть шанс немного сократить расчеты. Если нам понадобится статистика отдельно, будем думать над разбиением пожалуй

Вариант на изучение: stat /proc/1/cmdline https://serverfault.com/questions/830643/uptime-command-gives-weird-results-in-a-docker-image?newreg=45d3277a4e644259851743c00706d54c

Так же для примера вывели uptime, и он нам из контейнера показал аптайм сервера, что нам не подходит в этой адаче, но пригодиться в demius.ru Здесь надо будет поискать uptime именно php-fpm, либо uptime контейнера

Ну что, взялись и даже примерно набросали решение, уже не с итератором тегов, а tagged locator’ом (возможно баджи надо то же на него, там же для каждого объекта только один хандлер по факту срабатывает)

да, делаем в 3.1

Заодно можно убрать лишние ссылки из подвала. http://tasks.demius.ru/ не предоставляет поддержки, поскольку не дает регистрироваться или писать незарегстрированным. Changelog не нужен так активно, и может скрываться за версией.

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

Остальное вынесем в отдельную задачу на потом, или несколько (отдельно внешний запрос за наличием обнволений, отдельно расчет каких сложных метрик, не обсчитанных здесь, отдельно какие-нибудь диаграмки)