Вот так как-то (Временная тема медведя)

[dok34.ru]

HTTP compression - Wikipedia

en.m.wikipedia.org

...да, тот же gzip чаще

 

[TightBack361]

Не бесплатные.
Но с архивацией не сравнимо.
Это я говорю по наблюдению ..например, за утилитой top/htop в линуксе 🙂
Можете и сами сравнить, проверить 🙂

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

Дешёвая ОЗУ?
В каком мире?

В нашем. У нас гигабайты памяти. Сколько переписок нужно, чтобы занять такой объём? Но дело не в этом. Я предлагал хранить в памяти то, что почти не меняется между запросами. Статические страницы на диске скорее всего будут очень похожими. Представьте кучу статических файлов. Одно оформление, одна структура, они отличаются только самими сообщениями, которые и так разные. Но то что повторяется много раз как раз весит много и подлежит сжатию, а разницу между ними с текстом и так видимо лучше с диска читать. Распаковка будет похожа на объединение прочитанной с диска разницы и закешированной в памяти основы, которая весит мало.
Ну и в оригинале я предлагал что-то похожее больше на make файлы, а не на архиватор...
Типа это веселее и нет проблем темы менять... И я предлагал какой-то специфичный алгоритм, как раз чтобы было веселее.

У меня - процентов семьдесят.

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

Но с архивацией не сравнимо.

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

Плюс - при первом чтении из базы таблица помещается в память, кешируется. И затем уже из памяти читаем.

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

Но Вы правы, такое обрабатывается на лету.

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

 

[dok34.ru]

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

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

В нашем. У нас гигабайты памяти. Сколько переписок нужно, чтобы занять такой объём?

Довольно много 🙂
У меня база была больше гига ещё в прошлом году.
И она на сервере не одна 🙂

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

А это - другое дело!
Это называется CSS 🙂
С этим согласен.

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

Именно так и работает.
HTML + CSS.
Первое меняется, второе - нет, хотя занимает немало места.
Ну и картинки, включая разные аватарки и кнопки - тоже кешируются.

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

Ну да. так и делается.
Я действительно чуть про другое.
Предельный вариант, чистая статика для ряда страниц.

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

А. это тоже можно

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

Есть дисковый Кеш, и в памяти, факт!

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

Тоже можно 🙂

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

А. теперь понял, спасибо за пояснения!

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

Это само собой. Нгинкс и другие кеширующие сервера\прокси - рулят.

 

[TightBack361]

Не бесплатные.
Но с архивацией не сравнимо.
Это я говорю по наблюдению ..например, за утилитой top/htop в линуксе 🙂
Можете и сами сравнить, проверить 🙂

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

Дешёвая ОЗУ?
В каком мире?

В нашем. У нас гигабайты памяти. Сколько переписок нужно, чтобы занять такой объём? Но дело не в этом. Я предлагал хранить в памяти то, что почти не меняется между запросами. Статические страницы на диске скорее всего будут очень похожими. Представьте кучу статических файлов. Одно оформление, одна структура, они отличаются только самими сообщениями, которые и так разные. Но то что повторяется много раз как раз весит много и подлежит сжатию, а разницу между ними с текстом и так видимо лучше с диска читать. Распаковка будет похожа на объединение прочитанной с диска разницы и закешированной в памяти основы, которая весит мало.
Ну и в оригинале я предлагал что-то похожее больше на make файлы, а не на архиватор...
Типа это веселее и нет проблем темы менять... И я предлагал какой-то специфичный алгоритм, как раз чтобы было веселее.

У меня - процентов семьдесят.

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

Но с архивацией не сравнимо.

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

Плюс - при первом чтении из базы таблица помещается в память, кешируется. И затем уже из памяти читаем.

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

Но Вы правы, такое обрабатывается на лету.

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

 

[dok34.ru]

Ой. я вроде ответил сейчас...и не вижу ответа 🙂
Сорри.

 

[TightBack361]

Запрос из базы - это текст, плюс данные писавшего пост, плюс время и так далее.
Тяжёлые запросы...они не малые, у меня ограничение стоит...вроде 150Мб для запроса к базе, если ниже - иногда не хватает.

Вау. Много...
Но страницы обычно не содержат столько данных из запроса, а мы можем архивировать результат. А что там в этих запросах?
Наверное в архивации так работать не будет и нам не понадобятся такие запросы.

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

Условно как строится обычный сайт с базой данных:
1 Вызови процедуру которая отрисовывает html, подставь в места указанные в шаблоне какую-то процедуру или результат запроса к базе.
2 Для другого куска вызови следующий запрос.
3 Повтори для следующего поста.
Как у меня:
1 Запрос /posts/yy/yy - подходит ли кеш первого уровня для того чтобы показать запрос этому пользователю? Нет, зависимости не удовлетворены, потому что там появился новый пост. Кеш не соответствует.
2 Запрос /posts/yy/yy - подходят ли кеши второго уровня для того, чтобы показать запрос этому пользователю? Зависимости поста /posts/yy/yy:
header - кеш соответствует (был сгенерирован ранее) Добавляем
посты - Кеш не соответствует (появился новый пост) генерируем /posts/yy/yy/посты, зависимости:
пост 1 - Кеш соответствует Добавляем
пост 2 - Кеш соответствует Добавляем
пост 3 - Кеш не соответствует (потому что это новый пост)
Зависимости поста /posts/yy/yy/пост 3:
Оформление - кеш соответствует Добавляем
тело поста - Кеш не соответствует (кеша нет) Добавляем
время поста - Кеш не соответствует (кеша нет) Добавляем
Другое - кеш соответствует Добавляем

 

[TightBack361]

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

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

Пока писал понял, что не справился с задачей нормального объяснения. Ладно.
Робот собирает гамбургеры. У него есть окно запроса и он умеет копировать их. Копировать целиком проще, чем собирать с самого начала.
Процедура сборки гамбургера - положить ингридиенты друг на друга каждый раз запрашивая ингридиенты. В поле запроса указаны ингридиенты и ингридиенты могут "устареть".
Простая оптимизация с кешем - собираем гамбургер и копируем его. Если ингридиенты в окне запроса те же и они не устарели, то нам подойдёт копия гамбургера. Если другие - собраем гамбургер обычными запросами и тоже копируем (кешируем). Нужна жареная редиска - запрашиваем редиску как обычно и жарим. Описание того как создать гамбургер выглядит как последовательность действий.
Сложная оптимизация - есть гамбургер как первый слой кеширования, у него есть зависимости первого уровня (ингридиенты), у жареной редиски есть зависимости второго уровня - жарка.
В первом случае простой оптимизации, если у компонентов сложное построение - оно будет повторяться снова и снова - жарим огурцы, режем помидоры, жарим резаные помидоры снова и снова.
Во втором случае "рецепт" гамбургера это не последовательность действий, а зависимости между ними, к уровням кеширования которых и привязана логика сборки гамбургера:
Гамбургер:
>Булка
>Нарезанный жареный ломтик помидора
>>Жарка нарезанного помидора
>>>Резка помидора
>>>>Помидор
>Жареная редиска
>>Жарка редиски
>>>Редиска
>Жареный соевый белок с ароматизатором "сверчки"
>>Жарка соевого белка с ароматизатором "сверчки"
>>>Ароматизация соевого белка сверчками
>>>>Соевый белок
>Кетчуп
>Аналог водорослей
>Булка

 

[dok34.ru]

Я мастер непонятных объяснений, простите. Суть в том чтобы ну.

Ну, сорри - вроде всё понятно. Просто не вся информация сразу была, я и не понял, в другую степь думал 🙂

 

[TightBack361]

Просто не вся информация сразу была, я и не понял, в другую степь думал

Что-то более интересное, как мне кажется...

 

[TightBack361]

Мне трудно писать о чём-то конкретном, то что описано выше - описано криво и я забываю / переделываю детали.