> Про цискин SLB я в курсе.
Железки не подойдут по идеологическим причинам. Тем более не вижу вних смысла
если распределение требуется в пределах 1 машины.
NLB - это опять таки разные машины, и я уверен что этим решаетсяпроблема
"медленный скрипт загребает всю машину". В моем же случаескрипт быстрый, машина
быстрая, все быстрое. Только скриптов оченьмного одновременно запускается.
По поводу проблема - в 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% гарантии идентификации пользователя, но этогои не
нужно. Но зато он максимально нетребовательный к ресурсам способдостичь этой
идентификации.И если как то можно было бы решить эту проблему - это просто
сказка была бы.
Роман Голомидов
