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

S>Масло масленое. Какие параметры подставляются в шаблон?

А зачем параметры? ) Вы вообще в курсе, что такое скажем jade и каковы его возможности? )

S>Ок, давайте сначала. Что именно у вас собирается отдавать шаблонизатор? Готовый маркап? Тот, который вместо 5 килобайт шаблона и 20 килобайт данных содержит 100 килобайт разметки? Или всё же он у вас отдаёт отдельно шаблон, отдельно данные?

В сравнение с отдачей статического шаблона из файла естественно сравнивался вариант с отдачей шаблона отдельно, потому как глупо сравнивать динамику (обращение в бд и т.п.) со статикой. Но в принципе vibe.d поддерживает оба описанных сценария. А так же ещё и промежуточные варианты, например когда мы отдаём в одной html странице шаблон + данные (в формате json скажем), которые потом визуализирует клиентский js фреймворк.

S>Ещё раз: Усложнения IIS по работе с кэшем позволяют ему порвать ваш шаблонизатор, даже если последний будет прогрет. Потому что он, в отличие от шаблонизатора, умеет хэндлить conditional get и partial requests.

Хыхы, идея выдача шаблонов html страниц с докачкой весьма феерична... )

S>Я не в курсе, что выбрано в D, подозреваю, что UCS-2 — в духе времени.

Строки в D — это всего лишь алиас к "immutable T[]", где T может быть char (utf8), wchar (utf16), dchar(utf32), по желанию. Впрочем для нашей дискуссии это действительно не принципиально.

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

_>В сравнение с отдачей статического шаблона из файла естественно сравнивался вариант с отдачей шаблона отдельно, потому как глупо сравнивать динамику (обращение в бд и т.п.) со статикой. Но в принципе vibe.d поддерживает оба описанных сценария. А так же ещё и промежуточные варианты, например когда мы отдаём в одной html странице шаблон + данные (в формате json скажем), которые потом визуализирует клиентский js фреймворк.
Ок. И в каком из этих вариантов vibe.d собрался порвать и кого?

_>Хыхы, идея выдача шаблонов html страниц с докачкой весьма феерична... )
Ну, то есть про conditional get вам сказать нечего. Понятно.

_>Строки в D — это всего лишь алиас к "immutable T[]", где T может быть char (utf8), wchar (utf16), dchar(utf32), по желанию. Впрочем для нашей дискуссии это действительно не принципиально.
А как это выглядит в реальности? Можно мне показать пример статически скомпилированного шаблона, который порождает html-маркап на vibe.d?

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

S>Нет, не в курсе. Жду, пока вы мне это расскажете. Пока что звучит как "генерация шаблонов по шаблонам", и хочется понять, чем вызван этот 2й уровень косвенности.

Кроме просто удобства (автоматической корректности html, намного более ясного синтаксиса и т.п.) jade и ему подобные включают ещё и множество дополнительных возможностей по сравнению с html. Причём речь даже не о банальном императивном исполнение произвольного кода (хотя понятно какие возможности следуют из этого), а скажем о таких вещах как import. Например мы можем сделать некий шаблон common, в котором определим стандартные для всех страниц вещи (шапку, меню и т.п.), а потом использовать его во всех остальных шаблонах (конкретных страниц). Думаю программисту сразу должны быть очевидны преимущества такого инструмента, по сравнению с ручным набором отдельных html. Остальное можно глянуть например здесь http://jade-lang.com.

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

S>Ок. И в каком из этих вариантов vibe.d собрался порвать и кого?

Ну вы прицепились к фразе о вполне конкретном варианте. )))

S>Ну, то есть про conditional get вам сказать нечего. Понятно.

Хы, ну 304 для файлов vibe.d тоже умеет отдавать. )))

S>А как это выглядит в реальности? Можно мне показать пример статически скомпилированного шаблона, который порождает html-маркап на vibe.d?

Вот тут http://www.rsdn.ru/forum/philosophy/5693523

Автор: alex_public
Дата: 15.07.14

я уже показывал пример, правда на jade. На vibe.d будет всё тоже самое, но только язык D вместо JavaScript. Если же интересуют нюансы конкретно с D, то можно глянуть здесь http://vibed.org/templates/diet.

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

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


Ты никак не можешь дать простой ответ на один простой вопрос — что именно отдаётся в твоём случае. Вместо этого ты силишься дать всеобъемлющий ответ: "можно по-всякому..."
Если ты по шаблону генеришь шаблоны, то возникает естественный вопрос, откуда берутся все необходимые данные для для обработки конкретного реквеста.

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

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

У тебя ничего дополняющего нет, ты отдаёшь динамику пополам со статикой. Стало быть в CDN твоё решение не влезет.

Если ты генерируешь ангуляровский шаблон по jade шаблону, то я боюсь ты делаешь двойную работу и собираешь все недостатки как серверной обработки шаблонов, так и клиентской.
Во первых, CDN и прочие отптимизации тебе не помогут, т.к. твои шаблоны суть динамика. Во вторых, задержка времени отклика тупо увеличивается из за того, что контент должен будет процесситься еще и на клиенте.

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

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

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

Ты вероятно не понял — epub уже архив, его не надо клать еще в один архив. Второе — для веб-интерфейса его придется распаковать на сервере, хотя бы для того, что бы отдать нужную юзеру страницу. После распаковки спокойно можно отдавать статику, а тебе что бы "из архивов отдавать" придется переключаться между user/kernel по сотню раз на сессию.

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

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

И что мы видим на твоей картинке ? Бесплатное решение уровня "на коленке" более популярно, чем высокотехнологичное качественное и дорогое . Выйди на улицу и посмотри, сколько там серьёзных автомобилей, что бы современная конструкция, технологии, качественная сборка и тд и тд. Единицы процентов.

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

S>>Нет, не в курсе. Жду, пока вы мне это расскажете. Пока что звучит как "генерация шаблонов по шаблонам", и хочется понять, чем вызван этот 2й уровень косвенности.

_>Кроме просто удобства (автоматической корректности html, намного более ясного синтаксиса и т.п.) jade и ему подобные включают ещё и множество дополнительных возможностей по сравнению с html. Причём речь даже не о банальном императивном исполнение произвольного кода (хотя понятно какие возможности следуют из этого), а скажем о таких вещах как import. Например мы можем сделать некий шаблон common, в котором определим стандартные для всех страниц вещи (шапку, меню и т.п.), а потом использовать его во всех остальных шаблонах (конкретных страниц). Думаю программисту сразу должны быть очевидны преимущества такого инструмента, по сравнению с ручным набором отдельных html. Остальное можно глянуть например здесь http://jade-lang.com.

Ты внятно скажи,
1 какую это проблему решает и почему вот такую хрень нельзя сделать на ангуляре.
2 откуда берутся параметры для обработки конкретного реквеста

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

"Войны — не объявлять, мира — не подписывать, армию — распустить" @

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

S>>Тогда почему вы называете их "js", если они html?

_>Потому что они потом используются из клиентских js фреймворков в качестве шаблонов.

И тем не менее это html.

S>>Продолжаю непонимать — в чём тут роль серверного шаблонизатора?

_>Эээ, он их генерирует? )

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

_>Ну так эти несколько строк и не задумывались как конкурент nginx'у на рынке. )))

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

S>>Ну, тогда не стоит рассчитывать, что он хоть кого-то порвёт на отдаче статики.
_>А тут кто-то предлагал vibe.d для отдачи файлов с диска? )

Ты и предлагаешь, толко передёргиваешь. Речи ведь не было про "файлы с диска". Речь была про статику. Скажем, IIS можешь вообще даже и не видеть реквестов на статику, они все обработаются через тот же CDN.

S>>У шаблонизатора будет примерно столько же случаев непрогретого кэша и промахов.

_>С чего это? После загрузки приложения в память у него будет стабильное время выдачи результата.

А длину и качество пути до сервера надо учитывать или как ?

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

S>>У шаблонизатора будет примерно столько же случаев непрогретого кэша и промахов.

_>С чего это? После загрузки приложения в память у него будет стабильное время выдачи результата.

Кстати говоря, "загрузки приложения в память" в 99% случаев никогда не будет. Даже если ты принудительно запретишь своп, виртуальная память на этом не закончится — система мапит страницы прямо на исполнительные бинарники. Придется сделать многократный запас оперативной памяти на сервере.

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

В итоге тебе понадобится один адский сервер, на котором будет крутиться один единственный сайт. Чуть что поменял, добавил — твоё приложение будет вытесняться в своп.

Итого, твоё приложения при всех недостатках серверной генерации шаблонов будет обходиться дороже, чем десяток деплойментов IIS.

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

_>Нет, основой является совсем не это, а связь между функциями и данными (даже не типами, а экземплярами данных!), с которыми они работают.

Что за "связь между функциями и данными", да еще такая, которой нет в хаскеле и каким образом это является основой UML-диаграмм?

_>А зачем требуется какое-то специальное преобразование, если можно изначально писать писать эффективную однопроходную реализацию (как сделано в тех же диапазонах D). Причём никакой чистоты для этого не требуется.

Да, я уже понял, что вам оптимизации не нужны и даже написал об этом:

4) В конце концов выяснилось что оптимизации не нужны, потому что комбинации комбинаторов вы никогда не используете. <..>
С учетом этого опыта, я могу только констатировать что ничего ни доказать, ни продемонстрировать я вам не смогу.

Но не у всех такие скромные потребности.

_>Или же подразумевается, что компоновщик/компилятор сможет взять произвольную чужую функцию типа FilterXXX(array, pure func) с циклом по array внутри и как-то интегрировать её внутрь цикла допустим внутри map'a? ) Если так, то это конечно довольно интересно, но я пока о таком не слышал.
Программист на высокоуровневом языке не пишет какие-то "FilterXXX(array, pure func) с циклом по array внутри" а комбинирует комбинаторы. Именно на такой подход такие системы оптимизации и рассчитаны в первую очередь. Оптимизации, естественно, работают с "чужими функциями" тоже, если они соответствуют некоторым требованиям. Система оптимизации для списков в стандартной библиотеке foldr/build-fusion требует для того чтоб функция была хорошим консьюмером и продьюсером написания функции с использованием функций foldr и build. В случае stream-fusion из пакета vector можно писать обычные функции работающие с итераторами.
Такой вот filter

filter f (Stream step s n) = Stream step' s (toMax n) where
    step' s = case step s of
                Yield x s' | f x       -> Yield x s'
                           | otherwise -> Skip    s'
                Skip    s'             -> Skip    s'
                Done                   -> Done

будет "интегрирован внутрь цикла" вот такого map

map f (Stream step s n) = Stream step' s n where
    step' s = case step s of
                Yield x s' -> Yield (f x) s'
                Skip    s' -> Skip        s'
                Done       -> Done

в результате оптимизаций общего назначения. тут требование заключается в том, чтоб "итератор"

data Step s a = Yield a s
              | Skip    s
              | Done

был нерекурсивным АлгТД.

_>"Пока нет" — это справедливо. ) Я кстати даже не уверен, что это "пока" когда-нибудь исправится, т.к. что-то не очень много желающих заниматься этим направлением. Но главное то, что теоретическая возможность вполне есть, причём без всяких ужасных ограничений на язык (типа хаскельских). О чём я собственно и говорил.

Каким образом аннотации эффектов являются "ужасным ограничением", а аннотации чистоты — нет?

_>А как насчёт таких http://www.rsdn.ru/forum/philosophy/5676154

Автор: alex_public
Дата: 06.07.14

? )

Ну или один конвейер на всю программу как тут.

_>Ну так вы не правильно статистически обрабатываете — не учитываете, что отклонение измерения от истинного значения идёт только в одну сторону. )

Если речь идет о сотых секунды то нет, не в одну. Что я, вроде бы, понятно объяснил. Если бы речь шла о секундах — да, можно считать, что в одну.

_>я же исключительно практик, а не теоретик, играющийся с маргинальными языками.

Каким образом тогда оказалось, что вы знаете D?

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

_>Вообще то в том моём коде по сути используется своеобразный аналог функции realloc из C.

Каким образом это противоречит тому, что у вас аллокации "виртуальные"?

_>Так вот если заменить его на просто alloc, то по сути ничего не изменится.

Конечно изменится.

_>Просто ручной, а не автоматической.

Вот именно. "Ручная оптимизация" упрощенно говоря везде есть. А вы заявляете некую "поддержку".

_>Ну так про отсутствие в D готовых библиотек подобной оптимизации мы уже говорили, но как видно, их написание не представляет вообще никакого труда.

Это точно — потому их никто и не делает. Для программиста написание библиотек, которые никакого труда не требуют — оскорбительно, никто за такое не возьмется.

_>Я уже не раз повторял: область памяти, на которую ссылается такой объект является абсолютно неизменной всё время жизни объекта.

Конечно нет.

    auto a = IArray!(10, int).Make()~1~2~3;
    auto a1 = a~4;
    auto a2 = a~5;

    a1[].writeln;
    a2[].writeln;

выдаст

[1, 2, 3, 5]
[1, 2, 3, 5]

_>Почему вы ставите "в ответственность" такому объекту изменение памяти следующей непосредственно за его блоком, мне не понятно.

Постарайтесь понять.

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

K>Что за "связь между функциями и данными", да еще такая, которой нет в хаскеле и каким образом это является основой UML-диаграмм?

Так это же объединение функций и данных в рамках одного класса (в uml это соответственно выражается, как рисование их внутри одного прямоугольника). И это не основа всего uml, а основа ООП и соответственно основа диаграммы классов uml.

K>Да, я уже понял, что вам оптимизации не нужны и даже написал об этом:
K>Но не у всех такие скромные потребности.

Ну если написание уже оптимизированного кода не требует вообще никаких дополнительных усилий (например как в случае диапазонов D), то действительно зачем нам возможность писать неоптимизированный и потом ждать чудес от оптимизатора? )

K>Программист на высокоуровневом языке не пишет какие-то "FilterXXX(array, pure func) с циклом по array внутри" а комбинирует комбинаторы. Именно на такой подход такие системы оптимизации и рассчитаны в первую очередь. Оптимизации, естественно, работают с "чужими функциями" тоже, если они соответствуют некоторым требованиям. Система оптимизации для списков в стандартной библиотеке foldr/build-fusion требует для того чтоб функция была хорошим консьюмером и продьюсером написания функции с использованием функций foldr и build. В случае stream-fusion из пакета vector можно писать обычные функции работающие с итераторами.
K>Такой вот filter
K>

K>filter f (Stream step s n) = Stream step' s (toMax n) where
K>    step' s = case step s of
K>                Yield x s' | f x       -> Yield x s'
K>                           | otherwise -> Skip    s'
K>                Skip    s'             -> Skip    s'
K>                Done                   -> Done
K>

K>будет "интегрирован внутрь цикла" вот такого map
K>

K>map f (Stream step s n) = Stream step' s n where
K>    step' s = case step s of
K>                Yield x s' -> Yield (f x) s'
K>                Skip    s' -> Skip        s'
K>                Done       -> Done
K>

K>в результате оптимизаций общего назначения. тут требование заключается в том, чтоб "итератор"
K>

K>data Step s a = Yield a s
K>              | Skip    s
K>              | Done
K>

K>был нерекурсивным АлгТД.

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

K>Каким образом аннотации эффектов являются "ужасным ограничением", а аннотации чистоты — нет?

Вы так и не поняли? ) Ключевой вопрос не в разновидностях синтаксиса (в конце концов у всех разные вкусы и на планете полно поклонников и java стиля и perl стиля), а в обязательности ограничений. Ключевой подход C++ заключается в том, что мы используем только те возможности языка (включая и различные варианты ограничений и самоконтроля), которые выбираем сами. Причём остальное совершенно не мешает нам жить, если мы его не трогаем. Этого же принципа во многом придерживаются и другие приятные мне языки, типа Питона или D, а вот Хаскель его существенно нарушает.

_>>А как насчёт таких http://www.rsdn.ru/forum/philosophy/5676154

Автор: alex_public
Дата: 06.07.14

? )
K>Ну или один конвейер на всю программу как тут.

Так больше и не лезет в подобное приложение. )))

K>Если речь идет о сотых секунды то нет, не в одну. Что я, вроде бы, понятно объяснил. Если бы речь шла о секундах — да, можно считать, что в одну.

Эээ, где было объяснение такого интересного факта, как отклонение измерения времени работы алгоритма в меньшую сторону от истинного? )

_>>я же исключительно практик, а не теоретик, играющийся с маргинальными языками.
K>Каким образом тогда оказалось, что вы знаете D?

А причём тут знание языка? Я их много разных знаю и значительную часть явно можно назвать маргинальными. Однако я не использую их в каких-то серьёзных проектах. Как впрочем и D пока что. Хотя надеюсь, что когда-нибудь он всё же встанет на одну ступень с C/C++.

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

_>>Так вот если заменить его на просто alloc, то по сути ничего не изменится.
K>Конечно изменится.

Снаружи ничего не изменится, кроме быстродействия естественно. )

K>Вот именно. "Ручная оптимизация" упрощенно говоря везде есть. А вы заявляете некую "поддержку".

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

_>>Ну так про отсутствие в D готовых библиотек подобной оптимизации мы уже говорили, но как видно, их написание не представляет вообще никакого труда.
K>Это точно — потому их никто и не делает. Для программиста написание библиотек, которые никакого труда не требуют — оскорбительно, никто за такое не возьмется.

Видимо не особо интересно это практикам... А D написан как раз матёрым практиками по C++ для себя.

K>Конечно нет.

K>

K>    auto a = IArray!(10, int).Make()~1~2~3;
K>    auto a1 = a~4;
K>    auto a2 = a~5;

K>    a1[].writeln;
K>    a2[].writeln;
K>

K>выдаст
K>

K>[1, 2, 3, 5]
K>[1, 2, 3, 5]
K>

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

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

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

I>Ты никак не можешь дать простой ответ на один простой вопрос — что именно отдаётся в твоём случае. Вместо этого ты силишься дать всеобъемлющий ответ: "можно по-всякому..."
I>Если ты по шаблону генеришь шаблоны, то возникает естественный вопрос, откуда берутся все необходимые данные для для обработки конкретного реквеста.

В каком это "моём случае"? ) Мы говорим про какой-то конкретный мой проект или же просто про vibe.d? ) Мне казалось что про последнее. И в таком случае ответ "можно по-всякому" является абсолютно точным.

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

I>Ты вероятно не понял — epub уже архив, его не надо клать еще в один архив. Второе — для веб-интерфейса его придется распаковать на сервере, хотя бы для того, что бы отдать нужную юзеру страницу. После распаковки спокойно можно отдавать статику, а тебе что бы "из архивов отдавать" придется переключаться между user/kernel по сотню раз на сессию.

Всё равно не понял какие варианты ты сравниваешь. Опиши подробно обе сравниваемые архитектуры.

I>И что мы видим на твоей картинке ? Бесплатное решение уровня "на коленке" более популярно, чем высокотехнологичное качественное и дорогое . Выйди на улицу и посмотри, сколько там серьёзных автомобилей, что бы современная конструкция, технологии, качественная сборка и тд и тд. Единицы процентов.

IIS — это не дорогое и качественное, а скорее такой средний класс. ) А дорогое — это кастомый продукт, разработанный профи, типа как у гугла. Так вот наш средний класс что-то падает, а nginx (интересно какая у него аналогия из мира авто, самодельный спорткар?) наоборот растёт...

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

I>Ты внятно скажи,
I>1 какую это проблему решает и почему вот такую хрень нельзя сделать на ангуляре.

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

Что касается angular'a, то с помощью него такое в принципе не реализуемо, т.к. у него совсем другая архитектура. Так что в случае пожелания совмещения подобных техник, придётся строить своеобразный конвейер по загрузке и обработке. В начале некий препроцессор грузит набор (там же не 1 в 1 преобразуется) исходников, а потом полученные html шаблоны поступают на вход angular'а.

I>2 откуда берутся параметры для обработки конкретного реквеста

Что такое "параметры для обработки конкретного реквеста"?

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

_>>Ну так эти несколько строк и не задумывались как конкурент nginx'у на рынке. )))
I>Если ты сказал это хорошо подумав, то должен понимать, что нгинкс уступает IIS в части отдачи статики, а твое решение стало быть, уступае даже нгинксу.

Причём тут моё решение какое-то? ) Ты вообще читаешь на что отвечаешь? ))) Там речь шла про несколько строк на Питоне от Cyberax.

_>>А тут кто-то предлагал vibe.d для отдачи файлов с диска? )
I>Ты и предлагаешь, толко передёргиваешь. Речи ведь не было про "файлы с диска". Речь была про статику. Скажем, IIS можешь вообще даже и не видеть реквестов на статику, они все обработаются через тот же CDN.

Ну так о том и речь, что vibe.d умеет отдавать статические html через шаблонизатор даже быстрее, чем будет их отдавать с диска обычный сервер.

Да, кстати, и с чего ты взял, что эти данные нельзя кэшировать далее? ) Вообще то управление кэшированием находится под полным упралением программиста в vibe.d. Как укажешь, так и будет.

I>А длину и качество пути до сервера надо учитывать или как ?

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

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

I>Кстати говоря, "загрузки приложения в память" в 99% случаев никогда не будет. Даже если ты принудительно запретишь своп, виртуальная память на этом не закончится — система мапит страницы прямо на исполнительные бинарники. Придется сделать многократный запас оперативной памяти на сервере.

Бред какой-то ты написал. ) Да, изначально приложение не загружено полностью, но после разового исполнения уже будет всё нормально. Полный аналог "прогрева кэша" у обычных серверов. Только вот у них там другой алгоритм несколько — не каждый запрос и не обязательно с первого раза попадает в кэш.

I>Что бы получить эту самую "загрузку приложения в память", надо кроме отключения свопа запретить все остальные приложения, модули, демоны и тд и тд и тд. Аккуратно использовать динамическую памяти, ничего не хранить локально, ни в каком виде. В противном случае ты будешь получать косяки с кешем.

Вообще какие-то потоки бреда. )))

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

Ну собственно да, один сервер под одного такого демона. Только вот хватает при этом самого дохлого vps, хотя при обычных технологиях такой сервер не держит больше десятка клиентов. )))

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

_>Бред какой-то ты написал. ) Да, изначально приложение не загружено полностью, но после разового исполнения уже будет всё нормально. Полный аналог "прогрева кэша" у обычных серверов. Только вот у них там другой алгоритм несколько — не каждый запрос и не обязательно с первого раза попадает в кэш.

Не будет "всё нормально". Хоть в виндовсе, хоть в линуксе, крайне сложно заставить систему отказаться от свопа. О чем, собственно, и сообщают тулы.

I>>Что бы получить эту самую "загрузку приложения в память", надо кроме отключения свопа запретить все остальные приложения, модули, демоны и тд и тд и тд. Аккуратно использовать динамическую памяти, ничего не хранить локально, ни в каком виде. В противном случае ты будешь получать косяки с кешем.

_>Вообще какие-то потоки бреда. )))

У тебя вероятно RAM исчисляется терабайтами. Это объясняет, почему тебе не понятно, что такое своп.

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

_>Ну собственно да, один сервер под одного такого демона. Только вот хватает при этом самого дохлого vps, хотя при обычных технологиях такой сервер не держит больше десятка клиентов. )))

Приехали — виртуальный хостинг означает, что физическую память разделяют
1 целая куча других экземпляров VPS — иначе нет смысла подымать VPS
2 хостовая операционная система

Для твоего сайта должно быть выделено достаточно большое количество страниц физической памяти. Вероятность такого исхода стремится к нулю — именно из за vps.

Проблемы со свопом только усугубляются. Без нагрузки все шоколадно. А под нагрузкой все еще хуже, чем под обычным физическим сервером.
Что характерно, под нагрузкой в первую очередь и очень сильно страдает именно latency, про который мы все время и говорим.

Более того — совершенно не важно, кто будет источником нагрузки, твое приложение или приложение на другом vps на том же железе.

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

_>>>А тут кто-то предлагал vibe.d для отдачи файлов с диска? )
I>>Ты и предлагаешь, толко передёргиваешь. Речи ведь не было про "файлы с диска". Речь была про статику. Скажем, IIS можешь вообще даже и не видеть реквестов на статику, они все обработаются через тот же CDN.

_>Ну так о том и речь, что vibe.d умеет отдавать статические html через шаблонизатор даже быстрее, чем будет их отдавать с диска обычный сервер.

Объясняю еще раз — речь не про отдачу файлов. Речь про отдачу статики.

В моей схеме сервер может вообще _не_ отдавать статику. За счет оптимизаций время обработки запроса стремится к нулю справа.

В твоем случае такого нет и быть не может, потому, что твоя статика на самом деле динамика. Из этого следуеют что тот же CDN в твоём случае невозможен.

_>Да, кстати, и с чего ты взял, что эти данные нельзя кэшировать далее? ) Вообще то управление кэшированием находится под полным упралением программиста в vibe.d. Как укажешь, так и будет.

Я хочу что бы статика кешировалась вне моего сервера. То есть — вообще. Желательно поближе к клиенту и если можно то и вообще прямо на нём. Это очевидно — ангуляр конкретной версии никогда не экспайрится, в отличие от твоих темплейтов. А это значит, что его в 100% случае можно отдавать вообще как угодно, через тот же CDN который гарантировано быстрее любого процессинга на vide.d

I>>А длину и качество пути до сервера надо учитывать или как ?

_>Кстати, если уж тебе так нравятся решения с клиентскими шаблонами...

Я скипнул — ответь прямо на заданый вопрос. Повторяю — надо ли учитывать длину и качество пути от клиента на сервер и обратно ?

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

I>>Ты внятно скажи,
I>>1 какую это проблему решает и почему вот такую хрень нельзя сделать на ангуляре.

_>В принципе подобное вполне реализуемо на основе клиентских js скриптов. Но я навскидку не могу вспомнить таких готовых решений. Возможно их даже и нет, хотя теоретически не вижу каких-то принципиальных препятствий.

Вообще от ангуляр весь целиком именно про это.

_>Что касается angular'a, то с помощью него такое в принципе не реализуемо, т.к. у него совсем другая архитектура. Так что в случае пожелания совмещения подобных техник, придётся строить своеобразный конвейер по загрузке и обработке. В начале некий препроцессор грузит набор (там же не 1 в 1 преобразуется) исходников, а потом полученные html шаблоны поступают на вход angular'а.

Алё — задача показать общие для всех страниц элементы — футеры, меню и прочие вещи. Это делается легко и просто. Директивы ангуляра творят чудеса.

I>>2 откуда берутся параметры для обработки конкретного реквеста
_>Что такое "параметры для обработки конкретного реквеста"?

Обычно это юзерские данные всех возможных сортов.