Ускорение выдачи сайта

Главные вкладки

Аватар пользователя Dimm Dimm 27 февраля 2008 в 9:03

Решил ускорить выдачу сайта:
1. Включил сжатие html в настройках сервера модуль gzip_module.
2. Включил сжатие css и js этим модулем в .htaccess (настройка gzip_module http://www.lissyara.su/?id=1131)

<IfModule mod_gzip.c>
# включен ли модуль mod_gzip
mod_gzip_on                   Yes
# исключения - ява скрипты и таблицы стилей.
# на самом деле современные браузеры корректно понимают
# сжатые скрипты и CSS - тока Netscape4 не переваривает
# но его немного - поэтому в принципе эти две строки можно
# закомментировать, или поменять `exclude` на `include`
mod_gzip_item_include         file       \.js$
mod_gzip_item_include         file       \.css$
</IfModule>

3. Установил и включил Javascript Aggregator http://drupal.org/project/javascript_aggregator - он пакует все js в один файл и кэширует его.
4. Включил сжатие CSS.

В результате сайт залетал:
html сжатие - в 5 раз
css сжатие - в 6,5 раза
js сжатие - в 3 раза

Комментарии

Аватар пользователя yugin yugin 27 февраля 2008 в 11:41

Только что сделал такое же. Результат превзошел все ожидания. Сайт просто полетел!

Спасибо за статью! Очень полезно и актуально. Особенно, если на сайте работают много модулей.
Даже FCKeditor, который у меня разворачивается в popup окне стал гораздо быстрее открываться.

Аватар пользователя player player 27 февраля 2008 в 11:50

У меня стоит apache-2.2.8 и там gzip_module отсутствует. Из портов не ставится, хотя там написано что он уже там стоит. Sad непонятно.

Аватар пользователя yugin yugin 27 февраля 2008 в 12:11

Насколько помню, gzip не является обязательным модулем. На хостинге Ру-центра, например, его можно включать или выключать из панели управления. А раз модуль необязательный, то его вполне может и не быть.

Аватар пользователя Гость Гость (не проверено) 27 февраля 2008 в 15:32

Насчет Javascript Aggregator - я его поставил, включил. Ошибок нет. Но FireBag утверждает что js-файлы у меня грузятся по одному. Может кто-нибудь подсказать, в чем может быть дело ?

Аватар пользователя yugin yugin 27 февраля 2008 в 17:42

А вот и нестыковка - при первой включенной в модуле опции, которая как раз пакует и кэширует (забыл как она называется, и негде посмотреть сейчас) на странице создания материала пропадают ВСЕ ссылки, которые ниже текстового поля. Вернее, они перестают быть ссылками, и соответственно не разворачиваются.
Можно, конечно, отключать эту опцию, потом создавать новые материалы, и снова включать. Но это же неправильно!

При установке модуля использовал код, взятый со страницы модуля на .org, который вставляется в page.tpl.php
Надо бы еще проверить другой вариант. Тот, где уже другой код вставляется в template.php

Кто какие варианты делал? И как у кого дела обстоят с данной проблемой?
Если бы не данная проблемка, то метод отличный! Сайт реально залетал!

Аватар пользователя yugin yugin 28 февраля 2008 в 7:57

Читайте внимательно мой комментарий:
"При установке модуля использовал код, взятый со страницы модуля на .org, который вставляется в page.tpl.php
Надо бы еще проверить другой вариант. Тот, где уже другой код вставляется в template.php"

Так кто-нибудь еще столкнулся с этим или только я?

Аватар пользователя yugin yugin 29 февраля 2008 в 5:17

В общем, немного разобрался в проблеме. Но не до конца. У меня включен FCKeditor, соответственно все его js тоже сжимаются. При его отключении все работает отлично. Вот, что выдает Firebug:

Но теперь что, не пользоваться FCKeditor?

Аватар пользователя Dimm Dimm 29 февраля 2008 в 8:15

Они же независимы.
Drupal вроде как просто объединяет файлы в один.
gzip_module - сжимает при выдаче.
У меня работают вместе.
Косяков пока не обнаружил.

Аватар пользователя yugin yugin 29 февраля 2008 в 10:03

Спасибо, буду искать.
Кое-что уже посмотрел, но там только про TinyMCE. В комментариях встретились и другие модули, с которыми были проблемы. Может, конечно, ошибаюсь, но данный способ кажется не совсем надежным. Особенно, если в перспективе на сайт еще предстоит устанавливать другие модули, имеющие js.

Аватар пользователя Akzhan Akzhan 8 марта 2008 в 0:24

Если честно, то использовать JavaScript Aggregator - имеет мало смысла (в отличие от компрессии).

Достаточно проверить, что на ваши скрипты стоит директива Expires на пару недель (так делает Drupal по умолчанию через .htaccess).

Аватар пользователя B.X B.X 8 марта 2008 в 6:27

Akzhan wrote:
Если честно, то использовать JavaScript Aggregator - имеет мало смысла (в отличие от компрессии).

ну, как известно, практика всегда лучше теории... а для меня в пользу подобного решения было то, что Административные страницы стали открываться гораздо быстрее...

Аватар пользователя Akzhan Akzhan 8 марта 2008 в 16:09

Попробуйете отключить аггрегатор и не выключать компресию. И проверить настройки и включенность expires.

B.X wrote:
Akzhan wrote:
Если честно, то использовать JavaScript Aggregator - имеет мало смысла (в отличие от компрессии).

ну, как известно, практика всегда лучше теории... а для меня в пользу подобного решения было то, что Административные страницы стали открываться гораздо быстрее...


С уважением,
Акжан (http://www.masterhost.ru/ - обрашайтесь ко мне по вопросам дорогого и качественного хостинга).

Аватар пользователя player player 8 марта 2008 в 0:32

Akzhan wrote:
Если честно, то использовать JavaScript Aggregator - имеет мало смысла (в отличие от компрессии).

Достаточно проверить, что на ваши скрипты стоит директива Expires на пару недель (так делает Drupal по умолчанию через .htaccess).

Можно поподробнее?

Аватар пользователя Akzhan Akzhan 8 марта 2008 в 0:43
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On

  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600

  # Do not cache dynamically generated pages.
  ExpiresByType text/html A1
</IfModule>

Вот эта директива, которую по умолчанию прописывает инсталлятор Drupal в .htaccess, заставляет клиента кэшировать статические скрипты, таблицы стилей и изображения сроком на две недели.

Естественно, это работает, только если на вашем сервере стоит mod_expires. У нас стоит, естественно.

А касательно GZip-компрессии - включать выгодно всегда, но аккуратно. Наиболее аккуратно это делает nginx с настройками для прокси-серверов по умолчанию.

Аватар пользователя Dimm Dimm 11 марта 2008 в 20:33

А если в течении этих 2 недель я внесу изменения в css на сайте, а люди будут пользоваться закэшированными CSS, то у них сайт будет отображаться некорректно.
Или у браузера есть проверка на дату создания или размер кэшированного файла?

Аватар пользователя Dan Dan 12 марта 2008 в 14:35

Akzhan wrote:

Если честно, то использовать JavaScript Aggregator - имеет мало смысла (в отличие от компрессии).

Мало смысла и нет смысла - вещи разные, поэтому необходимы пояснения. Да, для постоянных пользователей - смысла почти нет. Но для большого количества анонимов, посещающих сайт редко или вообще по разу - есть, ибо сокращает кол-во запросов к серверу. Также зависит от кол-ва JS-файлов. Если их 2-3 - смысла нет, если 10-20 - сократит кол-во запросов на порядок и соответственно увеличится скорость загрузки.

Совет "Попробуйете отключить аггрегатор и не выключать компресию. И проверить настройки и включенность expires." - не катит, т.к. проверяющий есть постоянный пользователь и для него файлы закэшированы браузером.

Аватар пользователя likeleto likeleto 23 апреля 2008 в 18:31

Akzhan wrote:
Если честно, то использовать JavaScript Aggregator - имеет мало смысла (в отличие от компрессии).

Смысл делать один js файл есть, дело в том, что паковка и гзип лучше работают на одном но большом файле, чем на нескольких маленьких.

Аватар пользователя Dimm Dimm 22 апреля 2008 в 20:08

Нашел объяснение ускорению работы сайта и уменьшение потребляемой памяти при включении сжатия страниц gzip.
Как ни странно нашел это в тестовой установке битрикса Smile

Почему умирают сайты?

Оперативная память: медленные каналы

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

Например, время генерации страницы может составлять 0.01 секунды, а время передачи страницы клиенту даже с компрессией может занимать от 5 до 50 секунд и более.

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

Очень часто администраторы не отдают себе отчет в том, насколько данный фактор влияет на стабильность системы и эффективное использование оперативной памяти.

Давайте сделаем простой расчет. Рассмотрим две системы: А и Б.

В системе А время генерации страниц составит 0.1 секунды, а время передачи страницы клиенту в среднем будет составлять всего 5 секунд (в реальной жизни среднее значение окажется еще больше). В системе Б мы будем считать время генерации страниц равным 0.1, а время передачи страницы пользователю равным нулю.

Предположим, что на каждый сайт поступает по 100 запросов в секунду.

Система А: обработка 100 запросов в секунду потребует одновременной работы 100 самостоятельных процессов веб-сервера! "Почему?" - спросите вы. А как же иначе, если даже обработав запрос за 0.1 с., наши процессы, получается, еще не способны обрабатывать другие запросы, а будут висеть в памяти и просто дожидаться, пока пользователи в течение 5 секунд будут получать страницу. На четвертой секунде веб-сервер получит еще 100 запросов и должен будет запустить еще 100 процессов. Соответственно, на пятой секунде в памяти должно находиться 500 процессов и только с этого момента процессы первой секунды начнут высвобождаться и обрабатывать новые запросы. Таким образом, система А для нормальной работы будет запускать порядка 500 процессов, что потребует от нас в лучшем случае 10Г оперативной памяти. Обратите внимание, что даже если бы время генерации страниц было равно 0.001 секунды, это бы не увеличило производительность системы, так как процессы ожидают передачи данных пользователям на медленных каналах, а не времени генерации страниц. Т.е. производительность системы А никак не связана с производительностью PHP и продукта.

Система Б: за первую секунду на сервер поступит 100 запросов. Для обработки 100 запросов нам потребуется всего 10 процессов. Один процесс обрабатывает один запрос за 0.1 секунды. Как мы договорились для системы Б, время передачи страницы пользователю будет равно нулю. Т.е. за 1 секунду, один процесс веб-сервера способен обработать 10 запросов пользователей! К завершению первой секунды, все запросы будут обработаны всего 10 процессами и ко второй секунде все эти процессы будут свободны и готовы обрабатывать следующие запросы. Так же случится и на третьей секунде, и через час. Таким образом, система Б для нормальной работы будет запускать всего 10 процессов, что потребует от нас порядка 200М оперативной памяти. И очень важно отметить, что уменьшение времени генерации страниц до 0.01 секунды позволит реально увеличить производительность системы в 10 раз, и нам будет достаточно уже только 1 процесса для обработки всех 100 запросов в секунду. Производительность системы Б зависит только от производительности PHP и продукта и не зависит от медленных каналов.

Очень наглядный пример, который демонстрирует, насколько велико влияние медленных каналов пользователей на общую производительность веб-системы. Веб-сервер очень неэффективно расходует оперативную память на медленных каналах.

Аватар пользователя kiev1 kiev1 23 апреля 2008 в 20:54

В течение всего времени передачи страницы клиенту веб-сервер будет держать в памяти практически бездействующий процесс Apache, который будет только дожидаться завершения передачи данных

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

Аватар пользователя Valeratal Valeratal 8 мая 2008 в 0:16

у меня включен mod_deflate кстати (тот, который стандатный модуль во втором апаче)
вот что я нашел

Модуль mod_deflate заменил в Apache 2.0 модуль mod_gzip, используемый в Apache 1.3.
тут
получается, что мне не нужно включать gzip

Никто случайно не знает, как изменить права на файлы выдаваемые сервером по умолчанию?

Аватар пользователя Valeratal Valeratal 8 мая 2008 в 11:01

Кстати, у меня почемуто права на TMP-файлы Javascript Aggregator -а chmod 600 выставляется
никто случаем не знает - это от него зависит или от настроек сервера?

Аватар пользователя VladSavitsky VladSavitsky 30 мая 2008 в 0:01

Для совместной работы JS aggregator и tinyMCE нужно на странице "производительность" (admin/settings/performance) указать:

Exclude from js aggregation:

  • /sites/all/modules/imce-5.x-1.0/imce_set_tinymce.js
  • /sites/all/modules/tinymce-5.x-1.9/tinymce/jscripts/tiny_mce/tiny_mce_gzip.js

Эти файлы и так оптимизированы, поэтому можно не беспокоиться за трафик. Правда остаются лишние запросы к серверу для их получения...

Аватар пользователя kiev1 kiev1 30 мая 2008 в 23:29

получается, что мне не нужно включать gzip
не - не нужно, если nginx-а попросить - то он будет все проходящее зиповать, наверно так

Аватар пользователя Dimm Dimm 31 мая 2008 в 0:05

Помогите пожалуйста:
Возникла проблема: никак не сжимается выдача php-скриптов (ни html ни js) gzip_module
При этом сохраненные на диске файлы сжимаются.

если прописать в настройках
mod_gzip_item_include mime ^text/html$
то отключается сжатие css и js (сжатие html тоже не работает).

mime_magic_module и mime_module на всякий случай включены.

Аватар пользователя kiev1 kiev1 31 мая 2008 в 15:05

вот интересный сайт http://f-stop.com.ua/ - это магазин конечно не на друпал - но в нем все функции работают моментально - и вывод раздела с кучей позиций и работа с корзиной - попробуйте добавить несколько позиций и удалить - сайт это делает мгновенно - непонятно как им удалось.

Аватар пользователя manuscriptum manuscriptum 16 июля 2009 в 17:11

kiev1 wrote:
вот интересный сайт http://f-stop.com.ua/ - это магазин конечно не на друпал - но в нем все функции работают моментально - и вывод раздела с кучей позиций и работа с корзиной - попробуйте добавить несколько позиций и удалить - сайт это делает мгновенно - непонятно как им удалось.

Решил вернуться к данному обсуждению, я задавался таким вопросом и оказалось все очень просто - используется CMS с базой данных на плоских файлах. То есть на негигантских проектах можно использовать что-то вроде ReloadCMS (reloadcms.com) и все реально будет летать, при этом вместо mySql будут использоваться текстовые файлы. Времена отгрузки страницы в таких случаях порядка 0.03 сек (и форум тоже). На самом тормознутом бесплатном хостинге время будет порядка 0.3сек
Так что у меня как раз и обозначились легкие CMS на файлах как инструмент для маленьких но быстрых проектов, нетребовательных к хостингу. Для остальных вопросов - Друпал

кстати, сабж http://www.brain2life.com/book/1011.html

Аватар пользователя Dimm Dimm 31 мая 2008 в 22:38

С настройками gzip_module пока не получилось.

Зато сжал html средствами php.
http://www.internet-technologies.ru/articles/article_2.html

Просто добавил в template.php строку
ob_start("ob_gzhandler");
И страницы стали отдаваться в сжатом виде (примерное сжатие - в 8 раз).
Еще добавил эту же строчку в модуль AD /modules/ad/adserve.php для сжатия js.

Аватар пользователя VladSavitsky VladSavitsky 6 июня 2008 в 12:27

Dimm,
А как вы делаете сжатие в php? Что-то я не понял принципа - вы просто включили буферизацию...
Мой хостер сказал, что им "не выгодно включитаь mod_gzip" и оно "не включено ни на одном из наших серверов".
Короче, нет и не будет.
Я уже было думал по крону заставить спец. скрипт создавать архив всех .css и .js-файлов и их отдавать вместо несжатой версии...

Подскажите как вы сделали сжатие!

Аватар пользователя Dimm Dimm 6 июня 2008 в 21:07

Я же говорю:
Просто добавил в template.php строку
ob_start("ob_gzhandler");
Решение нашел здесь:
http://www.internet-technologies.ru/articles/article_2.html
Если ob_start("ob_gzhandler"); не работает, то там описан второй способ.
Но это у меня html сжимается.
А отдельные css файлы у мнея mod_gzip сжимает.
А js сжимает javascript_agregator.

Аватар пользователя Onza Onza 9 июля 2008 в 15:37

Такой вопрос: для модуля mod_deflate (который как уже говорили выше заменил mod_gzip в Apache 2.0) какие нужно указывать настройки (в .htaccess и т.д.)?
Кстати, staff предупредил, что включение mod_deflate может существенно повысить нагрузку на CPU, у кого-нибудь есть данные по этому поводу? (UPD: кое-что нашлось здесь - http://habrahabr.ru/blog/client_side_optimization/39360.html)

Аватар пользователя Onza Onza 17 июля 2008 в 3:35

Если у Вас cpanel и mod_deflate подключен, проще всего через cpanel указать необходимые mime-типы для сжатия, типа: text/plain text/html text/xml text/css и т.д. (через пробел). Или же просто отдавайте все с сервера (также глобально укажите mime-типы - см. мануал выше).

Аватар пользователя kiev1 kiev1 16 июля 2009 в 17:48

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

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

Аватар пользователя Dan Dan 16 июля 2009 в 21:03

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

Друпал тоже можно на файлы перевести.

Аватар пользователя manuscriptum manuscriptum 16 июля 2009 в 22:45

kiev1 wrote:
ну как-бы сказать... и да и нет - ведь mysql как раз и сделана для того что бы ускорить работу с этими самыми плоскими файлами, другое дело что при работе на общественном хостинге - админы не умеют, да и система не очень позволяет, распределить нагрузку между пользователями, и набирают сайтов кучу на один хост - по этому да, мускул тормозит там, но в случае своего сервера и нагруженного сайта - конечно mysql будет работать быстрее! а если нет - то это тоже объясняется очень просто - дело в том что сложно придумать многофункциональную систему с такой структурой на файлах - по этому в виду малофункциональности и получается скрость.

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


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

>> правильное кеширование

Ну давайте спросим владельцев сайта Wink Я видел десятки сайтов с такой же скоростью написанных на облегченных CMS - этот вариант легко может быть именно такой системой на флет-файлах.

А Вы пробовали тот-же ReloadCMS?, или NanoCMS? Упомянутый вами сайт может легко базироваться например на NanoCMS - под нее доступны готовые модули магазинов. Реальное положение дел можно узнать только у авторов. Но просмотрите реализации сайтов на той же Нане и вы увидите сравнимое время отклика для всех них. И все они на флет-файлах.

mySql база данных достаточно быстра, но _не_ быстрей операции чтения статичных файлов. Это факт. Она может либо читать почти с такой же скоростью для одиночных запросов, либо существенно медленней из-за механизма блокировки таблиц.
По умолчанию у вас наверное стоят таблицы myisam? А у этих достаточно быстрых таблиц насколько я знаю механизм блокировок работает так, что при записи в таблицу блокируется вся таблица. То есть 999 запросов будут ждать одного, который пишет. Это одна из причин тормозов сайта особенно при растущем числе обращений к базе (коих в Друпале офигительно много и в том числе при кешировании)
Разруливается переходом на тип таблицы innodb, тогда блокировка действует только на уровне той строки (записи) в базе, которая в данный момент изменяется. Но не все так просто - таблица innodb существенно тормознутей myisam для выборки данных. Другой выход - использование postgresql вместо mysql - у постгреса поддерживается блокировка на уровне одной записи таблицы при скорости существенно выше чем innodb но несколько ниже чем myisam. Такие компромиссы. Wink
Однозначно лучшего решени не существует. Тем более что innodb имеет ряд существенных ограничений функциональности (по-моему не поддерживается полнотекстовая индексация)

Значит теперь по поводу плоских файлов. Вообще-то это решение интересно тем, что фактически обладает преимуществом таблиц innodb блокировки условной "таблицы" на уровне "строки", поскольку каждая запись хранится в отдельном файле, отдельно может перезаписываться, читаться и сериализироваться, не затрагивая других "записей" в "таблице". (в ковычках взял потому что данные понятия понятно условные, а не фактические). Но основной недостаток - сравнительно маленький объем данных, которые такая БД может принять из-за трудностей с которыми сталкивается файловая система, обрабатывая множество маленьких файлов. Миллион записей не загрузишь)) Ну собственно этим и объясняется то, что для большого проекта на флет-файлах далеко не уедешь, но ехать будешь быстро))

А упомянутый Вами сайт слеплен как близнец тысяч таких же страничек на NanoCMS. Для ни для всех сравнимое время отклика. Несколько медленней CMS с БД собранной на XML-файлах, а флеты просто реактивные.

PS

а вот сайт http://management.web-standart.net/ действительно сделан на mysql и по времени отклика это чувствуется Smile
А вот этот сайтец http://f-stop.com.ua/ явно на флетах и никаким кешированием вы не сможете его обогнать, даже стат.страница будет соизмерима по скорости отклика

Аватар пользователя vitalka2k vitalka2k 17 июля 2009 в 14:34

По поводу f-stop.com.ua
Как один из работавших с его исходниками заявляю - используется MySQL и никакого кэширования Smile

А уж если хочется совсем большой скорости - смотрите на Redis, для простых запросов очень хорошо работает.

Аватар пользователя manuscriptum manuscriptum 18 июля 2009 в 0:28

vitalka2k wrote:
По поводу f-stop.com.ua
Как один из работавших с его исходниками заявляю - используется MySQL и никакого кэширования Smile

А уж если хочется совсем большой скорости - смотрите на Redis, для простых запросов очень хорошо работает.

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

а ничего что это такой забавный стиль всех ссылок в меню?
http://www.f-stop.com.ua/photo/digital/index.html
NanoCMS как раз и продвигает "эмуляцию статичных страниц".
Читаем здесь http://nanocms.name/assignment.htm
Чето вы мне, товарищь гоните, и особенно это странно на фоне того, что вы друпал.ру открыли для себя 9 часов назад Smile Поисковики-то реплику мою еще не проиндексировали пока Wink Или вы по приглашению?

... детство какое-то...

Насчет Redis не пробовал но быстрее движков на плоских файлах ничего не видел.
Устанавливал все добро у себя и гонял. sql база может поспорить с файлами только если ее устанавливать в какой-нибудь ramdisk. Но если файлы пишутся в рамдиск, опять они будут скорострельней.
А простые запросы у сайта? Опять же если вы его врукопашную пишите. А CMS дает вам собственную модель. Быстрый сайт вручную можно написать вон на Django.

Аватар пользователя manuscriptum manuscriptum 18 июля 2009 в 16:28

ну некоторое отдаленное отношение имеет - в друпале имеется несколько решений для создания кеша на файлах. Одно решение обсуждалось здесь.
Меня тема как раз эта интересовала, поэтому и на данный топик набрел)