Чувствуется в этом какая-то обреченность

в смысле?))

а в памяти хранить не вариант?

да любю кв базу типа bolt, level

в твоёи кейсе шардинг не планируется?

а в памяти хранить не вариант?

Зачастую лучший

да любю кв базу типа bolt, level

речь идёт скорее о вот этом конкретном issue: https://github.com/qbeon/webwire-go/issues/8 т.е. о дефолтном хранилище сессий, который включён по умолчанию. Если пользователь желает реализовать собственный session storage на основе какой-либо бд типа bolt, level, SQL, Mongo whatever то делается это через хуки: OnSessionCreated OnSessionLookup OnSessionClosed

а в памяти хранить не вариант?

память волатильна.. в этом вся проблема. Сессии пропадут после перезагрузки сервера

в смысле?))

Не в смысле разработки, а в философском)

Не в смысле разработки, а в философском)

честно говоря я не понял причём тут обречённость в филосовском смысле))

память волатильна.. в этом вся проблема. Сессии пропадут после перезагрузки сервера

после рестарта процесса, точнее

но, может, это и хорошо?

но, может, это и хорошо?

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

лучше таки хранить сессии и при желании хард ресета - просто удалить директорию..

однако меня беспокоит нагрузка на ФС.. ибо при поиске сессии придётся сканить всю директорию и искать сессию в O(n)

это никак нельзя превратить в O(1)?

при загрузке сервера просканировать все сессии и создать мап file descriptor'ов?

зачем?

зачем?

чтоб поиск сессий был O(1)

при старте сканируешь директорию, создаешь мап сессий

при появлении новой сессии пишешь ее на диск и в память

все

при старте сканируешь директорию, создаешь мап сессий

ну хотя да.. ты прав, нахера file descr.

а готовых решений нет?

а готовых решений нет?

их не может быть)

главное чтоб ФС во время исполнения не рассинхронилась с мапом в процессе.. ибо если каким-то гуем удалится файл сессии тогда сессия на серве как-бы есть, но её уже как-бы нет

да и хрен с ним

их не может быть)

их куча и маленькая тележка

у каждого фрэймворка есть миделварь с сессиями и разными сторажами для их хранения

при появлении новой сессии пишешь ее на диск и в память

а потом запускаешь два инстанса и охуеваешь

у каждого фрэймворка есть миделварь с сессиями и разными сторажами для их хранения

это решения для тех конкретных фреймворков

однако меня беспокоит нагрузка на ФС.. ибо при поиске сессии придётся сканить всю директорию и искать сессию в O(n)

в название файла не судьба положить идентификатор сессии?

это решения для тех конкретных фреймворков

фишка в том, что они все одинаковые

а потом запускаешь два инстанса и охуеваешь

если запускать два инстанса то нужно работать с БД и для этого есть хуки. Речь идёт о дефолтном хранилище сессий скажем так: "для новичков, чтоб запустил - и всё работало"

если запускать два инстанса то нужно работать с БД и для этого есть хуки. Речь идёт о дефолтном хранилище сессий скажем так: "для новичков, чтоб запустил - и всё работало"

капитан очевидность подсказывает, что файловая система это тоже база данных

в название файла не судьба положить идентификатор сессии?

это не поможет, тебе так или иначе придётся сканить и икать foreach O(n)

это не поможет, тебе так или иначе придётся сканить и икать foreach O(n)

Вут? Кого сканить?

если запускать два инстанса то нужно работать с БД и для этого есть хуки. Речь идёт о дефолтном хранилище сессий скажем так: "для новичков, чтоб запустил - и всё работало"

если для новичков, то и O(1) не надо

Наличие файла на диске?

это не поможет, тебе так или иначе придётся сканить и икать foreach O(n)

эм? обращаешься сразу по имени. нашлось - заебись. не нашлось - значит нету. а это уж дело фс как не делать фулл листининг директории при обращении к одному файлу по конкретному имени

хотя да, я туплю, if file ${sessionid}.sess exists

и несколько инстансов вполне могут прозрачно работать с этим

и несколько инстансов вполне могут прозрачно работать с этим

зачем тебе несколько инстансов на одной машине?

или ты имеешь ввиду несколько машин с шареной network FS?

и несколько инстансов вполне могут прозрачно работать с этим

На разных серверах не смогут

на одном смогут. да и на разных смогут, но так уже лучше не делать

зачем тебе несколько инстансов на одной машине?

паралелить нагрузку лол (да, я знаю что это чат про го)

паралелить нагрузку лол (да, я знаю что это чат про го)

Ты смеешься вот, а если PHP FPM запустить несколько пулов, то они быстрее работают, чем один с увеличенным количеством воркеров:) (ну или я не умею готовить, но я чем только не пробовал)

паралелить нагрузку лол (да, я знаю что это чат про го)

эмм, Go это тебе не Node.js, параллелить Go сервер процессами это абсурд. сервер использует все доступные ресурсы системы

а потом запускаешь два инстанса и охуеваешь

если ты два инстанса запустил - тебе полюбому надо подумать еще кой-о-чем. так что не в кассу

если ты два инстанса запустил - тебе полюбому надо подумать еще кой-о-чем. так что не в кассу

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

не, они хотят персистентных сессий. зачем - я не знаю

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

тут разговор не о дублировании данных, а дублировании обработчиков

тут разговор не о дублировании данных, а дублировании обработчиков

Данила предложил хранить сессии И в памяти в мапе И на диске. это дублирование

Данила предложил хранить сессии И в памяти в мапе И на диске. это дублирование

нет

не, они хотят персистентных сессий. зачем - я не знаю

getting started... на данный момент ты либо описываешь сам OnSessionCreated, OnSessionLookup и OnSessionClosed, либо они отключаются вообще.. для малых проектов, которые не требуют несколько инстанций сервера и хранения сессии в БД - нужно простенькое альтернативное решение, которое работает по умолчанию. файлы - вполне годное решение, нужно больше? пиши хуки! ?

нет

Daniel Podolsky, [19.03.18 13:50] при старте сканируешь директорию, создаешь мап сессий Daniel Podolsky, [19.03.18 13:50] при появлении новой сессии пишешь ее на диск и в память

конечно, дублирование

Daniel Podolsky, [19.03.18 13:50] при старте сканируешь директорию, создаешь мап сессий Daniel Podolsky, [19.03.18 13:50] при появлении новой сессии пишешь ее на диск и в память

а, ну тогда, конечно. не надо так делать

персистентности для in-memory не бывает без дублирования

короче подведу итоги: просто пишем файл с идентификатором сессии в указанную в конфиге директорию для сессий. В случае поиска - проверяем наличие файла. Проблема решена)

я бы ещё рекомендовал нестинг дирректорий, что бы не было несколько тысяч файлов в одной папке

несколько тысяч - это не много

персистентности для in-memory не бывает без дублирования

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

да похер же

капитан очевидность подсказывает, что файловая система это тоже база данных

кстати: https://www.quora.com/What-is-the-difference-between-a-file-system-and-a-database

ERROR: S client not available

я бы ещё рекомендовал нестинг дирректорий, что бы не было несколько тысяч файлов в одной папке

добро пожаловать в 2018-ый год

я бы ещё рекомендовал нестинг дирректорий, что бы не было несколько тысяч файлов в одной папке

1. зачем, если учитывать что большинство ФС спокойно жрут 16 лямов файлов в директории? 2. по какому принципу группировать?

> DBMS provide back up and recovery whereas data lost in file system can't be recovered.

1. зачем, если учитывать что большинство ФС спокойно жрут 16 лямов файлов в директории? 2. по какому принципу группировать?

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

https://github.com/gorilla/sessions

https://github.com/gorilla/sessions

won't solve the problem. different approach to session management

> DBMS provide back up and recovery whereas data lost in file system can't be recovered.

это конечно бред, самый основной пункт второй

won't solve the problem. different approach to session management

почему, ты можешь оттуда достать FilesystemStore

хотя его суть в том, что он сохраняет сессии в виде path/session_sessionID

это конечно бред, самый основной пункт второй

там почти всё прекрасно.

почему, ты можешь оттуда достать FilesystemStore

тянуть огромную зависимость в библиотеку ради дефолтного решения для небольших проектов - не вариант

тянуть огромную зависимость в библиотеку ради дефолтного решения для небольших проектов - не вариант

Зависимость? я предлагаю copy paste

Зависимость? я предлагаю copy paste

ещё хуже

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

чё-то у меня есть сомнения, что проседает. очень может быть, что наоборот. давненько не видел бенчмарков на эту тему

чё-то у меня есть сомнения, что проседает. очень может быть, что наоборот. давненько не видел бенчмарков на эту тему

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

чё-то у меня есть сомнения, что проседает. очень может быть, что наоборот. давненько не видел бенчмарков на эту тему

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

чё-то у меня есть сомнения, что проседает. очень может быть, что наоборот. давненько не видел бенчмарков на эту тему

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

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

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

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

а счас они где-то по-дефолту выключены? в xfs и ext4 включены. за остальные не скажу

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

Это от fs зависит. И да, на секундочку fs это уже database, и ext4 к примеру будет искать файл в каталоге совсем не перебором

я бы ещё рекомендовал нестинг дирректорий, что бы не было несколько тысяч файлов в одной папке

бесполезная фигня

спасибо, что просветили

короче подведу итоги: просто пишем файл с идентификатором сессии в указанную в конфиге директорию для сессий. В случае поиска - проверяем наличие файла. Проблема решена)

нет. не надо так делать.

нет. не надо так делать.

конкретнее плиз, причина?

конкретнее плиз, причина?

потому что медленно.

потому что медленно.

это дефолтное решение для небольших проектов и новичков. Для оптомизаций существуют хуки OnSessionCreated, OnSessionLookup и OnSessionClosed

это дефолтное решение для небольших проектов и новичков. Для оптомизаций существуют хуки OnSessionCreated, OnSessionLookup и OnSessionClosed

ну ок. вам виднее.

потому что медленно.

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

сорян, я децл водофки хлопнул и просто влом рыться в исходниках ядра, но описание механизма индексирования в fs можно загуглить по inode indexing ext4

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

осталось только сделать так, чтобы весь dentry был в памяти

и проблема как раз в этом.