MemSess — очередной сервер для работы с сессиями

[nskforward]

Для какого-то собственного pet-проекта, наверное, крутое решение. Я бы на своих проектах предпочёл использовать проверенные временем решения для подобных задач. Попробуйте не просто воспроизвести аналоги, а решить какую-то проблему, которую не решают, либо плохо решают другие - вот тогда будет интересно. Удачи!

[Trusow]

Насчет решения проблемы и "аналоговнет" есть одна идейка. Но уж очень она узкоспециализированная, и, думаю, в 99% случаев вообще никому не нужна. Проще будет какой-нибудь свой проект запилить со временем) Спасибо за отзыв!

[fuCtor]

Как pet project хорошо. Но вот по протоколу для клиентов рекомендовал бы выбрать что-то стандартное. Сейчас только для PHP есть клиент, другие попробовать не смогут. Взяли бы gRPC, под любой язык готовый клиент из коробки.

Так же, не заметил метрик, любых средств мониторинга.

[Trusow]

Спасибо.

Кстати изначально посматривал на Protobuf, но не пошло из-за статической сборки, когда та падала при старте. Не хватило знаний чтобы решить проблему, поэтому махнул рукой и написал простенький "парсер". Кстати, вообще насколько важно чтобы программа компилировалась статически? Может вообще зря по этому поводу парюсь.

Так же, не заметил метрик, любых средств мониторинга.

А чтобы Вы хотели видеть в мониторинге (кол-во удачных/неудачных запросов в минуту и т.п.) и каким образом получать эти данные? По запросу? Или чтобы они были в файле?

[fuCtor]

Статика хорошо, но не принципиально, зависимости всегда можно доставить, а в Docker это вообще пофиг.

В мониторинге хотя бы базовые RED метрики, чтобы видеть что и как работает. А отдавать их можно по классике, в формате prometheus на /metrics ручке.

[Trusow]

Быстрой реализации не обещаю, пока для себя делаю пометки на будущее и вникаю в новое. Как я понял, сам prometheus хранит и рендерит статику и раз, к примеру в полминуты, стучится в сервис по ссылке /metrics, где просто выдается стата с начала запуска сервиса.

[Trusow]

Добавил получение статистики в "сыром" виде.

[Borelli]

А что находится "под капотом"? Ставится mongo+memcache как зависимости))? Судя по репозиторию, там немного файлов - я почитаю, когда доберусь до компьютера.

Хранение важно для производительности системы, когда сессий миллионы, в них хранятся от десятков байтов до мегабайтов и более данных и в онлайне сотни тысяч сессий, в которых могут считать счётчики $i++. Тому же memcache нужно настраивать общий размер хранилища. И можно играться с настройками распределения объектов по их размеру по slab'ам.

Интересно сравнить MemSess с другими решениями по скорости ответа, нагрузке на сеть, нагрузке на CPU, RAM сервера сессий.

В интервью мне не хватило вопросов:

• Как поведёт себя сервер когда закончится ресурс для хранения?

• Переживут ли данные перезагрузку процесса сервера MemSess и перезагрузки ОС сервера в произвольный момент времени?

[Trusow]

Спасибо.

А что находится "под капотом"? Ставится mongo+memcache как зависимости))?

Никаких зависимостей от сторонних сервисов нет. Там несложно, если просто - map с данными, который периодически чистится, вот и все.

Интересно сравнить MemSess с другими решениями по скорости ответа, нагрузке на сеть, нагрузке на CPU, RAM сервера сессий.

Вот это было бы реально круто, но пока о таком сравнении приходится только мечтать, так как сервисом практически никто не пользуется.

Как поведёт себя сервер когда закончится ресурс для хранения?

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

Переживут ли данные перезагрузку процесса сервера MemSess и перезагрузки ОС сервера в произвольный момент времени?

Нет, не переживут. Хотя на будущее можно подумать над синком ключа сессии, вполне может пригодится.

[a-tk]

"traffic": {

"sendedBytes": 175013, // количество отправленных байт

"receivedBytes": 225050 // количество принятых байт

},

send, sent, sent...