LINUX.ORG.RU

Частично динамичный контент


0

1

Долго медитировал на сайт, думал что и как сделать. Решил остановится на статике, а php будет только генерировать странички, и по сути вообще не важно тогда на чем сайт делать (хоть на /bin/sh, главное суметь выбрать данные из базы). С php скриптами никто кроме одного человека (меня) для генерации контента общаться не будет, и с базой тоже - поэтому пускай хранится в файлах или sqlite. Все. Выдержит любой хайлоад, я доволен. Можно пойти дальше и написать свой сервер, который кроме отдачи статики с HTTP/1.1 200 OK ничего не умеет, но пока не нужно..

Проблема в том, что имеется блок с информацией о пользователе, который на сайте залогинен. Он конечно же должен изменяться для каждого посетителя отдельно, вплоть до вывода текущего IP адреса пользователя. Как его реализовать внутри статичного контента?

Первая мысль ajax, но у Ъ может быть отключен javascript.
Вторая мысль - делать не всю страницу сайта статичной, а только кэшировать ее основной контент, а такое как 'header', 'footer' и блоки сайта остаются php скриптом, но это существенно понижает производительность и сводит всю затею с хайлоадом к нулю, если в итоге все-равно каждый раз запрашивается .php файл.
Третья мысль, для каждой отдельной сессии (пользователя) генерировать свою статику, и при повторном запросе уже выдавать ее, но боюсь не напасусь места на винте и вообще, кажется на грани бреда.

Что вы могли бы посоветовать лучше?

★★★★★

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

Ты хочешь сказать, что фейсбукоконтакты постоянно лежат, лол?

jessey
()

Темлейт + LRU/кэш с таймаутами. Была аналогичная затея, правда без php :)

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

Ты хочешь сказать, что фейсбукоконтакты постоянно лежат, лол?

У них сотни серверов, могут себе позволить любой изврат.

AlexCones ★★★
()

sqlite

highload

Почему-то я очень сильно сомневаюсь в производительности sqlite. Наверное, потому что sqlite задумывался как встраиваемая, но не как высокопроизводительная БД.

итоге все-равно каждый раз запрашивается .php файл.

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

red_eyed_peguin
()
  1. ajax
  2. frame/iframe
  3. javascript вставляющий нужный код
  4. возможно через css можно вставить чтото (похоже на изврат?)
  5. генерировать картинку (jpg, png, gif, svg)

по идее подойдёт любая вещь которую можно подгрузить через src атрибут тега

mm3 ★★★
()

Проблема в том, что имеется блок с информацией о пользователе, который на сайте залогинен.

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

Но, все-таки, я не представляю, как без JS выполнить перенаправление на https с обратным возвратом на нешифрованную страницу для авторизации.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от red_eyed_peguin

Почему-то я очень сильно сомневаюсь в производительности sqlite. Наверное, потому что sqlite задумывался как встраиваемая, но не как высокопроизводительная БД.

ну можно попробовать запихнуть sqlite в RAM диск. В принципе там все упирается как раз в диск.

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

ну можно попробовать запихнуть sqlite в RAM диск. В принципе там все упирается как раз в диск.

ну сколько можно чушь нести, то другие заголовки кроме 200 и 404 не нужны, то еще какой бред...

в sqlite всё упирается в global lock, который там по любому поводу.

ей богу, иногда лучше молчать.

anonymous
()
Ответ на: комментарий от Eddy_Em

как без JS выполнить перенаправление на https

<meta http-equiv="refresh" content="0; url=https://example.com/login.html">

с обратным возвратом на нешифрованную страницу

на уровне приложения давать статус 302 moved.

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

<meta http-equiv=«refresh» content=«0; url=https://example.com/login.html">

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от anonymous

Он же умер

Да ладно?! Неужели апач его уже не поддерживает? (сам когда-то давно использовал, пока на JS не перешел).

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от AlexCones

У них сотни серверов, могут себе позволить любой изврат.

И о каком хайлоде тогда может идти речь, если у ТС какая-нибудь хилая VDS'ка? Школотарий какой-то.

jessey
()
Ответ на: комментарий от red_eyed_peguin

Единственный ненаркоманский коммент в треде.

Почему-то я очень сильно сомневаюсь в производительности sqlite. Наверное, потому что sqlite задумывался как встраиваемая, но не как высокопроизводительная БД.

Именно! Более того, там упор идет на малое энергопотребление, чтобы в ноутах не садился акк. Sqlite - не серверная база.

anonymous
()
Ответ на: комментарий от jessey

И о каком хайлоде тогда может идти речь, если у ТС какая-нибудь хилая VDS'ка? Школотарий какой-то.

у меня знакомый есть, он тоже делал что-то очень «хайлодное» с premature-optimization. когда решил всё это делал запустить - обзвонил всех знакомых, чтобы они одновременно зашли на сайт. (Про ab, siege, jmeter он до сих пор не знает). тут возможно та же опера.

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

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

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

А если базу sqlite держать постоянно в оперативке?

Не поможет. В sqlite куча глобальных локов независимо от того, где сама база находится. Если данные туда пишутся - то это вообще ппц будет.

anonymous
()
Ответ на: комментарий от mm3

Тебе сколько лет? Каникулы уже идут?

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

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

в sqlite всё упирается в global lock, который там по любому поводу.

ей богу, иногда лучше молчать.

да, лучше тебе этим и заняться. Во многих операциях sqlite не уступает MySQL, но это с учетом, что данных в базе не очень много. При больших объемах лучше взять PgSQL.

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

Как разработчик MySQL выражаю искреннее недоумение и требую примера в студию.

sqlite спонсируется DARPA, и основной критерий оптимизации - нижний отжор батарейки. мне очень интересно, на каких таких операциях sqlite быстрее.

zabivator
()
Ответ на: комментарий от anonymous

бред.

ну давай тестить. Ты у себя, я у себя. HP DL365G7 с 32Гб памяти и 2 Opteron 6138, диски 15k SAS. CentOS 6. Создаем по RAM диску, скажем в 500Мб, и создаем там таблицу sqlite. Делаем n инсертов, потом апдейты, потом селекты. Столько же для MySQL 5.1. Идет?

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

Как разработчик MySQL выражаю искреннее недоумение и требую примера в студию.

Я же выше указал. SQLite запихивали в память. Инсерты были чуть быстрее. При большом объеме уже MySQL на диске быстрее оказывался. Толку от этого конечно нет, но для говнобложика вполне сгодится.

xpahos ★★★★★
()

и вообще, кажется на грани бреда

Под это ёмкое определение попадает каждое словосочетание твоего поста. Не заморачивайся с хайлоадом, делай как делается

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

Большие объемы данных нормально чувствуют себя в MySQL

ну уже их слишком много. Нам тут как-то предлагали оракл внедрить :) Надо было ради интереса чтоли согласиться.

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

о каких тестах может идти речь, если «SQLite does not support concurrent write access to the same database file. SQLite will simply block one of the transactions until the other one has finished.»?

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

о каких тестах может идти речь, если «SQLite does not support concurrent write access to the same database file. SQLite will simply block one of the transactions until the other one has finished.»?

не, давай тестить. Просто инсерты. Я ж не говорю, что SQLite можно воткнуть куда угодно, просто он действительно может быть использован иногда даже для веб приложений. У нас где-то даже использовался. Кажется для проверки мата в какой-то неведомой ерунде на перле.

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

Ой, ну это не тест, это фигня какая-то. На всяких микротестах намерить можно что угодно. И в таких условиях абсолютно всё равно что работает- один фиг быстро.

zabivator
()
Ответ на: комментарий от xpahos

У нас где-то даже использовался. Кажется для проверки мата в какой-то неведомой ерунде на перле.

т.е. у тебя там несколько десятков «матюков» было в БД, они оттуда SELECT-ились перлом и через regexp искались совпадения с сообщениям Леночки? Ты бы сразу написал, что ничего больше бложика не писал - у меня бы вопросов не было.

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

т.е. у тебя там несколько десятков «матюков» было в БД, они оттуда SELECT-ились перлом и через regexp искались совпадения с сообщениям Леночки? Ты бы сразу написал, что ничего больше бложика не писал - у меня бы вопросов не было.

о Б-же, это писал даже не я! Ты представляешь? Мир потерян? Посещаемость большая, пару сотен тыщ человек будет.

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

Ну хз, теже badoo нормально себя чувствуют с мускулем и отказываться от него не собираются

ну от него уже не откажешься. У нас то нет никаких абстрактных прослоек для SQL.

xpahos ★★★★★
()

хватит экономить на спичках.

pechorin
()

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

На старом проекте редис постоянно хранил фрагментальный кеш (на уровне 30к фрагментов) и забивал при этом 20-30 мб памяти.

У вас будет 30к уников в день? Нет? Будет 100-500к в день - голова наконец-то поймет, что проще сделать динамику, ибо процессор все равно большую часть времени простаивает при static-only.

pechorin
()

Автор, если сайт на php то контент уже динамический, поэтому какие нафиг проблемы с формой входа?

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

Как разработчик MySQL выражаю искреннее недоумение и требую примера в студию.

Для мелких баз и несложных запросов sqlite надерёт задницу мусклу. Бенчи делай сам. Ещё он не требует переключения контекста на каждый запрос и пересылки данных туда-сюда через сокет.

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

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

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

pechorin
()
Ответ на: комментарий от true_admin

А еще он не умеет многопоточность. Точка.

Для особо долбанутых: любая система сложнее того, что описал Икспахос будет упираться в глобальный лок sqlite3.

anonymous
()

делай на js и не переживай

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

drupal + boost и не придумывать велосипед

drupal и есть велосипед с жирным и толстым самотыком вместо сиденья.

anonymous
()
Ответ на: комментарий от pechorin

Будет 100-500к в день - голова наконец-то поймет, что проще сделать динамику, ибо процессор все равно большую часть времени простаивает при static-only.

это ты про свой опыт рассказываешь?

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

для домашней странице как в первом посте - ему хватит этого, вместо очередной новой революционной цмс с недокешированием

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