Re: Асинхронная авторизаци я

[Deomid Ryabkov <myself@xxxxxxxxxxx>]

Vladimir Romanov wrote:
> > ничем принипиально не отличается от проверки юзера/пароля.
> > не забудьте выдать пользователю куку, чтоб в следующий раз
> > не нужно было ходить в медленный лдап.
> >     
> Это конечно! Это уже сделано. Сделал как модуль авторизации nginx.
> Сейчас почти готов прототип отдельного процесаа который шлет запросы к
> LDAP (на С)
>   
> > > нагрузка будет весьма велика. Вешать авторизацию на бакенд нельзя.  В
> > > случе чего, он сдохнет под нагрузкой.
> > >
> > >       
> > в том и смысл, что нагрузка на авторизацию будет ровно такая, какую вы
> > скажете.
> >     
> На авторизацию да. Но надо будет сначал принять решение авторизовать
> или сразу послать. А для принятия такого решения надо как минимуму
> делать селект в базе.
зачем? чего селектить будем?
если ваш лдап держит N запросов в секунду, вы настраиваете ваш авторизатор
на то чтоб он засылал в среднем не более N в секунду, с каким-нибудь 
усреднением.
если у вас их таких несколько на один лдап - зависит от того как будет 
распределяться нагрузка,
если поровну, то всем поставить N/m, если нет, то приблизительно.
и главное, чтоб авторизатор понимал, когда лдапу плохо и слал народ лесом.
то есть, например, когда лдап начинает прогибаться, наверняка растёт 
время ответа.
ну вот пусть авторизатору будет выставлен порог, а лучше интервал, или 
зависимость числа допущенных
запросов от времени ответа.
в общем, масса вариантов как не положить лдап без базы и координации 
между клиентами.
>  Что при большом количестве "неокученых"
> пользователей приведет к большой загрузке.
>
>   
> > авторизатор принимает бытрое рещение - можно ещё запрос отправить лдапу или
> > нет.
> > если можно - отправляет, проверяет, даёт куку. нельзя - даёт отлуп юзеру,
> > чтоб пришёл попозже.
> >     
> Вот принятие этого решения тоже дорогая операция и выносить в бакенд,
> например на php не хочется.
>   
как я уже описал, возможно не такая и дорогая, пара математических операций.
но всё равно её надо отдать тому, кто будет делать авторизацию, то есть 
как ни крути бэкенду.
> > >  Есть еще один момент - это
> > > кластеризация. Саму вебчасть можно спокойно кластеризовать используя
> > > репликацию DB. А вот релизовтаь ограничения по количесву обращений к
> > > LDAP в таком кластере  будет сложнее.
> > >       
> > надо сказать, что лдап тоже умеет реплицироваться. может вам не парить мозг,
> > а просто обеспечить требуемую нагрузочную способность лдапа с помощью
> > репликации?
> >     
> Этот LDAP не может :(. Со временем будет другой интерфейс.
>   
> > >  Эту часть лучше оформить в виде
> > > active/stand bay пары
> > >       
> > тут я не понял.
> >     
> т.е. два сервера. Один работает, второй проверяет рабоает ли первый.
> Как только первый останавливается за заботу принимается первый.
>   
я понял что это значит, но не понял при чём это здесь.
наличие неактивного stand by не влияет на нагрузку.

--
Deomid "rojer" Ryabkov
myself@xxxxxxxxxxx
rojer@xxxxxxxxxxxx
ICQ: 8025844

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru