Сохранение статического html на диск вместо динамической генерации

Часто-ли пишут и много-ли запросов?

А если потребуется сменить дизайн ?

> Чем такой способ плох?

Ты это поймёшь, когда потребуется отобразить посты какого-нибудь одного пользователя, либо за отрезок времени, либо что угодно ещё. Короче, то что ты ВНЕЗАПНО изобрёл - баян и лажа :-\

А что с транзакциями делать? Как обеспечивать целостность данных?

Ну да, с базой конечно удобнее добавлять новые фичи. Ладно, закроем вопрос :)

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

> А как же удалять камменты из гостевой? Записать туда гораздо проще, чем удалить. Да и с одновременной записью надо будет разбираться.

Да, ладно. Пожалуй стормозил :) Действительно запарно будет.

Использую этот подход во всех своих проектах :)

Все публичного доступа объекты - статический html.

Персонализация страниц делается через JavaScript.

Статический кеш сбрасывается по таймауту и/или при модификации объектов, от которых данная страница зависит.

Особенно тяжёлые страницы могут регенерировать в фоне. Т.е. пользователь всегда получает статическую страницу, даже если сейчас в фоне идёт процесс генерации новой.

Например, www.aviaport.ru работает на таком принципе :)

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

/user/12345/posts/
/user/12345/posts/2.html
/user/12345/posts/3.html

>либо за отрезок времени, либо что угодно ещё

/archive/2009/04/23/

>А что с транзакциями делать?

А они при чём? В статике ничего не хранится, она - просто кеш :)

А, понял. Нет, у меня не так, как у автора. Бэкэнд данных никак со статическим кешем не связан. (Хотя тоже может быть статическим - например, в XML)

У тебя действительно не статика а кэш.

>Да, ладно. Пожалуй стормозил :) Действительно запарно будет.

Я лет 9 назад извратился - написал гостевую в одном файле :)

Т.е. PHP-скрипт, который базу комментариев в себе держал в виде серии строковых записей, и который сам себя модифицировал при ответах/редактировании :) Когда размер файла стал к 500кБ приближаться - начало тормозить :)

> Т.е. PHP-скрипт, который базу комментариев в себе держал в виде серии строковых записей, и который сам себя модифицировал при ответах/редактировании :) Когда размер файла стал к 500кБ приближаться - начало тормозить :)

:-)

Самое простейшее кеширование в любом клоне ruby on rails так и делает. Проблемы начинаются когда сайт разрастается — приходится кешировать только некоторые части, внимательно чистить кеш при каждом обновлении. Прирост обычно есть, но в некоторых случаях кэширование только замедлит работу.

> Например, www.aviaport.ru работает на таком принципе :)

любопытно. сам изобрел, или используешь какой-то фрейморк? а для чего страница отдает заголовки X-Bors* ?

>любопытно. сам изобрел, или используешь какой-то фрейморк?

Мой фреймворк, который давно и безуспешно пытаюсь предложить кому-нибудь ещё :) Потенциальных юзеров отпугивает отсутствие нормальной документации. А так - GPL, использую на десятке проектов разного калибра, много красивых слов, типа MVC, ORM, микромодульности и т.п...

http://hg.balancer.ru - там, правда, только ядро и компоненты моего личного сайта. АвиаПортовские же классы - закрытые.

Основное, на что делал упор в разработке - гибкость интеграции с уже имеющимеся решениями и скорость разработки. Первое - потому что часто приходится встраиваться в уже многолетние проекты со своей структурой (тому же АвиаПорту - больше 10 лет, а под мой фреймворк он целиком не переехал до сих пор, процесс неторопливо уже года 4 идёт, надеемся старый код окончательно снести в этом году), второе - потому что я от природы очень ленивый и каждая лишняя строчка кода для меня неприятна :)

Сейчас меня моя лень всё больше подводит к идее заняться написанием Web-IDE :) Т.е. чтобы тупо в админке указывать привязки классов и URL, указывать основные параметры класса и описывать в визуальном редакторе с подсветкой отдельные методы.

>а для чего страница отдает заголовки X-Bors* ?

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

файловый кэш, имхо самый убогий в плане реализации ...

>файловый кэш, имхо самый убогий в плане реализации ...

Неужели ты знаешь нечто, что веб-сервера умеют отдавать быстрее статики?

> Неужели ты знаешь нечто, что веб-сервера умеют отдавать быстрее статики?

засирать диск кучей говен(html'ек) ради 5 сотых секунды на рендер страницы очень глупо.

Производительность увеличивается в разы. Вместо кластера из 5 дедиков хватает одной впски. Профит же.

>Мой фреймворк, который давно и безуспешно пытаюсь предложить кому-нибудь ещё :)

DO NOT WANT

http://carlifecom.com/Snapshot2.png

>DO NOT WANT

Ткнись в F5 :)

...

А так - это временные недовычищенные последствия недавнего http://www.linux.org.ru/view-message.jsp?msgid=3598108

Сервер-то на KOI8-R, а фреймворк - на UTF-8. Всё руки не доходят на временных заглушках перекодировку поправить.

...

Там фишка такая. Когда начинает генерироваться страница для статкеша, на время генерации кладётся заглушка с соответствующим текстом. Это чтобы если кто-то параллельно тыкается или непрерывно жмёт F5, не нагружал сервер новыми процессами генерации. Как сгенерится - заглушку перезапишет.

Вот ты на такую заглушку и попал :)

...

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

...

Ну да ладно, пойду прописывать ;)

...
function cache_static_recreate() { return true; }
...

Ну, вот, по идее, заглушки на /events/ больше никто никогда не увидит :)

Ну, вот, до кучи, раз уж взялся, и кодировку заглушки поправил :)

http://hg.balancer.ru/hgwebdir/bors-core/rev/73069877ab07

>засирать диск кучей говен(html'ек) ради 5 сотых секунды на рендер страницы очень глупо.

Угу. Пока у тебя не появится онлайн в 4000 человек :)

Напомню, что 5 сотых секунды - это всего 20 запросов в секунду.

И столько генерируются только _очень_ примитивные страницы. Которым итак сам Бог велел быть статическими :)

Когда у тебя пойдёт выборка из таблицы в пару миллионов записей, ты, в самом лучшем случае десятые доли секунды только на каждый SQL-запрос тратить будешь. В сумме - до секунды на страницу _легко и непринуждённо_.

>Производительность увеличивается в разы.

Нередко - в тысячи раз :)

Знаешь, я нажал на ссылку сверху, в меню первого уровня. Это было бы оправданием, если бы я зашел на статью из архива, но я зашел на страницу первого уровня! Я думаю правильнее заставить клиента подождать.

>Я думаю правильнее заставить клиента подождать.

Одного клиента - да. Но когда десяток одновременно топнут F5... Ты бы видел, на каком древнем железе там сервер крутится :)

...

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

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

Во время регенерации, параллельные запросы могут возвращать старую версию страницы. Когда данные считывается из кеша и кеш обнаруживает, что время жизни ключа истекло, то он не должен сразу удалять файл. Перед возвратом false он может переустановить время жизни этого ключа еще на немного вперед. За это время скрипт успеет сгенерировать новое значение и перезапишет данные в кеше обычным образом. А параллельные сессии будут возвращать старое значение, основываясь на обновленном времени жизни ключа.

Если же в кеше страницы нет вообще, то параллельные запросы должны возвращать заголовок Refresh. Это так же не сложно реализовать, чуть изменив логику отдачи данных из кеша.

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

Это если она есть. При _ре_генерации у меня так и делается. А вот при очистке кеша _без_ регенерации - файл просто исчезает, пока его не запросят снова.

>Когда данные считывается из кеша и кеш обнаруживает, что время жизни ключа истекло, то он не должен сразу удалять файл.

Это зависит от конкретной настройки.

>Если же в кеше страницы нет вообще, то параллельные запросы должны возвращать заголовок Refresh.

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

Заодно _в любом_ случае получим меньшую нагрузку на сервер. Потому что в случае отсутствия загрузки, даже при определении параллельных процессов, мы запускаем N экземпляров скриптового движка. А с заглушкой - вторичные обращений будут получать чистую статику. Что на два-три порядка быстрее.

...

А если учесть, что бывают ситуации, когда даже отдача статики - уже тяжело...

википедия из одного html файла - tiddlywiki.org

>Напомню, что 5 сотых секунды - это всего 20 запросов в секунду.

А я всегда думал что 200, но у тебя, видимо, запросы на порядок толще :-)

>>Напомню, что 5 сотых секунды - это всего 20 запросов в секунду.

>А я всегда думал что 200, но у тебя, видимо, запросы на порядок толще :-)

200 в секунду - это пять тысячных секунды на запрос. Воспользуйся кальулятором. Ну, или просто представь, что 1000 в секунду - это 1/1000 секунды на каждый :)

> KRoN73

Раз у тебя на php может донастроить и сделать fastcgi + акселератор, например http://eaccelerator.net ? Производительность действительно увеличивается ;)

ЗЫ: Сам люблю perl

> Производительность действительно увеличивается ;)

Не всегда.

>может донастроить и сделать fastcgi + акселератор

У меня итак стоит apc. Примерно пятикратный выигрышь. Без акселератора производительность PHP нельзя рассматривать хоть как-то серьёзно :)