Пара вопросов для CMS писателей и прочих творческих людей.
Тут назрели такие вопросы:
1a. Различаете урлы типа site.ru/url/ и site.ru/url.html
1b. Различаете урлы типа site.ru/url.html и site.ru/url.ht и т.п.
1c. Приписываете ".html" к урлу и надо ли?
2. Поддерживаете GET?
3. Как храните дерево страниц?
4. Как определяете что идет обращение к элементу таблицы (товару) а не к странице?
5a. Как кешируете страницы?
5b. А если на них есть динамические объекты?
6. Поддерживаете работу с разными типами баз данных?
7a. Какое, в среднем и без учета кеша, у Вашей CMS время генерации страницы?
7b. Какое, в среднем и с учетом кеша, у Вашей CMS время генерации страницы?
7c. Сколько, в среднем и без учета кеша, запросов к базе дынных?
7d. Сколько, в среднем и c учетом кеша, запросов к базе дынных?
8a. Генерируете формы (обратной связи, форма заказа - корзины)?
8b. Кешируете каким либо образом сгенерированную форму и как?
9. Какой у Вас алгоритм кеширования страниц?
Ну вот собственно) Если есть какие-то ноу-хау и Вам не жалко ими поделится, то просим изложить оные =)
Заранее всем ОГРОМНОЕ спасибо!
Тут назрели такие вопросы:
1a. Различаете урлы типа site.ru/url/ и site.ru/url.html
1b. Различаете урлы типа site.ru/url.html и site.ru/url.ht и т.п.
Конечно. У страницы должен быть уникальный адрес. У одной и той же страницы не может быть двух разных адресов. Иначе одна неверная ссылка зациклит поисковую систему и та если и сможет корректно проиндексировать сайт, то сделает это не так быстро.
1c. Приписываете ".html" к урлу и надо ли?
Чаще нет чем да. Вопрос религиозный и технически никак не обоснован.
2. Поддерживаете GET?
Конечно!
3. Как храните дерево страниц?
Использую две таблицы. В одной дерево объектов, в другой полные адреcа. При обращении идентификатор объекта получается из второй таблицы, а вся остальная информация по объекту из первой. Это избавляет от перебора всех родительских документов.
Если нужно скорость, то рекомендую генерировать статику на стадии редактирования объектов.
4. Как определяете что идет обращение к элементу таблицы (товару) а не к странице?
Тут как хочешь. Я бы сделал товар таких же объектом как и страница, только со своими свойствами и обработчиками.
5a. Как кешируете страницы?
5b. А если на них есть динамические объекты?
Если все пользователи получает одинаковые страницы то можно генерировать статику на стадии редактирования объектов, если нет, то каждый объект сам отвечает за свое кеширование.
6. Поддерживаете работу с разными типами баз данных?
В вебе достаточно поддержки модулей mysql и mysqli. Остальное обычно не оправдывает трудозатрат.
7a. Какое, в среднем и без учета кеша, у Вашей CMS время генерации страницы?
7b. Какое, в среднем и с учетом кеша, у Вашей CMS время генерации страницы?
7c. Сколько, в среднем и без учета кеша, запросов к базе дынных?
7d. Сколько, в среднем и c учетом кеша, запросов к базе дынных?
7a. < 0,2 сек
7b. < 0,05 сек
7c. < 15
7d. < 2
8a. Генерируете формы (обратной связи, форма заказа - корзины)?
8b. Кешируете каким либо образом сгенерированную форму и как?
Нет. Каждая форма - отдельный плагин, который сам отвечает за свое кеширование.
9. Какой у Вас алгоритм кеширования страниц?
Страницы или генерируются целиком заранее или каждый объект отвечает за свое кеширование.
Ну вот собственно) Если есть какие-то ноу-хау и Вам не жалко ими поделится, то просим изложить оные =)
Иногда кеширование невозможно, например со сложной системой прав.
1b. Различаете урлы типа site.ru/url.html и site.ru/url.ht и т.п.
Да.
Пользователь сам задает адрес узла, который будет отображаться в адресной строке и следовательно может задать там хоть pron.mpg
Только для вызова нескольких специфических модулей. А так нет - он не нужен.
В таблице в БД в виде иерархического связанного списка
На основе адреса. Некоторые типы модулей имеют свой "адрес".
По частям.
Динамические части не кешируются. Эти объекты "сами знают", что им нельзя кешироваться.
Система работает через прокладку phpADO.DB и теоритически должна работать на большом количестве СУБД без проблем (во всяком случае при разработке я это учитывал). Практически же запускал на MySQL, PostgreSQL и Sybase.
Сотые и тысячные доли секунды.
Сотые и тысячные доли секунды.
Максимум не более 13-15 запросов к СУБД на страницу (для сложных модулей вроде каталогов или хитрых фотогалерей). Много лет я свое время потратил на оптимизацию кода и запросов - поэтому разрабатывая систему я заранее хотел что-то очень быстрое и легкое.
Максимум 4 запроса к СУБД при использовании кеша.
8b. Кешируете каким либо образом сгенерированную форму и как?
Нет. Путем долгих измышлений пришел к выводу, что лично для меня и тем, кто будет пользоваться моей системой хитрое генерирование форм не нужно. Поэтому каждая функция (обратная связь, карта гугела с отмеченными офисами и т.д.) является отдельным, быстрым, легконастраиваемым из админки модулем.
Кешируется страница по частям (но это почти всегда так). Части сами решают насколько времени себя кешировать.
Ну, не знаю как ноу-хау, но есть особенность в системе. Там, к примеру, все ООП сводится к нескольким огромным синглтонам. Зачем так сделано - по нескольким причинам. Во-первых, скорость - ООП нагружает систему. Во-вторых, систему буду разрабатывать только я и оно не нужно. В-третьих, я противник подхода "ООП просто так ради самого ООП даже, если оно не нужно".
Плюс код системы заранее написан как можно более оптимально (ординарные кавычки вместо двойных, поменьше обращение к СУБД и т.п.) - отсюда высокая скорость работы даже на достаточно крупных сайтах (однажды система обслуживала сайт онлайн-газеты, который содержал более полумиллиона страниц - писуны они были еще те. Сейчас сайта уже нет, к сожалению).
Еще к особенностям можно отнести эдакую суперлайт-викиразметку. То есть система реализует некоторый набор специальных тегов, позволяющих пользователю применять те или иные штуки на страницах. Например, быстро вставить прямо в текст страницы стандартную форму обратной связи с помощью [[MODULE ID="FeedBack"]]. До графического интерфейса я это дело так и не довел (лень стало - много букф писать пришлось бы), но в целом это работает.