нет, как одну страницу они не считали и не будут считать, наверное никогда, и наверное, это правильно. Но они могут считать это как разные страницы, т.е. каждый ифрейм как отдельную страницу, и соцно можно индексировать этот контент
да, кстати, по поводу ифреймов. Почему они могут быть тут уместны.
Для краулеров, которые в большинстве своем JS не обрабатывают сейчас ты можешь вернуть
Iframы с контентом (ифреймы видимые, чтобы в клоакинге не заподозрили), после этого джаваскриптом их сделать невидимыми для пользователей. И тем же джаваскриптом рассовать данные по странице.
Т.е. можно экспериментировать, чтобы сделать дружелюбной для сео.
ну в любом случае у нас так получается, что где-то этот кеш хранится, либо оперативная память, либо дисковый кеш.
В случае памяти, сталкиваемся с проблемой ее размера. В случае диска — дисковые операции медленные. Прийдется делать систему, которая использует что-то совместное. Блоки, которые долго можно хранить — на диск, те которые быстро инвалидируются в мемкеш.
Проблемы именно в размерах, не так остро в скорости, нгинкс быстрый.
А в варианте, который я описал. Мы вообще ничего не храним на серверной стороне. Сгенерировали данные и отдали. Пользователь получил УРЛ с экспаером. И они уже в браузерном кеше. Инвалидируем посредством предоставления новых урлов. Все данные у клиента хранятся.
ну потому что урлы для данных в блоках у каждого пользователя свои, а шаблон главной страницы у всех пользователей общий. Поэтому и ввобился общий контейнер ифрейма, который отвечает за кеширование.
то, да, можно выбирать любой из них.
Опять же, все равно как и с помощью чего, а также в каком формате ты будешь забирать данные с сервера.
>я просто не особо понял прикола этого метода
Главный прикол, заключается в том, что у тебя получается все закешировано, и при этом мемкеш сервера остаются пустые. Т.е. в мемкеше ты на самом деле не хранишь ни данных, ни представления.
Если ты используешь SSI или ESI, то там ты вырезаешь из запроса кусок с SESSIONID или user_id, для него генеришь блок представления, и весь этот блок кладешь в свой мемкеш сервер. Если твой сайт — социальная сеть, то там таких блоков будет очень много: друзья, образование, карьера, стена, любимые места и пр. Так вот, каждый такой блок ты хранишь для каждого юзера. Притом хранишь не только данные, а еще и кучу повторяющегося хтмла. Ну и рано или поздно сталкиваешься с проблемой памяти, а также с проблемой постоянно выпадающих серверов мемкеша, если у тебя их over 9000
Да, сама идеология другая, это не SSI. Просто похожая идея перенесенная на Client Side
Я же описал в статье как.
У нас есть общий блок ифрейма (неважно чего на самом деле). Который хранит в себе все блоки. Он отвечает за то, был ли какой-то из блоков изменен. У меня в статье это скрипт all_blocks_data_urls.php По запросу от пользователя смотрится его session_id или user_id и проверяется ключ в мемкеше для него. Это всего лишь флаг в мемкеше. Он не хранит данные, нас интересует только наличие ключа. Если ключ есть — возвращаем 304, и все больше никаких HTTP запросов не будет.
Также для каждого пользователя в мемкеше хранится список урлов, указывающих на данные для каждого блока для этого пользователя. Если блок изменяется, то этот урл инвалидируется.
При запросе к странице, после изменения, мы обращаемся к скрипту all_blocks_data_urls.php и он уже не возвращает 304 заголовок, а генерирует новый ответ (отдает урлы неизменившихся блоков и генерирует 1 новый для изменившегося), при этом в мемкеше выставляются снова два флага (общий, и новый урл), сами данные не хранятся!
Все урлы для блоков возвращаютсяс Expires в будущем, т.е. там запросов больше не будет.
И того, если у пользователя ничего не менялось, то это 2 запроса — первый к главной странице (там кстати тоже можно сделать кеширование на Etag или Last-Modified), второй к блоку, который вернет 304
Если что-то менялось, то запросов 3: главная, фрейм-контейнер, запрос к блоку, который изменился.
Здесь как раз происходит экономия на запросы к серверу и мы его никак не перегружаем, более того, даже память зря не используем.
А когда я через GPRS интернет (телефон подключен к ноуту) захожу на maps.google.com у меня тоже карты не сразу открываются и долгое время неотрисованные полигоны висят. И я с этим живу :-) Точнее когда-то жил
>C скриптом согласен, но тогда возникнут проблемы блокировки загрузки страницы.
ну можно колбек на window.onload повесить, тогда не будет. Да и там же не данные, а список урлов приходит. Не должно быть много
>Приведи примеры. Ты меня еще в прошлый раз не убедил.
постараюсь найти линки про парадигму кеширования на уровне представления. Грубо говоря, кеширование во вьюхах частей вьюх
Кстати, не совсем понимаю зачем ждать html5, т.к. это решение будет работать и с html 3.2
Ты очень категоричен, Саша :-)
отвечаю по пунктам.
>ифреймы — зло
о, господи, чего вы к этим ифреймам привязались. Это всего лишь транспорт. Используйте <script></script>, input hidden или что-нибудь еще
>кэшировать полный html в memcached — зло
это не правда, и это факт. В зависимости от задачи, иногда очень удобно и правильно кешировать именно представление, а не данные
>Бенчмарки показали, что в некоторых случаях SSI тоже зло.
статья не об SSI. А о CSI кешировании, его можно использовать в паре с SSI, кешируя те самые темплеты. А можно вообще не использовать it's up to you.
А по поводу коннектов — при изменении одного блока всего 3 запроса (на главную страницу, на общий транспортный ифрейм, и к этому блоку данных).
>это обязательность JS для статичного контента
Если сайт полностью статический — это другой вид задачи, и другой вид кеширования. Хотя я не много таких в последнее время видел. Покажите мне такой сайт — я скажу как его правильно кешировать.
Предложенный мной вариант это не «серебрянная пуля», коих к счастью не бывает, а вариант, который может подойти определенным сервисам
кстати, я так понял объем данных для тестов был не больше гигабайта, т.е. все данные были в кеше, что тоже как бы не самый лучший тест для БД
тогда бы уже рядом и мемкеш потестировали бы
The per-minute quotas for application with billing enabled allow for up to 500 requests per second--more than one billion requests per month. If your application requires even higher quotas than the «billing-enabled» values listed below, you can request an increase in these limits here.
In addition to the daily quotas described above, App Engine moderates how quickly an app can consume a resource, using per-minute quotas. This protects the app from consuming all of its quota in very short periods of time, and keeps other apps from affecting your app by monopolizing a given resource.
Не глупо, Google предоставляет «Platform as a Service (PaaS)» в виде Google Apps, а это соответственно полный стек услуг из коробки, включая Big Table, т.к. ничего другого кроме Big Table + Memcached в Google Apps использовать нельзя.
Для краулеров, которые в большинстве своем JS не обрабатывают сейчас ты можешь вернуть
Iframы с контентом (ифреймы видимые, чтобы в клоакинге не заподозрили), после этого джаваскриптом их сделать невидимыми для пользователей. И тем же джаваскриптом рассовать данные по странице.
Т.е. можно экспериментировать, чтобы сделать дружелюбной для сео.
Не нужно пытаться смешать данные и представление, им хорошо друг без друга
В случае памяти, сталкиваемся с проблемой ее размера. В случае диска — дисковые операции медленные. Прийдется делать систему, которая использует что-то совместное. Блоки, которые долго можно хранить — на диск, те которые быстро инвалидируются в мемкеш.
Проблемы именно в размерах, не так остро в скорости, нгинкс быстрый.
А в варианте, который я описал. Мы вообще ничего не храним на серверной стороне. Сгенерировали данные и отдали. Пользователь получил УРЛ с экспаером. И они уже в браузерном кеше. Инвалидируем посредством предоставления новых урлов. Все данные у клиента хранятся.
Или я не совсем вопроса понял? :-)
Да, помню, общались.
>можно вопрос — а не проще ли тогда полностью javascript templates & json data «метод» использовать так сказать?
Если ты имеешь в виду различные JS темплеты типа
code.google.com/p/trimpath/wiki/JavascriptTemplates
или
code.google.com/p/embeddedjavascript/
то, да, можно выбирать любой из них.
Опять же, все равно как и с помощью чего, а также в каком формате ты будешь забирать данные с сервера.
>я просто не особо понял прикола этого метода
Главный прикол, заключается в том, что у тебя получается все закешировано, и при этом мемкеш сервера остаются пустые. Т.е. в мемкеше ты на самом деле не хранишь ни данных, ни представления.
Если ты используешь SSI или ESI, то там ты вырезаешь из запроса кусок с SESSIONID или user_id, для него генеришь блок представления, и весь этот блок кладешь в свой мемкеш сервер. Если твой сайт — социальная сеть, то там таких блоков будет очень много: друзья, образование, карьера, стена, любимые места и пр. Так вот, каждый такой блок ты хранишь для каждого юзера. Притом хранишь не только данные, а еще и кучу повторяющегося хтмла. Ну и рано или поздно сталкиваешься с проблемой памяти, а также с проблемой постоянно выпадающих серверов мемкеша, если у тебя их over 9000
Да, сама идеология другая, это не SSI. Просто похожая идея перенесенная на Client Side
чтобы не регекспом колбасить, а делать getElementById по айдишнику этого дива.
Но это уже реализация темплетного движка
Я же описал в статье как.
У нас есть общий блок ифрейма (неважно чего на самом деле). Который хранит в себе все блоки. Он отвечает за то, был ли какой-то из блоков изменен. У меня в статье это скрипт all_blocks_data_urls.php По запросу от пользователя смотрится его session_id или user_id и проверяется ключ в мемкеше для него. Это всего лишь флаг в мемкеше. Он не хранит данные, нас интересует только наличие ключа. Если ключ есть — возвращаем 304, и все больше никаких HTTP запросов не будет.
Также для каждого пользователя в мемкеше хранится список урлов, указывающих на данные для каждого блока для этого пользователя. Если блок изменяется, то этот урл инвалидируется.
При запросе к странице, после изменения, мы обращаемся к скрипту all_blocks_data_urls.php и он уже не возвращает 304 заголовок, а генерирует новый ответ (отдает урлы неизменившихся блоков и генерирует 1 новый для изменившегося), при этом в мемкеше выставляются снова два флага (общий, и новый урл), сами данные не хранятся!
Все урлы для блоков возвращаютсяс Expires в будущем, т.е. там запросов больше не будет.
И того, если у пользователя ничего не менялось, то это 2 запроса — первый к главной странице (там кстати тоже можно сделать кеширование на Etag или Last-Modified), второй к блоку, который вернет 304
Если что-то менялось, то запросов 3: главная, фрейм-контейнер, запрос к блоку, который изменился.
Здесь как раз происходит экономия на запросы к серверу и мы его никак не перегружаем, более того, даже память зря не используем.
ну можно колбек на window.onload повесить, тогда не будет. Да и там же не данные, а список урлов приходит. Не должно быть много
>Приведи примеры. Ты меня еще в прошлый раз не убедил.
постараюсь найти линки про парадигму кеширования на уровне представления. Грубо говоря, кеширование во вьюхах частей вьюх
Кстати, не совсем понимаю зачем ждать html5, т.к. это решение будет работать и с html 3.2
Но, некоторые блоки, очень быстро инвалидируются, например — последние коментарии на главной странице и прочее.
ну и по поводу ифрейма я ниже отписался :-)
отвечаю по пунктам.
>ифреймы — зло
о, господи, чего вы к этим ифреймам привязались. Это всего лишь транспорт. Используйте <script></script>, input hidden или что-нибудь еще
>кэшировать полный html в memcached — зло
это не правда, и это факт. В зависимости от задачи, иногда очень удобно и правильно кешировать именно представление, а не данные
>Бенчмарки показали, что в некоторых случаях SSI тоже зло.
статья не об SSI. А о CSI кешировании, его можно использовать в паре с SSI, кешируя те самые темплеты. А можно вообще не использовать it's up to you.
А по поводу коннектов — при изменении одного блока всего 3 запроса (на главную страницу, на общий транспортный ифрейм, и к этому блоку данных).
>это обязательность JS для статичного контента
Если сайт полностью статический — это другой вид задачи, и другой вид кеширования. Хотя я не много таких в последнее время видел. Покажите мне такой сайт — я скажу как его правильно кешировать.
Предложенный мной вариант это не «серебрянная пуля», коих к счастью не бывает, а вариант, который может подойти определенным сервисам
Которое является неким аналогом Amazon S3
В нем как раз нет ограничений на объем хранимых данных habrahabr.ru/blogs/hi/94964/#comment_2895982
msdn.microsoft.com/en-us/library/ee691964.aspx
Притом тут есть, фактически, транзакционная модель.
кстати, я так понял объем данных для тестов был не больше гигабайта, т.е. все данные были в кеше, что тоже как бы не самый лучший тест для БД
тогда бы уже рядом и мемкеш потестировали бы
code.google.com/appengine/docs/quotas.html#Requests
The per-minute quotas for application with billing enabled allow for up to 500 requests per second--more than one billion requests per month. If your application requires even higher quotas than the «billing-enabled» values listed below, you can request an increase in these limits here.
code.google.com/appengine/docs/quotas.html#Per-minute_Quotas
In addition to the daily quotas described above, App Engine moderates how quickly an app can consume a resource, using per-minute quotas. This protects the app from consuming all of its quota in very short periods of time, and keeps other apps from affecting your app by monopolizing a given resource.