Здравствуйте, Sinclair, Вы писали:

S>Я пытаюсь объяснить, что "отдача статики с диска" — адски оптимизированная операция. Есть разные стратегии оптимизации — http.sys, сплайсы, sendfile.
S>Порвать это при помощи шаблонизатора с "прямой записью" — дохлый номер.
В такой формулировке согласен. Но приведу интересный пример — нам в проекте надо добавить репозиторий для бинарных артефактов (образы Docker, характерный размер в 100-200Мб).

Задача достаточно обычная и решение очевидное — поставить nginx и из динамического кода просто перенаправлять на нужный статический файл. Но сначала сделали простенькую реализацию на Питоне (+PyPy) из 10 строк кода, чисто для эксперимента, пока я допиливаю развёртывание nginx.

Вот только оказалось, что эта детская версия работает почти с такой же скоростью, что и nginx. Splice творит чудеса.

Здравствуйте, Cyberax, Вы писали:

C>Вот только оказалось, что эта детская версия работает почти с такой же скоростью, что и nginx. Splice творит чудеса.
Конечно. Но эти чудеса, собственно, требуют наличия двух "файловых дескрипторов". То, что IO стек в современных осях позволяет оффлоадить взаимодействие диск-сеть и диск-диск за пределы CPU — это прекрасно. Весь выигрыш, собственно, и достигается за счёт а) отсутствия переключений контекста в процессе передачи и б) возможности выдвинуть всю коммуникацию между физическими устройствами за пределы процессора.

Как только мы попробуем запихивать те же данные в сокет из нашего юзермодного приложения мелкими порциями — грубо говоря, построчно — как вся магия тут же развеется.
Поэтому романтизировать compile-time шаблонизаторы — бессмысленное занятие. С точки зрения сетевой карты, они почти столь же неэффективны, как и "медленные" скрипты. Стоимость склейки строк, происходящей между вызовами socket.Send(), пренебрежимо мала по сравнению с самими вызовами.

Здравствуйте, Ikemefula, Вы писали:

I>Ты ничего не показал. Я вот никак не могу понять, что же будет отдаваться на клиент — html со всеми данными, просто темплейт или какие то данные вместе с темплейтом.

I>Судя по твоим косвенным намёкам, отдавать надо Html со всеми данными. А это, внезапно, исключает 90% оптимизаций. А следовательно "не будет стоить практически ничего" есть просто враньё.

Уже в который раз повторяю: это зависит от выбранной стратегии на клиенте, а не от vibe.d. Ты можешь отдавать на клиента статические js шаблоны плюс данные через ajax. Можешь отдавать js шаблоны + данные внутри одной html страницы. А можешь отдавать уже готовые html страницы без всяких скриптов, как в старом веб'е. Выбор на твой вкус, а vibe.d будет одинаково эффективно поддерживать любой из этих сценариев.

I>Для сравнения. Работа с темплейтами на клиенте означает, что серверу надо исключительно данные отдавать.
I>Если на серверве, то отдавать надо в сотни раз больше чисто из за того, что данные унуте html. Кроме того, это вызывает проблемы например с кешированием, делает невозможным использование большинтсва других оптимизаций. Например, CDN тебе так же не поможет.

Так сравнивать то надо конкурирующие между собой вещи, а это дополняющие друг друга... )

Здравствуйте, Ikemefula, Вы писали:

I>Ну да, в среднем это гораздо больше будет. Я вот книги в epub формате вижу, около 100мб в зипе. Надо объяснять, что зип жмёт текст примерно 10 к 1 ?
I>Книг может быть очень много. Вопрос — обо что встанет сделать веб-интерфейс для небольшой библиотеки, скажем в 1-10 тыс книжек ?

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

I>Не рассказывай ерунды. http://www.webperformance.com/load-testing/blog/2011/11/what-is-the-fastest-webserver/

Ой, да я таких ссылок с любым результатом могу столько накидать... ))) Меня больше убеждают вот такие картинки:
Кстати, в контексте нашей дискуссии небезынтересно взглянуть и на поведение "Other"...

Здравствуйте, Sinclair, Вы писали:

S>Мы, вроде бы, говорим про server-side шаблонизатор vs client-side. Для client-side шаблон является "статическим файлом", достаточно маленького размера. Его очень легко держать в кэше, как на клиентской стороне, так и на серверной. Для server-side шаблон существует только в памяти сервера, при отдаче он умножается на размер данных. Его нельзя кэшировать на клиенте, т.к. он "размазан" по результату.

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

S>Вам понятно, что в современном мире он весь сидит в кэше? Поэтому рассуждать о временах доступа к диску — это бравировать некомпетентностью.

Как теперь понятно по тексту ниже, вы подразумевали везде output caching http демонов. Это сразу вызывает множество комментариев:
1. Вообще то подобный кэш всегда умеет работать и для статических файлов и для динамического контента (причём в контексте нашего обсуждения, контент на самом деле даже не динамический, а просто генерируется на ходу, но всегда один и тот же). Так что совершенно непонятно привлечение его в качестве аргументации в противопоставление шаблонизаторов и статических файлов.
2. Даже если предположить, что для шаблонизатора вы почему-то отключаете кэш, а для статики нет, то всё равно выдача происходит почти одинаковым образом — копирование одного куска оперативной памяти в другой. Максимум разницы, это в случае IIS на один переход в нулевое кольцо больше, что просто смешно, как мы уже увидели из ваших же цифр. И это всё говорилось для случая "прогретого кэша", а если учитывать ещё и отсутствие данных в кэше (они кстати туда не обязательно после первого запроса попадают), то...
3. Настройки кэшей у всех серверов конечно же разные... Но если взять скажем ваш любимый IIS, то уже видно http://www.iis.net/learn/manage/managing-performance-settings/configure-iis-7-output-caching что там далеко не всё так радужно с кэшированием. И отсутствие обращений к файловой системе является преувеличением. И в режиме ядра умеет кэшировать далеко не всё. И с настройками этого дела не всё так тривиально (я не про сложность, а про вообще возможность получить то, что хочешь).

Вообще странно, что вы изначально не вспомнили такие инструменты как memcached, и nginx в режиме прокси (как его очень часто используют)и т.п... Это всё действительно будет обходить по скорости всяческие шаблонизаторы (голые). Может дело в том, что это всё опять же вполне применимо (и не только в теории, но так обычно и делают, правда не с обсуждаемым в этой темке шаблонизатором, т.к. он и сам быстрый) и поверх шаблонизаторов? )))

Здравствуйте, alex_public, Вы писали:

_>Нет, разговор, в который вы вмешались, был о сравнение отдачи клиентского js шаблона в виде статического файла и отдаче его же через работу серверного шаблона (типа jade).
А я-то думал вы тут рассказываете про военные чудеса фреймворков на D, которые пытаются генерировать разметку на сервере по шаблонам, скомпилированным на D.

_>Сравнения же реальной динамики (с обращением к базам данных и т.п.) со статикой очевидно абсолютно глупое занятие и никто тут этим не занимался.

_>Как теперь понятно по тексту ниже, вы подразумевали везде output caching http демонов. Это сразу вызывает множество комментариев:
_>1. Вообще то подобный кэш всегда умеет работать и для статических файлов и для динамического контента (причём в контексте нашего обсуждения, контент на самом деле даже не динамический, а просто генерируется на ходу, но всегда один и тот же). Так что совершенно непонятно привлечение его в качестве аргументации в противопоставление шаблонизаторов и статических файлов.
Просто для статических файлов "подобный кэш" очень хорошо умеет инвалидироваться, поэтому он в среднем лучше хэндлит Conditional Get.

_>2. Даже если предположить, что для шаблонизатора вы почему-то отключаете кэш, а для статики нет, то всё равно выдача происходит почти одинаковым образом — копирование одного куска оперативной памяти в другой. Максимум разницы, это в случае IIS на один переход в нулевое кольцо больше, что просто смешно, как мы уже увидели из ваших же цифр. И это всё говорилось для случая "прогретого кэша", а если учитывать ещё и отсутствие данных в кэше (они кстати туда не обязательно после первого запроса попадают), то...
Если мы хотим учесть отсутствие данных в кэше, то мы с тем же успехом можем учесть отсутствие бинарного кода в кэше. Как мы знаем, современные ОС не загружают весь исполняемый файл — вместо этого они включают memory mapping, и при исполнении кода страницы поднимаются с диска в память "на общих основаниях".

_>3. Настройки кэшей у всех серверов конечно же разные... Но если взять скажем ваш любимый IIS, то уже видно http://www.iis.net/learn/manage/managing-performance-settings/configure-iis-7-output-caching что там далеко не всё так радужно с кэшированием. И отсутствие обращений к файловой системе является преувеличением. И в режиме ядра умеет кэшировать далеко не всё. И с настройками этого дела не всё так тривиально (я не про сложность, а про вообще возможность получить то, что хочешь).
Конечно. Просто в случае велосипеда, который чего-то там пишет в Response.OutputStream, даже этого "не всё так радужно" достичь очень тяжело.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Sinclair, Вы писали:

S>>Мы, вроде бы, говорим про server-side шаблонизатор vs client-side. Для client-side шаблон является "статическим файлом", достаточно маленького размера. Его очень легко держать в кэше, как на клиентской стороне, так и на серверной. Для server-side шаблон существует только в памяти сервера, при отдаче он умножается на размер данных. Его нельзя кэшировать на клиенте, т.к. он "размазан" по результату.

_>Нет, разговор, в который вы вмешались, был о сравнение отдачи клиентского js шаблона в виде статического файла и отдаче его же через работу серверного шаблона (типа jade). Сравнения же реальной динамики (с обращением к базам данных и т.п.) со статикой очевидно абсолютно глупое занятие и никто тут этим не занимался.

S>>Вам понятно, что в современном мире он весь сидит в кэше? Поэтому рассуждать о временах доступа к диску — это бравировать некомпетентностью.

_>Как теперь понятно по тексту ниже, вы подразумевали везде output caching http демонов. Это сразу вызывает множество комментариев:
_>1. Вообще то подобный кэш всегда умеет работать и для статических файлов и для динамического контента (причём в контексте нашего обсуждения, контент на самом деле даже не динамический, а просто генерируется на ходу, но всегда один и тот же). Так что совершенно непонятно привлечение его в качестве аргументации в противопоставление шаблонизаторов и статических файлов.
Динамический контент на то и динамический, что меняется. Если его кешировать, то надо знать когда сбрасывать кеш или как кеш варьировать, это все снижает Hit-Miss Ratio.
Теперь банальный расчет — предположим удалось сделать кеш для динамического контента, который с вероятностью 50% попадает. Средний размер страницы — 60кб. Шаблонизатор работает 1 мсек.
Приходит 1М запросов — это 500 секунд работы шаблонизатора и около 28 гб трафика.

Переносим шаблонизатор на клиент — шаблон весит 60кб, отдается один раз и лежит в кеше (ядра или reverse proxy). Данные для работы шаблонизатора — 5кб, при этом можно подобрать гранулярность запросов данных, чтобы повысить hit-miss ratio. Предположим удалось 60% сделать. Тот же 1М запросов — время на сервере — 0, трафик — 3гб, так еще и к внешнем данным обращаться реже надо из-за более удачного кеширования.

В реальном же случает кшировать генерируемые на сервере страницы нереально, слишком изменчивы и слишком сложно вычислять когда сбрасывать кеш. А для ajax запросов данных совсем наоборот.
Так что с точки зрения кеша клиентская шаблонизация рулит. Фактичекси рулит она почти всегда, кроме слабых устройств обходчиков поиска.

_>3. Настройки кэшей у всех серверов конечно же разные... Но если взять скажем ваш любимый IIS, то уже видно http://www.iis.net/learn/manage/managing-performance-settings/configure-iis-7-output-caching что там далеко не всё так радужно с кэшированием. И отсутствие обращений к файловой системе является преувеличением. И в режиме ядра умеет кэшировать далеко не всё. И с настройками этого дела не всё так тривиально (я не про сложность, а про вообще возможность получить то, что хочешь).
Статику как раз в режиме ядра кеширует. Динамику — в памяти приложения.

Здравствуйте, Sinclair, Вы писали:

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

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

S>Если мы хотим учесть отсутствие данных в кэше, то мы с тем же успехом можем учесть отсутствие бинарного кода в кэше. Как мы знаем, современные ОС не загружают весь исполняемый файл — вместо этого они включают memory mapping, и при исполнении кода страницы поднимаются с диска в память "на общих основаниях".

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

S>Конечно. Просто в случае велосипеда, который чего-то там пишет в Response.OutputStream, даже этого "не всё так радужно" достичь очень тяжело.

Ну вообще то vibe.d был создан совсем не для того, чтобы соревноваться с http серверами в отдаче статики. Он предназначен для обгона совсем других конкурентов — см. первые же диаграммы тут http://dconf.org/2013/talks/panteleev.pdf. Более того, он естественно умеет отдавать статические страницы обычным образом (из файлов), а не только через шаблонизатор. ))) Так что никакого позиционирования на конкуренцию со статическими серверами нет. Просто я отметил в одном месте Ikemefula, что подобный шаблонизатор может обойти по быстродействию даже отдачу шаблона из статического файла (при условии, что шаблонизатор отдаёт такую же страницу, а не какую-то динамику с данными из базы). А вы прицепились к этой фразе и начали строить теории про велосипеды. )))

Здравствуйте, Sinclair, Вы писали:

C>>Вот только оказалось, что эта детская версия работает почти с такой же скоростью, что и nginx. Splice творит чудеса.
S>Конечно. Но эти чудеса, собственно, требуют наличия двух "файловых дескрипторов".
Необязательно. Сплайсы можно делать прямо из куска памяти (выравненного по границе страницы). Sendfile — это просто частный случай, когда страницы просто лежат в файловом кэше.

S>Как только мы попробуем запихивать те же данные в сокет из нашего юзермодного приложения мелкими порциями — грубо говоря, построчно — как вся магия тут же развеется.
А зачем так делать? Рендерим всю страницу (ну или заметный её кусок, скажем в районе мегабайта) и сплайсим его в сокет. Во время передачи мы можем даже продолжать рендеринг в другом потоке.

Здравствуйте, gandjustas, Вы писали:

G>Динамический контент на то и динамический, что меняется. Если его кешировать, то надо знать когда сбрасывать кеш или как кеш варьировать, это все снижает Hit-Miss Ratio.
G>Теперь банальный расчет — предположим удалось сделать кеш для динамического контента, который с вероятностью 50% попадает. Средний размер страницы — 60кб. Шаблонизатор работает 1 мсек.
G>Приходит 1М запросов — это 500 секунд работы шаблонизатора и около 28 гб трафика.

G>Переносим шаблонизатор на клиент — шаблон весит 60кб, отдается один раз и лежит в кеше (ядра или reverse proxy). Данные для работы шаблонизатора — 5кб, при этом можно подобрать гранулярность запросов данных, чтобы повысить hit-miss ratio. Предположим удалось 60% сделать. Тот же 1М запросов — время на сервере — 0, трафик — 3гб, так еще и к внешнем данным обращаться реже надо из-за более удачного кеширования.

G>В реальном же случает кшировать генерируемые на сервере страницы нереально, слишком изменчивы и слишком сложно вычислять когда сбрасывать кеш. А для ajax запросов данных совсем наоборот.
G>Так что с точки зрения кеша клиентская шаблонизация рулит. Фактичекси рулит она почти всегда, кроме слабых устройств обходчиков поиска.

Вот надо бы тебе всё же читать дискуссию с самого начала, а не кусками. Тогда не пришлось бы писать столько довольно разумного текста понапрасну. В данной темке обсуждалась ситуация сравнения отдачи клиентского js шаблона как статического файла, в сравнение с отдачей этого же клиентского js шаблона через его динамическую генерацию с помощью серверного шаблона. Во всяком случае именно к моей реплике к Ikemefula, что при таком раскладе шаблонизатор может обойти даже статическую отдачу, и прицепился Sinclair.

G>Статику как раз в режиме ядра кеширует. Динамику — в памяти приложения.

Там же написано, что даже банальная авторизация отключает кэширование...

Здравствуйте, alex_public, Вы писали:
_>Да, именно. Но я так и не понял почему некоторые, считают подобную технологию в чём-то противопоставленной клиентским js скриптам, в то время как очевидно, что это дополняющие друг друга технологии. В частности вполне можно генерировать клиентские js шаблоны с помощью серверных шаблонов (кстати, с помощью того же jade частенько генерируют и полностью статические страницы, просто это происходит на компьютере разработчика, а не на сервере в реальном времени).
Простите, я потерял нить. Что такое "клиентские js шаблоны"?


_>Только правила разные. Если взглянуть на описание того же IIS, то там вполне указано, что не каждый запрос попадает в кэш...
Вы поймите, что для статики уже написаны правила и код, которые очень хорошо работают из коробки. Если вы пишете хэндлер, который отдаёт статический файл "вручную", то вам придётся сильно нагнуться для того, чтобы достичь производительности nginx или lighttpd.

_>Ну вообще то vibe.d был создан совсем не для того, чтобы соревноваться с http серверами в отдаче статики. Он предназначен для обгона совсем других конкурентов — см. первые же диаграммы тут http://dconf.org/2013/talks/panteleev.pdf. Более того, он естественно умеет отдавать статические страницы обычным образом (из файлов), а не только через шаблонизатор.
А что такое "обычным образом"? Он рассчитан на встраивание в инфраструктуру IIS или на самостоятельную работу? Есть ли в нём output cache? Использует ли он TransmitFile/splice для оффлоада отправки в железо?

_>))) Так что никакого позиционирования на конкуренцию со статическими серверами нет. Просто я отметил в одном месте Ikemefula, что подобный шаблонизатор может обойти по быстродействию даже отдачу шаблона из статического файла (при условии, что шаблонизатор отдаёт такую же страницу, а не какую-то динамику с данными из базы). А вы прицепились к этой фразе и начали строить теории про велосипеды. )))
Конечно прицепился. Потому что "подобный шаблонизатор" никак не сможет обойти по быстродействию отдачу шаблона из статического файла. Ну, то есть если мы возьмём одиночный запрос, то один из response time шаблонизатора может оказаться короче, чем один из response time классического HTTP-демона. Благодаря изначально неравным условиям — например, шаблонизатор прогрет, а статический хэндлер запускается из прогретого кэша.
А если мы будем симулировать реальную нагрузку и смотреть на response time и throughput, то шаблонизатор всегда будет не лучше, чем статический хэндлер. Природу не обманешь.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Sinclair, Вы писали:

C>>>Вот только оказалось, что эта детская версия работает почти с такой же скоростью, что и nginx. Splice творит чудеса.
S>>Конечно. Но эти чудеса, собственно, требуют наличия двух "файловых дескрипторов".
C>Необязательно. Сплайсы можно делать прямо из куска памяти (выравненного по границе страницы).
Тогда будет маршаллинг из юзермоды в кернел; а тот конкретный splice(2), о котором идёт речь, пользуется перемещением данных в кернел-моде.
C>А зачем так делать? Рендерим всю страницу (ну или заметный её кусок, скажем в районе мегабайта) и сплайсим его в сокет. Во время передачи мы можем даже продолжать рендеринг в другом потоке.
Если так делать, то мы быстро упрёмся в размеры буферов. Если, скажем, у нас буфер в районе мегабайта, то во всём адресном пространстве 32х-разрядного процесса мы не сможем одновременно обслуживать больше 2000 клиентов, что для веба как бы приговор. Ну, то есть на самом деле ещё меньше, т.к. адресное пространство нам нужно не только для буферов под сплайсинг.
Конечно, х64 немножко улучшает ситуацию, но в целом, оффлоадить нагрузку за пределы своего процесса — более грамотная стратегия.

Здравствуйте, alex_public, Вы писали:

_>Там же написано, что даже банальная авторизация отключает кэширование...
В режиме ядра, в режиме ядра. В юзермоде кэширование всё ещё возможно.
Шаблоны обычно не требуют авторизации, т.к. не содержат никаких sensitive данных.

Здравствуйте, Sinclair, Вы писали:

C>>Необязательно. Сплайсы можно делать прямо из куска памяти (выравненного по границе страницы).
S>Тогда будет маршаллинг из юзермоды в кернел; а тот конкретный splice(2), о котором идёт речь, пользуется перемещением данных в кернел-моде.
Не будет. Splice(2) помечает куски памяти как защищённые, так что при обращении их изменении из пользовательского пространства произойдёт Copy-On-Write. В результате, сетевая карта может читать из засплайсенного буфера как из своего, не боясь разных гонок.

S>Если так делать, то мы быстро упрёмся в размеры буферов. Если, скажем, у нас буфер в районе мегабайта, то во всём адресном пространстве 32х-разрядного процесса мы не сможем одновременно обслуживать больше 2000 клиентов, что для веба как бы приговор. Ну, то есть на самом деле ещё меньше, т.к. адресное пространство нам нужно не только для буферов под сплайсинг.
2000 одновременных клиентов, что уже неплохо. Ну и таки x64 есть уже везде.

S>Конечно, х64 немножко улучшает ситуацию, но в целом, оффлоадить нагрузку за пределы своего процесса — более грамотная стратегия.
Это смотря для чего. Клиентские шаблоны мне, лично, не очень нравятся по многим причинам.

Здравствуйте, Cyberax, Вы писали:
C>Не будет. Splice(2) помечает куски памяти как защищённые, так что при обращении их изменении из пользовательского пространства произойдёт Copy-On-Write. В результате, сетевая карта может читать из засплайсенного буфера как из своего, не боясь разных гонок.
Ничего не понял. Я плохо знаком с Linux технологиями. Вот, читаю тут:
1. Никакого упоминания про возможность копирования из буфера в сокет. Чёрным по белому написано:

splice() moves data between two file descriptors without copying between kernel address space and user address space.

2. Есть упоминания про семантику move, в сочетании с vmsplice(). Я до конца их не понял; про copy-on-write ничего не сказано, зато сказано, что если типа не указать SPLICE_F_GIFT в vmsplice(), то последующий splice() будет вынужден копировать страницы.
C>2000 одновременных клиентов, что уже неплохо. Ну и таки x64 есть уже везде.
В жизни это означает 300 одновременных клиентов. Расходы памяти на каждого клиента стоит минимизировать. Тут как раз баланс: делаем большие буфера — снижаем concurrency. Делаем маленькие — тратимся на context switch и постоянный ремаппинг между user address space и kernel address space.

S>>Конечно, х64 немножко улучшает ситуацию, но в целом, оффлоадить нагрузку за пределы своего процесса — более грамотная стратегия.
C>Это смотря для чего. Клиентские шаблоны мне, лично, не очень нравятся по многим причинам.
Это для улучшения масштабируемости.

Здравствуйте, alex_public, Вы писали:

_>Ой, да я таких ссылок с любым результатом могу столько накидать... ))) Меня больше убеждают вот такие картинки: http://cdn-static.zdnet.com/i/r/story/70/00/017838/webserverjuly2013-620x359.png
_>Кстати, в контексте нашей дискуссии небезынтересно взглянуть и на поведение "Other"...
И в чёи, интересно, такие картинки могут убедить? Что большинство вебсайтов строится людьми, не имеющими ни малейшего представления о производительности, так что даже самый уродский сервер, который только можно себе представить, доминирует на рынке с большим отрывом?
Простите, это вообще ничего не доказывает в техническом плане.

Здравствуйте, Sinclair, Вы писали:

S>2. Есть упоминания про семантику move, в сочетании с vmsplice(). Я до конца их не понял; про copy-on-write ничего не сказано, зато сказано, что если типа не указать SPLICE_F_GIFT в vmsplice(), то последующий splice() будет вынужден копировать страницы.
Да. Алгоритм такой:
1) Создаётся неименованый пайп.
2) Делается vmsplice() с SPLICE_F_GIFT. Ядро получает стабильную копию данных.
3) Делается splice() с другого конца пайпа в сокет. Физически в пайп ничего не пишется, конечно же.

C>>2000 одновременных клиентов, что уже неплохо. Ну и таки x64 есть уже везде.
S>В жизни это означает 300 одновременных клиентов. Расходы памяти на каждого клиента стоит минимизировать. Тут как раз баланс: делаем большие буфера — снижаем concurrency. Делаем маленькие — тратимся на context switch и постоянный ремаппинг между user address space и kernel address space.
В Линуксе это достаточно тривиальная операция. Кстати, с помощью BPF (Berkely Packet Filter — такая виртуальная машинка в ядре, с простым JIT) можно даже часть её перенести в kernelspace.

C>>Это смотря для чего. Клиентские шаблоны мне, лично, не очень нравятся по многим причинам.
S>Это для улучшения масштабируемости.
Только вот в случае больших страниц (мегабайт, как ты сам привёл) обработка на мобильных устройствах занимает достаточно много времени и требует батарейку. Причём весьма так заметно.

Во-вторых, большинство (все?) распространённые клиентские шаблонизаторы требуют полностью загруженного шаблона, чтобы начать рисовать страницу. При плохом мобильном соединении в результате получаем белый квадрат Малевича, пока страница загружается. В случае с серверными шаблонами Хром и другие браузеры умеют делать прогрессивный рендеринг.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

G>>Динамический контент на то и динамический, что меняется. Если его кешировать, то надо знать когда сбрасывать кеш или как кеш варьировать, это все снижает Hit-Miss Ratio.
G>>Теперь банальный расчет — предположим удалось сделать кеш для динамического контента, который с вероятностью 50% попадает. Средний размер страницы — 60кб. Шаблонизатор работает 1 мсек.
G>>Приходит 1М запросов — это 500 секунд работы шаблонизатора и около 28 гб трафика.

G>>Переносим шаблонизатор на клиент — шаблон весит 60кб, отдается один раз и лежит в кеше (ядра или reverse proxy). Данные для работы шаблонизатора — 5кб, при этом можно подобрать гранулярность запросов данных, чтобы повысить hit-miss ratio. Предположим удалось 60% сделать. Тот же 1М запросов — время на сервере — 0, трафик — 3гб, так еще и к внешнем данным обращаться реже надо из-за более удачного кеширования.

G>>В реальном же случает кшировать генерируемые на сервере страницы нереально, слишком изменчивы и слишком сложно вычислять когда сбрасывать кеш. А для ajax запросов данных совсем наоборот.
G>>Так что с точки зрения кеша клиентская шаблонизация рулит. Фактичекси рулит она почти всегда, кроме слабых устройств обходчиков поиска.

_>Вот надо бы тебе всё же читать дискуссию с самого начала, а не кусками. Тогда не пришлось бы писать столько довольно разумного текста понапрасну. В данной темке обсуждалась ситуация сравнения отдачи клиентского js шаблона как статического файла, в сравнение с отдачей этого же клиентского js шаблона через его динамическую генерацию с помощью серверного шаблона. Во всяком случае именно к моей реплике к Ikemefula, что при таком раскладе шаблонизатор может обойти даже статическую отдачу, и прицепился Sinclair.


Я все прочитал. Ключевая фраза — Динамический контент на то и динамический, что меняется.
Если не меняется, то сгенерируй один раз и положи файлом, тогда IIS с его отдачей из ядра порвет любую реализацию.

G>>Статику как раз в режиме ядра кеширует. Динамику — в памяти приложения.
_>Там же написано, что даже банальная авторизация отключает кэширование...
Статика по умолчанию не проходит через авторизацию.

Здравствуйте, Cyberax, Вы писали:
C>Да. Алгоритм такой:
C>1) Создаётся неименованый пайп.
C>2) Делается vmsplice() с SPLICE_F_GIFT. Ядро получает стабильную копию данных.
C>3) Делается splice() с другого конца пайпа в сокет. Физически в пайп ничего не пишется, конечно же.
А, я-то думал что на одном конце сокет, а на другом — файл.

C>>>2000 одновременных клиентов, что уже неплохо. Ну и таки x64 есть уже везде.
S>>В жизни это означает 300 одновременных клиентов. Расходы памяти на каждого клиента стоит минимизировать. Тут как раз баланс: делаем большие буфера — снижаем concurrency. Делаем маленькие — тратимся на context switch и постоянный ремаппинг между user address space и kernel address space.
C>В Линуксе это достаточно тривиальная операция. Кстати, с помощью BPF (Berkely Packet Filter — такая виртуальная машинка в ядре, с простым JIT) можно даже часть её перенести в kernelspace.
Не очень понял, что именно можно перенести в kernelspace? формирование выходной разметки, накладывая шаблон на результат выборки из базы?

C>Только вот в случае больших страниц (мегабайт, как ты сам привёл) обработка на мобильных устройствах занимает достаточно много времени и требует батарейку. Причём весьма так заметно.

C>Во-вторых, большинство (все?) распространённые клиентские шаблонизаторы требуют полностью загруженного шаблона, чтобы начать рисовать страницу. При плохом мобильном соединении в результате получаем белый квадрат Малевича, пока страница загружается. В случае с серверными шаблонами Хром и другие браузеры умеют делать прогрессивный рендеринг.
Не очень понимаю, как так. Шаблон же сам по себе — это всего лишь кусок <tr></tr> с плейсхолдерами, условно говоря. Как он может загрузиться позже, чем фрагмент-страницы-с-данными? Он вообще должен с 90% уже в клиентском кэше лежать. Или имеется в виду то, что не работает обработка json-formatted data при частичной загрузке?

Здравствуйте, Sinclair, Вы писали:

S>А, я-то думал что на одном конце сокет, а на другом — файл.
Так и получается, на самом деле

C>>В Линуксе это достаточно тривиальная операция. Кстати, с помощью BPF (Berkely Packet Filter — такая виртуальная машинка в ядре, с простым JIT) можно даже часть её перенести в kernelspace.
S>Не очень понял, что именно можно перенести в kernelspace? формирование выходной разметки, накладывая шаблон на результат выборки из базы?
Весь процесс splice'а данных, включая создание пайпов.

C>>Только вот в случае больших страниц (мегабайт, как ты сам привёл) обработка на мобильных устройствах занимает достаточно много времени и требует батарейку. Причём весьма так заметно.

S>Не очень понимаю, как так. Шаблон же сам по себе — это всего лишь кусок <tr></tr> с плейсхолдерами, условно говоря.
Смотри, при загрузке динамического контента мы имеем:

<body>
Hello, world!
<table>
<tr><td>This</td><td>is a test</td></tr>
//Затык на 10 секунд - мобильный инет тормозит

Браузер сразу покажет на дисплее "Hello, world!" и "This is a test", хотя ещё не всё загружено. В случае с клиентским шаблоном нужно загрузить ВЕСЬ шаблон и все данные (два отдельных запроса!), прежде чем на экране что-то появится.

S>Как он может загрузиться позже, чем фрагмент-страницы-с-данными? Он вообще должен с 90% уже в клиентском кэше лежать.
Клиентского кэша нет при первом (самом важном!) обращении к сайту. Вдобавок, в том же Хроме клиенсктий кэш — всего порядка 50Мб. Всего за пару дней оттуда данные исчезнут.

S>Или имеется в виду то, что не работает обработка json-formatted data при частичной загрузке?
Это тоже, кстати.