Можно из одного Cache1 выполнить на другом Cache2 функцию или программу и в первом Cache1 увидеть результат этой функции или полученные в ходе работы программы переменные?

Ничего не скажешь, гибкая технология.

Вообще-то возникла революционная для понедельника идея спроектировать логическое управление наполнением буферов глобалов ecp-клиентов (когда и клиенты, и сервер слабоваты по озу) при работе с csp-юзерами.

Если csp-шлюз своим load-balancing будет направлять запросы csp-юзеров хаотически на несколько ecp-клиентов, то получится что одни и те же глобалы будут закачиваться случайно с разных ecp-клиентов, повторно загружая одними данными разные буфера ecp-клиентов, и по-сути излишне нагружая дисковую систему сервера.

Следовательно нужно запросы csp-юзеров разделить на группы по ecp-клиентам прямо в коде csp-веб странички и делать запросы данных адресно с конкретного ecp-клиента, а не со случайного, эмулируя «умный» csp-шлюз.

> Данные, которые запросил один ECP-клиент будут в кеше данных ECP-сервера.

Теоретически да, но если, к примеру, размер 1 кеш – это 2Г.
У 8-ми ECP клиентов будет соответственно 16Г Кеш.
И у сервера – 2Г кеш.

Если каждому из 8-ми ECP-клиентов не хватит каких-то данных, то эти данные будут читаться с ECP сервера.
И если всем ECP клиентам будут нужны разные данные, то они просто не смогут поместиться в кеш сервера.
Более того, одни и те же данные будут все время заливаться и стираться в кешах клиентов, хотя теоретически могли там лежать спокойно, но каждый запрос нового веб-юзера, направленный «по очереди», будет приводить к «кеш-турбулентности» – постоянной смене данных в кешах, пока сервер не заклинит, хотя в значительной степени эти Кеши клиентов могли быть один раз заполнены и потом просто читаться и все.

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

Но согласен – нечего из 10 PC-ков с митинского радиорынка делать один сервер HP RX3600. :-)

Просто идея масштабируемая – когда-нибудь на этом принципе 10 HP RX3600 смогут легко заменить более какой-то грандиозный сервер, ведь кеш любого сервера не резиновый.

забыл сказать, это просто пока теоретические проектные рассуждения - ECP-конфигурацию еще не испытывал - вдруг и правда она уже некая "умная" и опасения тогда напрасны

> судя по размерам предлагаемого кэша, речь идет о террабайтных прямо-таки данных.
Или Вы считаете, что скорость серверов и организация хранения и доступа к данным уже не имеет значения?

странный вывод – увидеть в упомянутых, к примеру, 16Г кеша сразу террабайтную базу.
теоретически база может быть 150Г, но юзеров может быть много, к примеру 100 разных запросов/сек

«организация хранения данных» - конечно имеет значение – это глобалы
а «скорость сервера» - это просто организация «кешей» и все

- кеши можно оставить «как есть»
- и возникла мысль - вдруг загрузку кешей можно еще «тюнинговать»? с помощью маршрутизации – конечно совершенно не факт, что этим нужно заниматься,
но вот если этим заняться – то тогда видимо в методе новой csp-странички “OnPreHTTP" нужно проанализировать запрос и выявить тот ecp-клиент, где уже закачены или где должны быть закачены те данные, какие надо – они туда закачаются один раз и будут там лежать.

И собственно вопрос был один – ну вот «назначили» ecp-клиента для какой-то группы запросов юзеров.

А как данные то получать с него?

Вроде ответ: «Web-сервис и SOAP-клиент» // «SQL gateway»

Но немножко кажется, что это что-то тяжеловатое и медленноватое.
Полегче бы, типо такого:

Open
Use
Do [ecp-client1]^prog1 Return $LB(Ans1,Ans2 . . .Ans50)

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

тут что-то самое простое, быстрое и легкое по идее должно быть
в конце концов - все эти слова - «Web-сервис и SOAP-клиент» // «SQL gateway» - они же просто эмулируют, оболачивают, какой-то сокет, шмокет и т.п.

Всем спасибо за ответы и с наступающим Новым Годом!
Что-то заморочил своими опасениями всех, а сам больше всего заморочился, вааще в дугу.

Мне Cache очень нравится, но если пофантазировать в стиле «новогоднее-фэнтези», то в csp-страничках, по аналогии с методом “OnPreHTTP" напрашивается еще один какой-то новый метод – выбор ecp-клиента - определение контекста csp-странички по ecp-кешу-клиента.

То есть все остается как есть, только добавляется один оператор – USE ECP_клиент БанкКеша4.
Это будет не 3-х звенная архитектура: ECP-сервер - ECP-клиент – Web-сервер,
А 4-х звенная архитектура с банками кешей.
ECP-сервер – ЕCP-клиент БанкКеша - ECP-клиентCSP – Web-сервер

В этой архитектуре вместо сервера может быть просто PC, общая мощность сервиса не будет определяться мощностью сервера, а будет определяться количеством ecp-кешей-клиентов.

Вот как умеют давать советы те, кто ничего сам еще не испытывал, ничего не видел и не делал!
:-)


PS.
> А какие проблемы-то? Доступ к IP есть.
Это куда надо кликнуть в документации или примерах?

Sergei Obrastsov[quot decaml]
В этой архитектуре вместо сервера может быть просто PC, общая мощность сервиса не будет определяться мощностью сервера, а будет определяться количеством ecp-кешей-клиентов.

Здорово. Главное чтобы ECP-клиентов было побольше, да кэш у них покрупнее... А что они будут стоять в очередь на медленный PC - это уже мелочи. ;)


представляется, что в конкретной очереди ecp-клиенты будут стоять один раз после включения системы, потом csp-юзеры-неудачники (у них будет все медленно) счастливым образом наполнят банки кешей - в этом фишка и была - и работа сервиса нормализуется

Sergei ObrastsovПри большой базе кэш обновляется быстро. А о пропускной способности сети не хочется подумать? Ведь все
запросы будут гоняться по ней. Не будет ли быстрее прочитать блок с диска, чем гонять его по сети? Так ведь его еще и найти надо. :)

во-во!
и я про это, сразу просек эту шнягу

кэш обновляется конечно быстро, особенно когда конкурирующие запросы активно его обновляют, то одно считал, то другое, то одно считал, то другое.

Добавил 10 кешей – и всюду одно и тоже – у каждого в кешах то одно, то другое . . . и всюду идет гигантская работа по считыванию и заполнению кешей – возможно во многом одними и те же данными данными.

И поболее всего это загрузит именно сервер – от таких ecp-клиентов помощи серверу 0.
да и в сети работа тоже просто гигантская

но кеши уже сегодня и самозаполняющиеся, и пересекающиеся – это совсем не критично

по мне кажется очевидно критичным то, что запрос по 2006 году легко попадает в кеш-клиента, заполненный 2005-м годом,
а запрос по 2005-ому году легко попадает в кеш другого клиента, заполненый 2004 годом.

имея 3 ecp-клиента с уже готовыми заполненными скоростными кешами: 2004, 2005, 2006 - три запроса юзера могут легко вызвать ну просто ступор и на клиентах, и в сети, и на самом мощном сервере, производительность которого будет слимитирована моторчиком диска, по сути механического устройства - там где не надо было ничего делать – представляется возникнет колоссальная работа

опять же может ecp-уже давно умный, и мы просто не в курсе, тогда вопросов нет,
может этот ecp не крутит моторчик диска, а берет данные вначале из кеша любого клиента, вот это было бы наверно круто, а может нет :-)

Придумал. Это открытие.

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

И нужно сделать улучшение самого csp-веб-шлюза – добавить параметр – вызывать или нет пользовательскую функцию, к примеру, NewTripIP.
Если «нет» - все остается как есть сейчас.

Если «да», то при подключении нового юзера csp-шлюз вызывает в локальном Cache эту функцию, передавая ей запрос юзера, а в ответ получает IP ecp-клиента куда шлюзу перенаправить запрос.
Для уже подключившихся сессий NewTripIP видимо не вызывается.
И все.

Прикладные же программисты, при желании, уже могут реализовать в NewTripIP свою логику деления запросов юзеров на группы кешей.


(за одно такое открытие с очевидностью нужно давать 64-битную анлимитет версию)