Тэги вместо подфорумов

Давно у себя на форумах к этому веду :) Собственно, даже реализовано, но хочется просмотр форумов в статике, и при этом - с отметками о прочтении. Нужно много JavaScript'а, а с этим пока ломает :)

Было бы замечательно, да.

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

>просмотр форумов в статике это как ?

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

Это именно про страницы форумов. Страницы топиков у меня итак давно уже статические.

>тут больше не джаваскрипт, а бд хитростей

БД тут как раз не лимитирует :) (при грамотном проектировании). Фишка в том, что статику тот же Лайти отдаёт на порядок быстрее лучших реализаций скриптовых движков. А уж если конкретно с PHP сравнивать... :)

> Я планирую делать статические страницы, а отметку о прочтении топиков делать через CSS + персональные JS для зареганых и через кукисы для гостей. Понятно, что точная отметка прочтений будет только у регистрантов, а у гостей - только в пределах последней сессии (как это итак сделано сегодня на большинстве движков).

т.е. если я регистрант и регулярно чищу куки спамы и трояны, для меня каждый раз форум будет непрочитанным:) ? это напомнило мне мучения с порядочно заполненым POP3 ящиком

> БД тут как раз не лимитирует :) (при грамотном проектировании). Фишка в том, что статику тот же Лайти отдаёт на порядок быстрее лучших реализаций скриптовых движков. А уж если конкретно с PHP сравнивать... :)

ну ладно отдает, он генерить эту статику при высоком конкурентом доступе на замучится:) ? помойму тут лучше хранения в бд + кэширования ничего не придумаешь.

>т.е. если я регистрант и регулярно чищу куки спамы и трояны, для меня каждый раз форум будет непрочитанным:) ?

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

>ну ладно отдает, он генерить эту статику при высоком конкурентом доступе на замучится:)

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

>помойму тут лучше хранения в бд + кэширования ничего не придумаешь.

Вот. А лучшее кеширование - статическое :)

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

[вещества]
[ненависть!!!]
[лента.вру]
[вендекапетц]
[британские ученые]

нет, спасибо, такой форум не нужен

>Как быть с тем что просмотр одного и тогоже топика у каждого может выглядеть по-разному

Топики у меня давно уже статические: http://balancer.ru/tech/forum/2009/04/t66927--Prosmotr-PDF-v-Linux-konsoli.69...

По сравнению с бывшей динамикой народ разницы не заметил :)

...

А, например, на www.aviaport.ru - там вообще почти всё на статике :)

а не реврайт хитрый случайно ?

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

Например, персональные меню пользователя («Здравствуйте, Имярек!») делаются JS-вставками (тоже статическими) вида /js/users/personal/topic.js (при чём формирователь таких JS организован так, что JS-ность этого дела от программиста может быть скрыта, т.е. задача их MVC получить HTML-код нужного блока и всё).

Но для _зарегистрированных_ юзеров нужно, всё же, немного скриптов. Например, отметить о том, что юзер прочитал этот топик. Для этого есть один динамический вызов. Типа /js/tune.js?object=topic://33445. Но такой вызов по-любому намного легче формирования всей страницы и, повторюсь, нужен только для регистрантов. Которых всегда меньше :)

> Тут задача вообще отказаться от вызова скрипта, чем и разгрузить сервер

А не проще сервер помощней взять - это будет дешевле чем оплачивать работу девелопера, как мне кажется :-)

Не проще :)

> А не проще сервер помощней взять

Это не Ъ, -500 к красноглазию.

> Генерировать статику как бы ни в каких условиях не накладнее :) Ты всё равно формируешь страницу. Так почему бы тебе её не сохранить на диск?

А почему именно на диск? Сохранять можно и в память, все равно не критические данные, а чтение с диска может даже проиграть голой генерации. Поэтому тут однозначного "лучше" нет. Ты порой на проверках валидности кеша больше потеряешь.

> пока на форуме что-то не обновится

Ну вот я дописал пост в тему, вышел на следующую страницу в 200-страничном треде. Мне все 200 страниц перегенерить? Или использовать JS везде где только можно, вставляя через него все кроме текста? Это SSI напоминает - старую, но забытую идею. Или таки по запросу только нужное? Дык чем это тогда от кеширующего сквида отличается?

Еще момент - 2 юзера одновременно что-то отпостили - сколько раз ты будешь генерить новую страницу треда?

> Даже если на загруженном форуме обновление какой-то темы произойдёт через десяток секунд - значит этот десяток секунд народ будет читать статику

А если под DDoS, то и через 10 минут, благо хоть как-то будет работать. Или кеш сразу убиваешь?

> Вот. А лучшее кеширование - статическое :)

Когда-то давно я тоже так думал :)

А потом прозрел, что не нужно изобретать велосипеды, а надо грамотно использовать окружение сервера. Если раньше генерацию превьюшек вида thumb.php?img=298374 (или спрятанную через реврайт - сути не меняет) считал преступлением, то сейчас нормой.

И ваще, я собираюсь написать веб-сервер, который вообще не будет использовать файлов, все в памяти.

>А почему именно на диск? Сохранять можно и в память

В tmpfs? Это принципиально не отличается от «диска» я имел в виду не обязательно хард. Подразумевается просто ФС.

В memcached? Так web-сервер не умеет читать из memcached статические данные. Значит - нужен скрипт, которые это делает. Значит - падение производительности на 1-3 порядка (в зависимости от скриптовой платформы). В случае оптимизированного PHP падение будет под два порядка. М.б. и больше.

>Ты порой на проверках валидности кеша больше потеряешь

У меня нет никаких проверок валидности. Статика отдаётся без всяких проверок, на то она и статика. Хранить можно, в принципе, вечно (за сбросом или пересчётом кеша при обновлении данных следит уже фреймворк и делает это только по надобности). Но я обычно чищу, а то несколько миллионов файлов - это тяжеловато. Реально же статический кеш сейчас... (смотрит) на Авиабазе - 136 тыс. файлов, на Авиапорте - 32 тысячи файлов. Во втором случае цикл очистки устаревших данных длится доли секунды, в первом - 1-2 секунды.

>Ну вот я дописал пост в тему, вышел на следующую страницу в 200-страничном треде. Мне все 200 страниц перегенерить?

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

>Дык чем это тогда от кеширующего сквида отличается?

Тем, что позволяет делать персонализацию и активно очищаться по обновлению :)

>Еще момент - 2 юзера одновременно что-то отпостили - сколько раз ты будешь генерить новую страницу треда?

Два раза. Но не имей я статику, генерить бы пришлось эти же два раза + N раз для числа читателей :)

>Или кеш сразу убиваешь?

Зависит от настройки объекта. Есть и чистая динамика, например, когда страницы не сильно загружены а с JS заморачиваться влом. Есть такие, у которых прописано хранение до года. Есть такие, у которых время хранения невелико (скажем, минут 10), но по истечению срока хранения они не трутся, а пересоздаются. А то были прецеденты... Сидит 50 человек и непрерывно жмут F5. Кеш убивается и... Запускается 50 процессов по генерации тяжёлой страницы :) Которая генерится, скажем, секунд 5... Сейчас страница статическая есть всегда, перезаписывается только когда система сама обновит её.

>А потом прозрел, что не нужно изобретать велосипеды, а надо грамотно использовать окружение сервера. Если раньше генерацию превьюшек вида thumb.php?img=298374 (или спрятанную через реврайт - сути не меняет) считал преступлением, то сейчас нормой.

Статическая превьюшка грузит сервер на порядкИ меньше динамической :)

Сильви как всегда супер%)

>А потом прозрел, что не нужно изобретать велосипеды
[...]
>И ваще, я собираюсь написать веб-сервер

Как-то мало сочетается ;)

> Страницы топиков у меня итак давно уже статические.

> статику тот же Лайти отдаёт

Ты научил лайти лочить файлы или забил на рейскондишены?

> В tmpfs? Это принципиально не отличается от «диска» я имел в виду не обязательно хард. Подразумевается просто ФС.

А зачем тебе ФС? Мало того, что ты трогаешь тормозную VFS (см.идеи рейзера), так еще непонятно как хранить аттрибуты кеша (время генерации, дабы убивать первыми тех, кого проще всего генерить, время валидности, условия валидности, когда статическая страница от чего-то зависит, например - переименовали форум, а сам топик не трогали, условия генерации, когда юзер выбрал русский язык и эту кешированную страницу не подсовывать тому, кто выбрал английский и т.д.)

> В memcached? Так web-сервер не умеет читать из memcached статические данные. Значит - нужен скрипт, которые это делает.

Значит, можно изобрести свой мемкешд, а может быть и целый сервер :)

http://twistedmatrix.com/trac/wiki - и это не единственный вариант. Что-то вообще в последнее время по этому пути все пошло.


> Нет. У меня сбрасываются явно только две последние страницы (предпоследняя - из-за нумерации).

А с 1-198 разве нельзя перейти на 200 сразу? Или костылем на JS правим?

>Еще момент - 2 юзера одновременно что-то отпостили - сколько раз ты будешь генерить новую страницу треда?

>А потом прозрел, что не нужно изобретать велосипеды, а надо грамотно использовать окружение сервера. Если раньше генерацию превьюшек вида thumb.php?img=298374 (или спрятанную через реврайт - сути не меняет) считал преступлением, то сейчас нормой.

Статическая превьюшка грузит сервер на порядкИ меньше динамической :)

А динамическая превьюшка с кешированием - еще меньше, ибо статическую превьюшку надо еще сгенерить, и не факт, что пользователи ее вообще увидят (актуально для ОЧЕНЬ больших объемов картинок, особенно когда дизайнер захочет изменить параметры генерации оной, вроде изменения размеров, добавления рамочек ватермарков. С твоем случае генерирование всей статики может занять и сутки, и больше, а в случае динамики с кешированием - 0, первое время конечно будет лагать, зато потом от статики не отличишь)

>>И ваще, я собираюсь написать веб-сервер

>Как-то мало сочетается ;)


А мне надоело изоретать велосипеды под http+fcgi/wsgi+perl/php/что_угодно+html+js, мне надоело подстраиваться под их ограничения. Гугль тоже забил, он теперь даже формы на простом HTML не рисует, они и сами признались: "мы все пишем на жабе, а HTML+JS само генерируется". Видимо его это давно задрало, поэтому они сейчас пилят свой Wave, который будет заменой всему этому зоопарку.


Представь:

приходит коннект на 80 порт, его читает мой сервер, парсит, разбирает, что же скрывалось под /threads/1234/837/newposts (аналог реврайта), а потом в shared memory пишет структурку:
int processID;
int iserIP;
int userID;
int userThread;
int param1;
int param2;
int param3;

И никаких скриптов. Написал структурку и все. Параллельно работает демон, который будет собирать ответы на эти запросы, что-то вроде make, только для сбора страниц, причем для начала достаточно всего 2 вещи: делать простой инклюд еще 1 make (с рекурсией) и вызывать внешний скрипт/fcgi/что-там-еще-осталось-от-прошлой-жизни. Скажем, для /threads/1234/837/newposts будет правило: "заинклюдить шапку_форума + имя_пользователя + ответы_форума + статистику_форума + подвал, результат закешировать для пользователя на 30 секунд". Если на данное правило есть валидный кеш - выдается кеш, иначе запускается сборка. Каждое правило в свою очередь имеет аналогичные параметры кеширования и исполнения. Скажеи правило "ответы_форума" запускает скрипт на лиспе/пхп/баше и, каким бы он небыл тормозным, он будет закеширован, а потом быстро будет отдаваться верхним правилом с огромной скоростью. Сформированную страницу демон размещает в памяти и пишет в shared memory указатель на нее, после чего веб-сервер отдает ее клиенту. ВСЕ. Сборка простых динамических страниц БЕЗ скриптов. Прямо как во времена SSI, только без потерь времени на чтение с диска/парсинг шаблонов. Даже если бекэнд отвалится (демон не сможет поднять базу и помрет, произойдет ошибка и он помрет и т.д.), то веб-сервер какое-то время все равно сможет отправлять результаты, а главное - запросы то в памяти сохраняются! А это значит, что написанный в форум пост не пропадет, даже если бекэнд отвалился. На всякий случай очередь запросов можно дампить на диск, если она слишком большая (т.е. у нас какие-то проблемы, или демон сдох, или под ддосом лежим)

Может немного сумбурно объяснил, но вроде понятно.

>или забил на рейскондишены?

Э... Прошу перевести на известные мне термины :)

>А зачем тебе ФС?

Потому что обычные web-серверы отдают статику только с ФС :)

>так еще непонятно как хранить аттрибуты кеша

В mysql. Вопросов отдачи контента это не касается. Но крутится отдельный низкоприоритетный поток (упомянутые ранее 1-2 секунды на проход, запускается раз в минуту), который чистит старые файлы.

>Значит, можно изобрести свой мемкешд, а может быть и целый сервер :)

Я сторонник проверенных и реально работающих решений :) Тем более, что FS всё равно кешируется уже средствами ОС :) Вот прямо сейчас на сервере 497 Мбайт в кеше :)

>А с 1-198 разве нельзя перейти на 200 сразу?

Гарантировано и в общем случае - нет. Но зачем? :) Нормальные люди открывают или первое непрочитанное сообщение, или первую, или последнюю страницу прямо со страницы форумов :) Если же начал листать от начала - то уж, не обессудь, придётся сделать несколько лишних кликов. Типа, на 1-й закешированной показано, что страниц 190. Перешёл на 190-ю, там видно, что их 196. И уже на 196-й видно все 200 ;) Очень редкий и экзотичный случай...

>А динамическая превьюшка с кешированием - еще меньше

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

>и не факт, что пользователи ее вообще увидят

Увидят. Превьюшка генерится в момент запроса пользователя. Заранее ничего не геренится.

>приходит коннект на 80 порт, его читает мой сервер

Ну, когда твоё решение будет жить и работать на практике - тогда и посмотрим ;) Пока же я предпочитаю статику...

> Потому что обычные web-серверы отдают статику только с ФС :)

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

> В mysql. Вопросов отдачи контента это не касается. Но крутится отдельный низкоприоритетный поток (упомянутые ранее 1-2 секунды на проход, запускается раз в минуту), который чистит старые файлы.

Имхо, такие вещи лучше через мемкешд делать, то база и так обычно является слабым звеном, так еще некритичную инфу в ней хранить...

> Я сторонник проверенных и реально работающих решений :) Тем более, что FS всё равно кешируется уже средствами ОС :) Вот прямо сейчас на сервере 497 Мбайт в кеше :)

Ну а чего же используешь лайти, а не более проверенный Апач? ;)

> Очень редкий и экзотичный случай...

Сегодня форум, завтра магазин, послезавтра интерактивная галерея... Получится так, что заткнув дырку в одном месте, где-то в другом месте появится новая. Непправильно все это, на случаи пологаться.

>Динамическая превьюшка _всегда_ отдаётся медленнее статической.

Зависит от сервера, особенно если перед ним стоит сквид ;)

> Увидят. Превьюшка генерится в момент запроса пользователя. Заранее ничего не геренится.

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

> Ну, когда твоё решение будет жить и работать на практике - тогда и посмотрим ;) Пока же я предпочитаю статику...

Я один ниасилю (я вообще http на xmpp заменить хочу, о написании плагина для фокса думаю), а другие прочитают твое сообщение и тоже захотят статику. Кто ж писать то будет? ;) Раньше я сам был фанатом статики, но со временем это прошло.

>А это ничего, что принципиально ничего в версероверостроении нового за 20 лет не произошло

Я не пишу веб-сервера, так что просто использую данность :)

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

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

>Ну а чего же используешь лайти, а не более проверенный Апач? ;)

Из двух проверенных решений использую более адекватное. Апача тоже есть - висит на втором IP с mpm_itk для виртхостов левого народа :) Но у него производительность на порядок с лишним хуже... (именно с mpm_itk)

>Сегодня форум, завтра магазин, послезавтра интерактивная галерея...

И то, и другое, и третье у меня делается на одном фреймворке с минимальными затратами на его расширение. И все механизмы кеширования и управления им там уже давно, раз и навсегда реализованы :)

>Зависит от сервера, особенно если перед ним стоит сквид ;)

При прочих равных статика всегда быстрее. Так и статика за сквидом всё равно будет быстрее динамики за скивдом.

>Ну тогда поздравляю, ты изобрел мой вариант, только без сквида :)

Ну, моему варианту уже около 10 лет и он настолько очевиден, что его сложно считать изобретением :)

>Я один ниасилю (я вообще http на xmpp заменить хочу, о написании плагина для фокса думаю), а другие прочитают твое сообщение и тоже захотят статику. Кто ж писать то будет? ;)

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

Как ты обновляешь отдаваемую статику?

>Как ты обновляешь отдаваемую статику?

Я раньше писал. Есть два подхода - очистка кеша системой по истечению срока хранения, либо очистка при изменении в объектах, связанных с заданным по кеш-зависимостям. Т.е., на примере форума, мы указывает, что форумный список зависит от топиков. При ответе в топик будет сброшен или пересчитан и кеш форумов.

Нет, я не много не это имею в виду.

Система формирует новую версию топика. Записывает половину новых данных
Приходит запрос на чтение топика. Что читает и отдает веб-сервер?

>Система формирует новую версию топика. Записывает половину новых данных
>Приходит запрос на чтение топика. Что читает и отдает веб-сервер?

Пока идёт генерация новой страницы, в зависимости от конкретного объекта пользователь прочитает или старую версию (если она не удалялась и обновится только готовым обновлённым вариантом), или заглушку «Извините, данный объект в процессе создания, нажмите F5». Когда-то была автоперезагрузка через 1-5 секунд, но оказалось, что тогда html-анкоры теряются :) Так что оставил эту задачу пользователю.

...

В случае топиков форумов сейчас используется заглушка. Вижу её пару раз в месяц :)

> обновится только готовым обновлённым вариантом

Дубль 2 - ты научил лайти лочить файлы? )) Как обеспечивается, что веб-сервер отдаст уже полностью записанную готовую страницу?

Перевес в толксах лечится увеличением кнопочки "Последние сообщения" со всего форума + затруднение доступа в ветки по отдельности (например только через страницу последних сообщений).

В тегах будет разнобой, форсеры будут вешать все теги сразу итд.

>Как обеспечивается, что веб-сервер отдаст уже полностью записанную готовую страницу?

Это обеспечитвается атомарной записью по file_put_contents() :)

Это не ответ, а уход от ответа )))

Реквестирую тело file_put_contents() :)))

Это PHP функция жж вроде :}

Да, естественно. Атомарная запись в файл. Не знаю, лочит оно там или не лочит файл при записи, но запись проходит за столь малое время, что ни разу ещё не наблюдал каких-либо сбоев на этот счёт :) Скорее соседский мальчишка прогуляется по Луне (c) раньше, чем такой сбой сможет произойти... Чтобы тут же исправиться через несколько минут :D

Ладно, будем посмотреть, как это сделано в PHP ))