Date: Thu, 4 Jul 2002 06:20:13 +0000 (UTC)
From: 1.0| Victor Wagner <vitus@communiware.ru>
Subject: communiware etc
Ruslan Bondarev <Ruslan.Bondarev@p37.f327.n463.z2.fidonet.org> wrote:
RB> Hello, All!
RB> В livejournal из уст одного из пользователей прозвучал вопрос: "Может ли
RB> система типа Communiware быть не такой тормозной от природы?"
RB> Вопрос не такой уж и примитивный, как кажется на первый взгляд. Да и самый
RB> топик. Предлагаю обсудить. Думаю, тут даже найдутся заинтересованные. (о;
Вопрос очень даже не примитивный. Лично я его уже четвертый год решить
не могу. Даже с помощью (в последние полгода) Артема Чуприны ;-)
Он распадается на несколько подвопросов, большинство которых относятся
не к тематике данной эхи, а к тематике какой-нибудь из соседних.
Например:
"А нужна ли для данной задачи система с такой гибкостью?" - похоже
вопрос из области RU.WEB.CONSTRUCTION или что-то в этом роде. Понятно,
что при решении конкретной задачи выбор часто делается в пользу скорости
разработки, в ущерб скорости при эксплуатации.
"Существует ли способ представления структуры произвольного
информационного ресурса, более эффективно ложащийся на реляционную базу,
чем графовая модель Communiware?" - это куда-нибудь в RU.ALGORITHMS
"Существуют ли базаданческие движки, лучше приспособленные для работы
с графами, чем sql-сервера, но выполняющие требования по части
целостности, атоммарности транзакций и отказоустойчивости, предъявляемые
нагруженным интерактивным web-сайтом" - куда-нибудь в SU.DBMS
"Каким образом увязать привычки конечного пользователя, для которого
модель объект-связь довольно естественна, с привычками разработчика,
мыслящего в категориях процедурных языков?" Вообще не знаю куда,
в RU.PSYCHOLOGY что-ли. Но известно, что если разработчик сайта может
мыслить в правильной модели, то сайт получается не тормозным.
"Каким образом эффективно кэшировать страницы web-сайта, которые
все из себя динамические и персонализованные" - куда-нибудь в
RU.WEBSERVER
Если не отвечать на все поставленные вопросы, а заниматься
только тем, что относится к тематике данной эхи - интерпретатором
шаблонов, мемоизацией в пределах выполнения одного http-запроса,
то можно повысить производительность движка как максимум процентов на
50%. В то время как переформулировка одного SQL-запроса или небольшое
шевеление онтологической модели часто дает на конкретных тормозных
страницах ускорение на 1-2 порядка.
--
http://www.communiware.ruhttp://www.ice.ru/~vitus
