?

Log in

Технологии, используемые системой - Поддержка CMS Fly.Colibry [entries|archive|friends|userinfo]
Поддержка CMS Fly.Colibry

[ website | официальный сайтFly ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Технологии, используемые системой [Mar. 11th, 2006|03:29 pm]
Поддержка CMS Fly.Colibry
ru_cms_colibry
[ter1x]
[Tags|]
[mood |amusedCOOL]

Итак...

Движок системы - Php5
БД - CSDA over MySQL
Шаблоны - XML

Неплохо получается )))
Система будет одной из самых современных и самых быстрых.

Движок пхп5 позволяет организовать ядро на нескольких функциях (__autoload, __get, __set), избежать возможных проблем с классами и просто говорить, что система одна - из первых систем на пхп5 )))

CSDA over MySQL позволяет говорить о высокой скорости работы системы с БД, ведь любой элемент можно получить одним запросом, равно как и изменить структуру БД!!!

XML позволяет сделать простой редактор шаблонов, который не будет требовать знаний технологии XML/CSS от администратора сайта на Colibry.

Структура записей в БД позволяет хранить в записи любые данные. Или, как альтернатива - хранить в одной записи сразу несколько текстов статьи для различных языков!
linkReply

Comments:
[User Picture]From: dnovikoff
2006-03-11 02:36 pm (UTC)
а на C++ слабо? ;) мне кажется, что всяких CMS на PHP уже столько, что это мало кому интересно. и плюс в виде PHP5 тут мало роляет. объектную модель они туда, конечно, пришили более-менее пристойную, но всё равно левой пяткой через ухо, т.е. обычным для PHP образом. и для MySQL тоже.
(Reply) (Thread)
From: ter1x
2006-03-11 02:40 pm (UTC)
слабо )))

по поводу количества... Млин, таки вы видели те ЦМС???
Взять тот же слаед... Брррр...

Совершенно неудобные весчи ))
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-11 02:44 pm (UTC)
Видел. к своему сожалению. и не только CMS. вообще, у меня сложилось впечатление, что нормальных разработчиков на PHP не существует, и в этом виновата как доступность технологии, так и то, что сама технология провоцирует разработчиков на костыли.

У нас вот система написана на PHP. Результат катастрофический. В итоге, в силу того, что смена платформы проблематична, пришли к тому, что набираем C/C++-программистов и заставляем их писать на PHP.
(Reply) (Parent) (Thread)
From: ter1x
2006-03-11 02:56 pm (UTC)
маньяки-извращенцы ))))
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-11 02:58 pm (UTC)
к сожалению, это просто реальность %)) смена платформы чревата очень серьёзными финансовыми затратами и отставанием на рынке, что, думаю, понятно. соответственно, приходится по мере сил и возможностей приводить в нормальное состояние то, что есть. и таким методом оно получается. если вы знаете какие-то иные методы и готовы ими поделиться - я с радостью вас послушаю :)

а вы пробовали искать PHP-программистов? я - пробовал. увы :(
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-13 06:55 pm (UTC)
Давайте конструктивно!

Какие катастрофические результаты наблюдаете? В чем это проявляется?
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-13 06:57 pm (UTC)
это проявляется в крайней неэффективности поддержки системы, например :)
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-13 07:02 pm (UTC)
;))

Это как?
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-14 05:00 am (UTC)
давайте я вам отвечу, когда просплюсь? ориентировочно - послезавтра. сейчас я просто уже сутки не спал и пока это ещё не конец...:)
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-14 08:26 am (UTC)
Да, конечно, отдыхайте :)

Мне на самом деле интересно, чем плох PHP, какие у него проблемы.
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-11 02:45 pm (UTC)
кстати, само использование PHP5 - это даже скорее минус, чем плюс, потому как мало на каких хостингах он есть. Как следствие - придётся ставить на дедик или колок, что резко снижает доступность системы для потенциальных заказчиков - там уровень цен совсем другой.
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-11 02:46 pm (UTC)
а если писать изначально под отдельный сервак - тогда сам бог велел юзать С++ и Oracle/DB2/PostgreSQL :)
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-11 02:55 pm (UTC)
также следует обратить внимание на то, что для обеспечения популярности и актуальности системы необходимо динамично её развивать. с какого-то момента у вас одного просто перестанет хватать для этого рук, если серьёзно заниматься вопросом. следовательно, вы будете вынуждены привлекать сторонних разработчиков. а вменяемых разработчиков на PHP, как я уже говорил, почти нет.
(Reply) (Parent) (Thread)
From: ter1x
2006-03-11 02:57 pm (UTC)
Смутно подозреваю, что чем дальше, тем больше будет хостеров с пхп5.

Кроме того, когда появлялся пхп4, разве не те же траблы были???
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-11 03:03 pm (UTC)
с одной стороны это так. с другой же, хостеры чаще думают о себе, нежели о клиентах, если говорить о mass-based hosting. поясню. хостеру важнее обеспечить стабильность и равномерность (в смысле нагрузки) работы виртуального хостинга, нежели новые фичи. тут возникает ряд вопросов, как то:

1) код PHP4 при исполнении на PHP5 генерит кучу deprecated warnings.
2) ПО под PHP5 пока мало. крайне мало. тот же PEAR повально заточен под PHP4 и исправлен этот недостаток будет очень нескоро - потому что код PHP5 не работает на PHP4 :)
3) вспомните, как радовался народ появлению foreign key constraints на InnoDB в MySQL. а теперь посмотрите, сколько хостингов у нас есть с поддержкой innodb на mysql 4.x? намёк понятен? :)
(Reply) (Parent) (Thread)
From: ter1x
2006-03-11 03:32 pm (UTC)
недавно (с месяц назад) спокойно перевел форум (ИПБ 2-1-3) с пхп " на пхп 5.
никаких проблем не змечено.
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-11 03:35 pm (UTC)
ну в таком случае я за вас только рад. потом, я говорил не о том, что проблемы будут, а о том, что они могут быть. :)

кста, посмотрите http://dixx.ru/resume.html. если заинтересует - стучитесь в аську (на dixx.ru валяется), можно будет вашу CMS обсудить. в ЖЖ не очень удобно :) может чего полезное подскажу :)
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-11 03:17 pm (UTC)
кстати, по части хранения объектных моделей весьма удобным является сквозной идентификатор для всех типов сущностей. в том же PostgreSQL это вообще очень удобно реализуется - через наследование таблиц. Пример:

create sequence entity_id;
create table entity (
id integer not null default nextval('entity_id'),
entity_type_id integer not null,
-- прочие вкусности типа пути по дереву, ctime/mtime/etc..
);

-- внимание, ахтунг!!
create table login(
sid varchar(32) not null,
-- ...
) inherits(entity);

а потом вот так:

insert into login(sid) values('test');

и через select * from entity; получаем в том числе и содержимое таблицы login в рамках структуры таблицы entity :)
(Reply) (Thread)
From: ter1x
2006-03-11 03:34 pm (UTC)
вкусность )))
(Reply) (Parent) (Thread)
[User Picture]From: dnovikoff
2006-03-11 03:35 pm (UTC)
и я о чём ;)
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-13 07:17 pm (UTC)
Ммм... хранить в одной записи несколько текстов... Зачем?
(Reply) (Thread)
From: ter1x
2006-03-13 08:33 pm (UTC)
На самом деле они храняться в разных записях БД, но модуль CSDA объединяет их в потоки одной записи уже после вытягивания из БД.

Представьте, что Вам надо хранить несколько переводов для одной статьи. В идеале (первые версии этого поддерживать не будут) Колибри сможет выдавать по одному и тому же запросу различные данные - в зависимости от принимаемого броузером языка. И это только самый банальный пример ))
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-13 08:50 pm (UTC)
Представляю :) Но почему бы просто не дать метку материалу - язык? "ru", "be", "cz".

Вообще, я бы хотел с вами посоветоваться. Просто узнать ваши свежие мысли на этот счёт. Если они не коммерческая тайна ;)

Кстати, под какой лицензией планируется Coliry?

Так вот.
Какие у вас мысли по поводу ЧПУ? Будет ли? Если да, то в каком виде? И как (примерно) будет осуществляться?

И второе - кэширование документов на сервере, чтобы не пересобирать каждый раз заново. Планируется? Примерно, как оно будет выглядеть?
(Reply) (Parent) (Thread)
From: ter1x
2006-03-13 10:10 pm (UTC)
«
Представляю :) Но почему бы просто не дать метку материалу - язык? "ru", "be", "cz".
»

потому что проще это сделать на потоках )))
возможно, позже у потоков записей и появятся такие метки.

«
Вообще, я бы хотел с вами посоветоваться. Просто узнать ваши свежие мысли на этот счёт. Если они не коммерческая тайна ;)
»

Нет. Это военная тайна ))))

«
Так вот.
Какие у вас мысли по поводу ЧПУ? Будет ли? Если да, то в каком виде? И как (примерно) будет осуществляться?
»

Система изначально заточена под чпу и уже его поддерживает. основные принципы:
- каждому запрошенному адресу соответствует запись в одной из таблиц БД
- каждая запись в этой таблице имеет свойство «ТИП»
- Каждый тип записей имеет свой модуль-обработчик

Соответственно, запрос /cool_data/ при условии достаточности прав автора запроса вызовет метод user_call() обработчика типа записи /cool_data/.
Запрос /cool_data/?edit при условии достаточности прав автора запроса вызовет вместо user_call() метод edit().
Также сохраняется возможность передавать GET-данные в запросе: /cool_data/?edit=blabla1&blabla2=blabla3, что не рекомендуется ))
Также, если это позволяет обработчик типа (это позволяет, в частности, дефолтный обработчик), то можно применить его функцию только к потоку записи. Для этого перед последним слешем вставляется точка и имя потока: /cool_data.cool_thread/?edit

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

На данный момент система использует два кеша:
- Кеш выдаваемых страниц (файлики в папке «cache/» с именем «md5($_SERVER['REQUEST_URI'].$_SERVER['REMOTE_ADDRESS'].$mods->auth->id», где «$mods->auth->id» - ИД текущего пользователя), хранится настраиваемое время)
- Кеш откомпилированных шаблонов (рекомпилится, если файл в кеше старше шаблона-источника или не найден)

«
Кстати, под какой лицензией планируется Coliry?
»

GNU GPL (хотя единственная чужая разработка на данный момент - модуль WYSIWYG-редактора на основе FCKeditor, от встраивания которого в базовые дистрибутивы в будущем придется отказаться - он «весит» более чем в 10 раз больше Колибри ~1,5 МБ против текущих 137КБ)
+ дополнительные услуги (установка, настройка) - платно (ненавижу тупых пользователей )
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-13 10:35 pm (UTC)
Ну вот! Как же вам теперь отвечать? :) Может быть, оставьте свой емайл, если не хотите, чтобы переписка была видна всем.

Мой vigrin@gmail.com

Спасибо за ответы... Мысли очень интересные, есть над чем подумать! В частности вызов edit () для меня вообще совершенно новое. Никогда бы не додумался.

Теперь о ЧПУ.
А какой вид будет у ЧПУ? /about/company/history? В таком духе?

Я тоже вначале думал поступить так же: lookup-таблица, в которой храняться ЧПУ-адреса, и которые вызывают обработчик.

А на какие типы сайтов заточена Colibry? Сайт с публикациями-статьями, нечто вроде блога?

Если я правильно понимаю, движок модульный и тип сайта может быть любой?

Да, а как с классификацией материалов? Иерархическая? Фасетная (ключевые слова)? Нечто совсем иное?

Судя по адресам - иерархическая. Кстати, в этом главный недостаток таких адресов: одна страница не может принадлежать нескольким разделам...

А вот с кэшем я не понимаю причин такого вашего решения :)
Зачем привязываться к IP-адресу посетителя? А если он не авторизирован на сайте?

В общем-то, я сейчас думаю только над системой кэширования и отдачи last-modified.

1. Что есть Last-Modified страницы? Дата последнего изменения содержания страницы (текста, комментариев) без учета оболочки в виде меню, шапки; или точная копия страницы (байт-в-байт)?

2. Кэширование. Изменяем одну страницу, но ведь есть зависимые страницы, которые тоже устаревают в кэше. Как правильно поступать?
Самый простой вариант: при изменении одной страницы считать весь кэш устаревшим. Но, сами понимаете :), из пушки по воробьям!

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

Не сталкивались ли вы с такими проблемами?
(Reply) (Thread)
From: ter1x
2006-03-13 11:17 pm (UTC)
«
Теперь о ЧПУ.
А какой вид будет у ЧПУ? /about/company/history? В таком духе?
»

А есть иные предложения?? ))

«
Если я правильно понимаю, движок модульный и тип сайта может быть любой?
»

Вы абсолютно правильно меня поняли.

«
Судя по адресам - иерархическая. Кстати, в этом главный недостаток таких адресов: одна страница не может принадлежать нескольким разделам...
»

Это легко исправить при помощи введения типа LNK (Ссылка на страницу)?

«
А вот с кэшем я не понимаю причин такого вашего решения :)
Зачем привязываться к IP-адресу посетителя? А если он не авторизирован на сайте?
»

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

«
Что есть Last-Modified страницы? Дата последнего изменения содержания страницы (текста, комментариев) без учета оболочки в виде меню, шапки; или точная копия страницы (байт-в-байт)?
»

Если страница берется из кеша страниц, то это - дата изменения кеша.
Иначе, имхо, это дата изменения запрошенной информации.


Что вы понимаете под «зависимыми страницами»?
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-14 08:24 am (UTC)
> А есть иные предложения?? ))

Sure! :) Если принять утверждение, что ЧПУ - это адрес, который легко запомнить, то ЧПУ могут превратиться в /forum/324, /key/24, /entry/198 ;)

Коротко и ясно. А почему? Потому что, когда я посмотрел на реальном проекте, что делают люди с адресами... Если б уже всё в одном стиле, так ведь нет: часть адреса на чистом английском, часть на транслите... Уж лучше никакого ЧПУ ! ;)

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

> Это легко исправить при помощи введения типа LNK (Ссылка на страницу)?

Трудно сказать. Смотря, что вы имеете ввиду ;). Дело в том, что один и тот же документ не может (условимся) быть под разными адресами. Значит, либо мы не можем включить документ в два раздела, либо получится так, что адрес его будет иным, вопреки действующему разделу.

Представим, мы находимся в разделе Фото (размещены фотографии), и в нём есть ссылка на раздел "Выбор фотоаппарата", размещенная в разделе "Статьи".
Фото:               /photos/
Природа:            /photos/nature
Города:             /photos/cities
Животные:           /photos/animals
Выбор фотоаппарата: /articles/choose


Да, это выход и не так уж и страшно. Но всё-равно, я бы старался этого избегать. Впрочем, тут тоже надо подумать, какой раздел первичный, а какой вторичный ;) Чтобы не случился коллапс.

> Все неавторизованные пользователи расцениваются как один пользователь с нулевыми привилегиями.

У меня также. Только наверное сама система разграничения прав доступа другая. Как я видел на вашем сайте, у пользователей есть некие... минимальные права? А они выражены в численном значении? Просто не совсем представляю как. Как в UNIXе права доступа, чтоли?

> Если страница берется из кеша страниц, то это - дата изменения кеша.
> Иначе, имхо, это дата изменения запрошенной информации.

Интересное мнение! Спасибо!

В общем, довольно правильно. Только странно будет, если у документа то дата изменения прыгает, то в будущее, то в прошлое ;) Я надеюсь поисковики к этому нормально отнесутся ;).

Просто в чем сложность-то. Я боюсь, что в случае, если мы не будем учитывать обвязку страницы (меню, шапку, подвал), и на изменившуюся страницу, но не изменившееся содержание будем отвечать браузеру: "304, парень! Ничего нового для тебя!", то пользователь просто не увидет, если у него появится "Для вас новое сообщение" либо что-то в этом духе.

А "зависимые страницы" в моём понимании - это когда изменение одной страницы ДОЛЖНО повлечь за собой изменение другой. А проблема в том, что если одну страницу мы в кэше обновляем (отмечаем устаревшей), то должны обновить и другую, которая тоже уже стала неактуальной.

Такое часто бывает. Предположим, на нашей странице написали комментарий. Тогда на странице данного раздела мы должны изменить строку "Комментариев: n". Ну, вообще много случаев.

Самый простой вариант, как я говорил - считать весь кэш устаревшим при изменении одной из страниц. Но такой вариант подходит только для сайтов, где нет комментариев и где вообще всё изменяется очень медленно ;).

В общем, буду думать. Кажется, есть решение. Осталось его додумать.

Да и вот ещё что. Я думаю: а нужно ли мне кэширование? Так уж получилось, что мой движок в любом случае открывает соединенение с Базой при старте: нужно записать статистику и аворизировать пользователя по полученной куке.

Так вот, сильно ли отразится на производительности вариант, когда мы не станем собирать страницу заново, а возьмём её из кэша, но всё-равно будем открывать коннект к Базе?

Ну это риторический вопрос ;) Всё-равно, делать нужно.
(Reply) (Parent) (Thread)
From: ter1x
2006-03-14 10:49 am (UTC)
«
ЧПУ могут превратиться в /forum/324, /key/24, /entry/198 ;)

»
Это конкретная реализация. Создать такие же адреса в Колибри будет можно.

«
Трудно сказать. Смотря, что вы имеете ввиду ;). Дело в том, что один и тот же документ не может (условимся) быть под разными адресами. Значит, либо мы не можем включить документ в два раздела, либо получится так, что адрес его будет иным, вопреки действующему разделу.

»
Вы меня не совсем точно поняли, наверное. Введение типа LNK подразумевает создание обработчика этого типа. А обработчик типа тупо выдаст редирект на указанный в записи адрес. Вот Вам и размещение одной статьи в нескольких разделах ;)

«
А "зависимые страницы" в моём понимании - это когда изменение одной страницы ДОЛЖНО повлечь за собой изменение другой. А проблема в том, что если одну страницу мы в кэше обновляем (отмечаем устаревшей), то должны обновить и другую, которая тоже уже стала неактуальной.

»

Стоп. Судя по Вашему описанию, у вас в системе нет такого понятия, как срок жизни кеша?
Кеш - он на то и кеш, чтобы за счет оперативности появления изменений на сайте увеличивать скорость работы. Безусловно, это хорошо, что вы пытаетесь реализовать такой кеш, который можно тупо раскидать по папочкам в виде хтмл и на этом сделать ЧПУ ))). Но в данной ситуации это - весьма сложная задача. Прежде всего потому, что процесс отслеживания связей у вас сожрет весь прирост скорости, полученный при помощи кеширования. Так что, ИМХО, тут Вы несколько увлеклись...
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-14 01:14 pm (UTC)
> у вас в системе нет такого понятия, как срок жизни кеша?

Нет. Кэш жив до тех пор, пока актуален. А зачем иначе? :)

> Кеш - он на то и кеш, чтобы за счет оперативности появления изменений на сайте увеличивать скорость работы.

Не совсем понял :) Я так считал, что кэш для того, чтобы каждый раз не делать одно и то же :) (не подключаться к БД, не собирать страницы заново).
И убивает кэш (делает его неактуальным) только изменение информации на сайте (новые статьи и комментарии).

Да, увлёкся.
Я ведь говорю, кэш можно просто обнулять, когда информация изменяется, но это тоже ничего хорошего не даст: у меня сайт (под который я и делаю CMS), на котором нужно реализовать форум. И если при каждом новом сообщении в форуме убивать неизменившиеся страницы, то смысла в таком кэше не будет.

А как вы видете кэш?

Да и есть ведь ещё такая штука, как SQL-кэш...
(Reply) (Parent) (Thread)
From: ter1x
2006-03-14 09:16 pm (UTC)
В моем понимании кещ - это сохраненные для последующего использования результаты исполнения шаблона. В колибри предусмотрен только кеш, в котором актуальность хранимой в нем информации определяется ее возрастом, а не измененностью.

Объясню почему. Дело в том, что для ускорения работы системы, соответствие между запросом и страницей, сохраненной в кеше производится по трем параметрам, которые в совокупности гарантируют однозначность идентифиации и в тоже время их получение не связано с ресурсоемкими задачами. Таким образом, это ип-адрес автора запроса, его ИД в системе, и сам запрос к системе.

При такой схеме кеширования отслеживать все версии закешированнной страницы предоставляется крайне затруднительным. Именно поэтому срок жизни одной записи кеша во избежание снижения его актуальности будет браться примерно в 5, максимум 10 минут (я не беру во внимание исключения типа домашних страничек).

Имхо, в итоге это будет работать быстрее, чем Ваш кеш, поскольку Колибри откроет соединение с БД только в случае неактуальности кеша страниц. Во всех остальных случаях пользователю будет выводиться соответствующий текст из кеша.

Кроме того, со встраиванием Js_HttpRequest, проблема кеширования станет менее актуальной, поскольку сама эта технология способна значительно разгрузить сервер за счет экономии на статичных элементах сайта. И тут появляются поистине безграничные возможности для кеширования. Но увы, на эту тему все мысли пока что спутанны.
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-14 11:28 pm (UTC)
Да про кэш - у меня почти то же самое!
По md5 ($REQUEST_URI) и другим параметрам сохраняется сгенерированная страница и она отдаётся. Одно только отличие: я хочу, чтобы кэш, если он ещё актуальный, не очищался. Организовать его максимальную эффективность.

И делается это не очень сложно, я скоро постараюсь изложить все мысли в ЖЖ.
И за это даже не платишь скоростью. Но другое дело: нужен ли кэш вообще?

Самый простой пример я привёл сегодня у себя в ЖЖ:
коннект к Базе увеличивает время выполнения скрипта в 5 раз!

Но... с 0.008 до 0.045 сек. Это не время на низкопосещаемых сайтах (< 100 000 посещений в день). Стоит ли в таком случае вообще городить кэширование? (это приглашение к обсуждению ;)).

Вопрос: нужен ли кэш, и если да, то в каких случаях?

На тему частичного кэширования:
http://www.artlebedev.ru/tools/technogrette/etc/fragment-caching/
http://www.artlebedev.ru/tools/technogrette/etc/cache/

Может быть, чем-то поможет. Я тоже над этим думаю, но пока мне не нравится такой подход.
(Reply) (Parent) (Thread)
From: ter1x
2006-03-15 12:22 pm (UTC)
«
И делается это не очень сложно, я скоро постараюсь изложить все мысли в ЖЖ.
И за это даже не платишь скоростью. Но другое дело: нужен ли кэш вообще?
»

Очень интересно.
Но мне кажется, что это будет неоптимально в первую очередь с точки зрения сложности алгоритма. Вот это - именно тот случай, когда стремится к совершенству стоит умеренно. Потому что можно перемудрить с алгоритмом и в результате проиграть в скорости.

«
нужен ли кэш вообще?
»

Он нужен CMS хотя бы для того, чтобы значительно расширить рынок, на который она может выйти.

Теоретически, чем больший сегмент рынка удовлетворит система, тем больше будет ее популярность. Но тут необходимо учесть также и увеличение количества конкурентов системы ;).

Поэтому наравне с многофункциональностью система должна быть гибкой и легко подстраиваемой под различные требования. Именно такую весчь я и пишу ;)

«
нужен ли кэш, и если да, то в каких случаях?
»

Кеш нужен исключительно тогда, когда Ваш сайт в третий раз выгоняют с хостинга за загрузку серверов )))
(ну или когда вам надоест ждать несколько минут открытия страницы)))
БОЛЬШЕ ОН НАХ НЕ НУЖЕН ;)

«
На тему частичного кэширования:
»

Читал. Глубоко поддерживаю. =Р
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-15 02:26 pm (UTC)
Интересно, какая же должна быть посещаемость сайта и/или какая должна быть неэффективная CMS, чтобы выгоняли с хостинга? ;)

Я вот поставил мерялку... На свою, даже не CMS, а так, затечку, чтобы можно было запустить проект: http://vary.ru

А теперь под него и пишу CMS, которая нам нужна. Так вот, результаты (время работы скрипта) http://vary.ru/profiler

Меня устраивает такая скорость. Правда там нет проверок на права пользователя, нет сложных запросов. Но я и не планирую.
(Reply) (Parent) (Thread)
From: ter1x
2006-03-15 06:10 pm (UTC)
Увы, посещаемость в 100 посетителей - не показатель. Вам кеш вообще не нужен (и не думаю, что понадобится) именно из-за низкой посещаемости. А вот если сервер будет обрабатывать по 5 и более запросов в короткое время (например, за секунду), возможно, на скорости это не скажется... Но хостер начнет нервничать из-за высокой нагрузки на сервер... Тогда без кеша Вам придется несладко. И тогда вам понадобится кеш. И именно тогда Вы поймете, что проверка актуальности кеша должна быть максимально простой.
~~~~~~~~~~
кстати, некоторые хостеры в договорах предупреждают о том, что считают себя в праве удалить без предупреждения грузящий их сервер скрипт.
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-15 09:27 pm (UTC)
100 сейчас и всё выше и выше...

Хорошо.
5 запросов/сек.
5*60 = 300 запросов/мин.
300*60 = 18000 запросов/час.
18000*24 = 432000 запросов/сутки.

Ни один хостер не будет держать у себя сайт с такой посещаемостью на shared-хостинге за $5/мес. :)

Сейчас я пишу CMS конкретно под этот сайт. А развивать её планирую тогда, когда это будет нужно.

Я и сейчас прекрасно понимаю какой должна быть проверка актуальности кэша :) Поймите вы, что его актуальность вычисляется не при запросах.
(Reply) (Parent) (Thread)
[User Picture]From: victorgr
2006-03-14 11:31 pm (UTC)
Да. Конечно, вероятность мала, но md5 не даёт гарантий ;) Вполне возможны и коллизии и тогда кому-то отдастся чужая страница.




(смеюсь) конечно я понимаю ничтожность такой вероятности ) :)
(Reply) (Parent) (Thread)
From: ter1x
2006-03-15 12:04 pm (UTC)
Имхо, вероятность коллизий зависит от длины кодируемой строки.
Чем она короче, тем меньше вероятность коллизий
(Reply) (Parent) (Thread)