ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Load Balancing н а основе вх одящих IP



> Про цискин SLB я в курсе. 
Железки не подойдут по идеологическим причинам. Тем более не вижу вних смысла 
если распределение требуется в пределах 1 машины.
NLB - это опять таки разные машины, и я уверен что этим решаетсяпроблема 
"медленный скрипт загребает всю машину". В моем же случаескрипт быстрый, машина 
быстрая, все быстрое. Только скриптов оченьмного одновременно запускается.
По поводу http://www.apsis.ch/pound/вся проблема - в session. т.е. он в каком 
то виде _их_ хранит у себя.
Проблема же состоит в том, что я пользователей сам внутри проектаидентифицирую 
с максимальной эффективностью.И для этого используются временные файлы.Если 
этот модуль будет сам еще временные файлы делать - то будет масло масляное.
Т.е. условно говоря, сейчас работает все так:пришел запрос  - каждый раз 
разному веб серверу.произошла обработка этой сессии (временный файл)в следующий 
раз я этого клиента идентифицирую, беру временный файл ипредпринимаю действия.
Конкретно сейчас в пике одновременно бывает порядка 1800 
максимальнооптимизированных апачей.При использовании nginx работа получается 
гораздо эффективнее. Ятестировал это ввиде 10% нагрузки от основного трафика, и 
испытаниепоказало что можно разгрузить машину раза в 2 - 2.5 при том жетрафике, 
следовательно трафик может вырасти раза в 2 минимум :)Сейчас для обработки 
вызывается компилированный С скрипт. Вседостаточно быстро и тормоза только при 
этих файловых операциях свременными файлами, и это не смотря на то что все они 
на RAM диске.Тормоза причем скорее даже не их читке (они по 100 байт), а в 
ихпоиске на диске силами файловой системы (базы для хранения 
ЭТОГОрассматривались, но также были отметены как не эффективные).
Логичным этапом максимизации эффективности является искоренение этих 
операций.Достичь этого можно с использованием FastCGI. Скрипт постоянно висит 
впамяти, копит информацию, раз в 10 минут respawn с удалениемустаревшей 
информации - все в шоколаде, даже если скрипт на perl.НО! Для целостности 
информации - у меня должен быть 1 только процесс,который условно говоря хранит 
в себе все эти временные файлы.Он не справляется со всей нагрузкой. Преподагаю 
что их должно бытьпорядка 15 процессов для обработки всего трафика. И вот тут 
встаетпроблема - запросы приходят каждый раз в разные скрипты - попредыдущему 
визиту информации нет в другом скрипте. Напрашиваютсявременные файлы. Но 
собственно зачем тогда от них уходили? :)
Вот тут и является выходом то что я говорил (может быть невнятно, признаюсь)
>Мне непонятна жёсткая балансировка вида> > A.B.C.D> D mod 3 == 0 -> первый 
>скрипт> D mod 3 == 1 -> второй скрипт> D mod 3 == 2 -> третий скрипт
d mod 3 == 0 первый скрипт означает, что я без использования какихлибо внешних 
кук, временных файлов и прочего, уже получаю туфункциональность которая нужна - 
этот клиент приходит всегда туда гдепро него знают. Он сам (IP) является 
носителем инфы куда его послать.При этом я легко могу увеличить это количество 
до сколько угодно процессов.d mod 20 == 19 - будет 20 процессов обрабатывающих 
и все легко масштабируется.
Этот способ не дает 100% гарантии идентификации пользователя, но этогои не 
нужно. Но зато он максимально нетребовательный к ресурсам способдостичь этой 
идентификации.И если как то можно было бы решить эту проблему - это просто 
сказка была бы.

Роман Голомидов



 




Copyright © Lexa Software, 1996-2009.