LINUX.ORG.RU

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


0

0

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

Я имею ввиду, есть, к примеру, скрипт на неком языке, который принимает запросы на добавление записей, он же просто перезаписывает статический исходник гостевой прямо на диске вместо того, чтобы использовать базу данных (либо хранение записей в виде отдельных файло). Соответственно сервер всегда будет отдавать статический html вместо динамической генарации.

Чем такой способ плох? Никаких ошибок, связанных с базой данных, резервное копирование простое, разве что на диск время от времени запись будет идти... зато html статический и, по идее, время отклика сайта будет относительно побыстрее.


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

sin_a ★★★★★
()

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

ef37 ★★
()

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

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

Anoxemian ★★★★★
()

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

mrhx
() автор топика

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

roy ★★★★★
()
Ответ на: комментарий от roy

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

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

mrhx
() автор топика

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

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

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

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от Anoxemian

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

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

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

/archive/2009/04/23/

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

sin_a ★★★★★
()
Ответ на: комментарий от mrhx

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

:-)

mrhx
() автор топика

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

future-of-the-lor
()
Ответ на: комментарий от KRoN73

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

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

Lucky ★★
()
Ответ на: комментарий от Lucky

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

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

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

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

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от phasma

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

phasma ★☆
()
Ответ на: комментарий от future-of-the-lor

>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/ больше никто никогда не увидит :)

KRoN73 ★★★★★
()
Ответ на: комментарий от phasma

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

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

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от future-of-the-lor

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

future-of-the-lor
()
Ответ на: комментарий от future-of-the-lor

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

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

...

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

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

Lucky ★★
()
Ответ на: комментарий от Lucky

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

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

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

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

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

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

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

...

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

KRoN73 ★★★★★
()

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

gorilych ★★
()
Ответ на: комментарий от KRoN73

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

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

sdio ★★★★★
()
Ответ на: комментарий от sdio

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

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


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

KRoN73 ★★★★★
()
Ответ на: комментарий от Mrak

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

Не всегда.

kkw
()
Ответ на: комментарий от Mrak

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

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

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.