Последняя дата входа

[Lozhkinda]

А что, ограничить время жизни куки не решит проблему?

Как это настроить в Руководителе?

[Lozhkinda]

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

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

Не подскажите как вы реализовали обработчик. Как у вас работает руководитель с такой большой бд за 200 Гб?

[vaanes]

А что, ограничить время жизни куки не решит проблему?

Из разных испробованных нами вариантов с учетом что приложение работает через балансировщик и пользователь может обращаться к одному из трех хостов, вариант с активностью нам больше зашел.
На большом объеме находиться много пользователей которые утром прийдя на работу и зайдут в CRM откроют посмотрят дашборды обновят пару записей и дальше занимаются своими делами в соседних вкладках и следующий раз он туда может зайти только к обеду и все это время CRM каждую минуту опрашивает обновление и грузит систему.
А так мы поставили что если в течении пары часов активности нет, выкинуть его из системы.

[vaanes]

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

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

Не подскажите как вы реализовали обработчик. Как у вас работает руководитель с такой большой бд за 200 Гб?

По поводу обработчика то на каждое посещение items обновляете время последней активности (которое например можете создать в сущности пользователей), далее отслеживаете это время и когда у пользователя время его НЕ активного состояния будет больше чем заданное время то выкидываете его по аналогии как механизм выкидывает всех режиме обслуживания

Что касается объема то тут все прям очень индивидуально и на разных проектах зная что объем будет большой использовали разные подходы, но в целом это всегда тюнинг базы и индексов, оптимальное построение архитектуры и связей сущностей для больше производительности уже зная тонкие места такие как просчет видимости или до того момента когда поле выпадающая сущность не могло грузить порционно приходилось дописывать самим, так как у тебя 3-4 мл записей и тебе их нужно а ты из коробки не можешь так как по памяти отвалишься, в общем да такой объем вытягивает но не без труда

[nruslan2]

походу родилась новая идея для доработки

[support]

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

Ого, а что это у вас за проект такой с таким количеством пользователи? Справляется программа с такой нагрузкой?

Обратите внимание на страницу "Нагрузка на сервер", там можно закешировать отчеты, которые обновляется в верхнем меню. Это так же значительно снизит нагрузку на сервер.

[vaanes]

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

Ого, а что это у вас за проект такой с таким количеством пользователи? Справляется программа с такой нагрузкой?

Обратите внимание на страницу "Нагрузка на сервер", там можно закешировать отчеты, которые обновляется в верхнем меню. Это так же значительно снизит нагрузку на сервер.

Это исключительно внутренние порталы в компаниях у которых зачастую есть представительства по территории РФ а это разные часовые пояса и в пике больше 300-500 уникальных пользователей в онлайн не бывает, если говорить не о пиках а о среднем то прям активных пользователей которые активно работают с системой на протяжении всего рабочего дня 300-400 а еще есть 600-700 пользователей которые заходят каждый день систему по событию (когда пришло сообщение о назначенном действия) или периодически входя для выполнения разовых операций.

То что есть кэш конечно знаю, но для систем когда у тебя web работает через балансировщик это не работает так как кэш храниться в файлах а у тебя фактически 2-3 ноды и получается что в текущую секунду ты обратился к одному хосту и через 10 секунд уже к другому и там нет нет этого отчета в кэш, конечно можно пользователя "привязать" к ноде но там тоже есть свои тонкости тогда или сделать так чтобы как и загрузки хранились на выделенном хосте, но если говорить за кэш то отчеты это не самая большая проблема при большой базе и пользователях, например при выводе таблицы есть два равных запроса по времени первый нужен для основной информации второй только для подсчета количества и вот когда у тебя данных много то такое дублирование приводит к увеличению времени ожидания сразу в два раза, по этому для кэширование в таких случаях уже использую Redis ну и как говорил ранее это оптимизация базы и правильное построение схемы сущностей зная уже особенности работы под нагрузкой и большим объемом.

По этому возможность выкинуть не активного пользователя это как не большой бонус который позволяет соблюдать гигиену в работе.

Отвечая на в вопрос в целом при нормальном подходе к архитектуре приложения будет работать нормально или будут не большие ограничения по функционалу.

[vaanes]

Под ограничениями я имею ввиду отказ или доработка текущего функционала для оптимизации

Например:
1) Для построения отчетов отказ от встроенного функционала и написание своих модулей или использование сторонних BI, правда с уходом с рынка РФ многих BI, это чаще написание своих отчетов. Конечно в новых версиях больше возможности для гибкости и уже многое для чего еще пару лет назад нужен был Power BI сейчас можно сделать на платформе
2) Поле теги на больших объемах требует переработки или отказа, так как если посмотреть лог выполнения видно что если например если у тебя 100 пользователей которые сделали 20 тегов каждый получаем 2000 тегов, для открытия записи в итоге генерируется 2000 запросов и если каждый например по 0,004 сек то получим 8 секунд только из-за этого поля

[Lozhkinda]

Вы создали новое поле, которое берет время из поля дата последнего входа и если оно больше какого-то лимита допустим 3 часов, то его выкидывает из системы. Не подскажите как реализовать выход пользователя из Руководителя в данном случае?

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

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

Не подскажите как вы реализовали обработчик. Как у вас работает руководитель с такой большой бд за 200 Гб?

По поводу обработчика то на каждое посещение items обновляете время последней активности (которое например можете создать в сущности пользователей), далее отслеживаете это время и когда у пользователя время его НЕ активного состояния будет больше чем заданное время то выкидываете его по аналогии как механизм выкидывает всех режиме обслуживания

Что касается объема то тут все прям очень индивидуально и на разных проектах зная что объем будет большой использовали разные подходы, но в целом это всегда тюнинг базы и индексов, оптимальное построение архитектуры и связей сущностей для больше производительности уже зная тонкие места такие как просчет видимости или до того момента когда поле выпадающая сущность не могло грузить порционно приходилось дописывать самим, так как у тебя 3-4 мл записей и тебе их нужно а ты из коробки не можешь так как по памяти отвалишься, в общем да такой объем вытягивает но не без труда

[vaanes]

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

Вы создали новое поле, которое берет время из поля дата последнего входа и если оно больше какого-то лимита допустим 3 часов, то его выкидывает из системы. Не подскажите как реализовать выход пользователя из Руководителя в данном случае?