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

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

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

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

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

IIS это и есть дорогое и качественное. На ём реализуются высоконагруженые решения.

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

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

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

Это уже позже ты решил увиливать и притягивать все возможные и невозможные баззворды.

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

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

Группировка "внутри одного прямоугольника" определяется архитектурными соображениями. Соответствует ли ей связь а-ля симула-ООП — деталь реализации языка, к архитектуре и UML никакого значения не имеющая.

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

Это фантастика.

_>(например как в случае диапазонов D)

Как мы узнали из опыта, в случае диапазонов D оптимизации не сработали и вам пришлось конвейер переписать в потрясающую строчку

p.find!(q{b%a==0||a^^2>b})(v).front()^^2>v

умопомрачительной читаемости.

_>то действительно зачем нам возможность писать неоптимизированный и потом ждать чудес от оптимизатора? )

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

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

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

_>И в чём тогда принципиальное отличие от такой же оптимизации диапазонов D?

В том, что в хаскеле оптимизация работает, а в Ди — нет. Это довольно важное отличие.

_>Там тоже всё отлично работает, в том числе и для пользовательских функций (написанных в соответствие с техникой диапазонов)

В обсуждаемом примере не работает.

_>и при этом без всяких требований чистоты.

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

_>Вы так и не поняли? ) Ключевой вопрос не в разновидностях синтаксиса (в конце концов у всех разные вкусы и на планете полно поклонников и java стиля и perl стиля), а в обязательности ограничений.

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

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

Поэтому никакие нормальные возможности для выбора в C++ и не доступны, только недоделанные. Да, это закономерное следствие ключевого подхода "не используем не платим". Поскольку никаких нетривиальных возможностей не требующих платить в случае неиспользования не существует — никаких интересных возможностей и в C++ нет. В этом отличия между высокоуровневыми и низкоуровневыми языками и заключается.

_>Причём остальное совершенно не мешает нам жить, если мы его не трогаем.

Но если вдруг потрогаем, серьезно нам жить не поможет. Чудес не бывает.

_>Этого же принципа во многом придерживаются и другие приятные мне языки, типа Питона или D, а вот Хаскель его существенно нарушает.

Как раз скриптовые языки — чемпионы по предъявлению счетов за неиспользуемые возможности.

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

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

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

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

Если ваши часы обновляются раз в 0,02сек. то вроде бы очевидно, что измерение интервала времени по таким часам может быть меньше действительного примерно на 0,02сек. Вы когда-нибудь часами пользовались? Или линейкой?

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

Тогда не понятно. Если вы не "играющийся с маргинальными языками", то вроде бы это означает, что вы с маргинальными языками не играете. Где тут ошибка?

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

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

Изменится результат работы программы в моем примере.

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

Я же говорю, я понял, что иммутабельностью вы называете возможность кастить между двумя типами, один из которых вроде как иммутабельный (на самом деле нет). Такое достигается без переделки языка написанием/генерированием иммутабельных оберток для мутабельных классов.
Впрочем, если вы не видите принципиальной разницы между ручной и автоматической оптимизацией, удивительно видеть, как вы проводите разницу между ручной и автоматической проверкой (которую вы в демонстрируемых примерах сами же легко обходите).

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

Многим "матерым практикам по X" вообще ничего кроме обоснования ненужности отсутствующего в X отсутствием в X не интересно. Самопровозглашенные матерые практики они такие.

_>Хы, так речь же шла про конкретно тот код, а не про произвольное использование класса оттуда

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

_>Естественно, что если бы я решил выложить этот класс публично в виде библиотеки,

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

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

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

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

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

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

Я вам ее показал, но как обычно, вы в упор не видите то, что вам показывают. Впрочем, остается еще вариант, что вы под словами "точка мутабельности" понимаете что-то совершенно невообразимое.

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

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

А зачем отключать своп на сервере? )

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

И зачем мне терабайты для загрузки программы размером в несколько мегабайт? )

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

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

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

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

Очаровательно) Ты мне тут излагаешь свои теории, а я тебе рассказываю практику. Что всё отлично работает. Причём на таком же железе классическая конфигурация (LAMP) просто дохнет от малейшей нагрузки. Нормальная конфигурация (nginx + python и т.п.) в принципе работает, но при увеличение числа клиентов быстро начинает подтормаживать. А вот обсуждаемая штука спокойно летает даже на этой дохлой железке.

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

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

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

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

Почему не возможен то? ) Кэширование зависит от возвращаемых заголовков, а мы ими полностью управляем. )

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

Ну на клиенте, так на клиенте — всё в твоих руках.

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

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

Да, ну так и что у нас с обработкой поисковыми машинами чисто ajax'ых страниц? )

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

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

Ну покажи пример. )

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

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

ОК, тогда опиши подробно какую задачку надо решить и я скажу о вариантах на vibe.d.

I>IIS это и есть дорогое и качественное. На ём реализуются высоконагруженые решения.

Вот как раз в области высоконагруженных он существенно устипил nginx'у. Ещё год назад об это статья была подробная.

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

K>Группировка "внутри одного прямоугольника" определяется архитектурными соображениями. Соответствует ли ей связь а-ля симула-ООП — деталь реализации языка, к архитектуре и UML никакого значения не имеющая.

Т.е. всё снова сводится к тому, что вы предлагаете рисовать виртуальное ООП для Хаскеля. Мы же это уже обсуждали — мне уже как-то надоело ходить по кругу...

K>Как мы узнали из опыта, в случае диапазонов D оптимизации не сработали и вам пришлось конвейер переписать в потрясающую строчку
K>

K>p.find!(q{b%a==0||a^^2>b})(v).front()^^2>v
K>

K>умопомрачительной читаемости.

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

K>В том, что в хаскеле оптимизация работает, а в Ди — нет. Это довольно важное отличие.

С map'ми всё отлично работает, как вы уже видели. А то, что вам посчастливилось наткнуться на какую-то недоработка стандартной библиотеки D при первом же знакомстве с языком, — это конечно нестандартное "везение". )))

_>>и при этом без всяких требований чистоты.
K>Это означает, что в тех случаях, когда она работает (если такие есть) — преобразования некорректны в общем случае, и правильность кода остается на совести программиста. такой подход плохо масштабируется.

Фокус в том, что там нет каких-то преобразований, а есть стандартный подход, прописанный в документации. Кстати, тот же IEnumerable в C# хотя и заметно послабее, но тоже ведь из этой области...

_>>Вы так и не поняли? ) Ключевой вопрос не в разновидностях синтаксиса (в конце концов у всех разные вкусы и на планете полно поклонников и java стиля и perl стиля), а в обязательности ограничений.
K>Вы так и не поняли? ) Ключевой вопрос не в разновидностях синтаксиса, а в обязательности ограничений. Если ограничения не обязательны — то и возможности, которые основываются на таких ограничениях недоступны.

Ну вот здесь у нас с вами и находится принципиальное различие во взглядах. )

K>Поэтому никакие нормальные возможности для выбора в C++ и не доступны, только недоделанные. Да, это закономерное следствие ключевого подхода "не используем не платим". Поскольку никаких нетривиальных возможностей не требующих платить в случае неиспользования не существует — никаких интересных возможностей и в C++ нет. В этом отличия между высокоуровневыми и низкоуровневыми языками и заключается.

Да да. ) Только вот переход вверх возможен (написанием своего кода, подключением готового из библиотеки), а переход вниз обычно нет... )

_>>Причём остальное совершенно не мешает нам жить, если мы его не трогаем.
K>Но если вдруг потрогаем, серьезно нам жить не поможет. Чудес не бывает.

По разному бывает. Частенько требуется не просто использовать какую-то возможность языка, а подключить мощную библиотеку, которая в итоге существенно меняет язык. )

K>Любой цикл, который в вашем приложении, я уверен, не один может быть представлен как комбинация комбинаторов с улучшением читаемости. Вот только возможно такое при работающей в значительном числе случаев оптимизации.

Да, циклов много, но большая часть из них написана на спец. языке, компилируемом в simd инструкции.

K>Если ваши часы обновляются раз в 0,02сек. то вроде бы очевидно, что измерение интервала времени по таким часам может быть меньше действительного примерно на 0,02сек. Вы когда-нибудь часами пользовались? Или линейкой?

Ааа вы всё про это... Ну это же меньше процента погрешность. А ведь у вас перед усреднением разброс был существенно больше, не так ли? )

Да, и кстати на счёт 16 мс — это ещё не факт. Многий софт (включая например Хром) меняет это значение до 1 мс. Из-за чего как раз недавно были разборки, т.к. на мобильных устройствах это вызывало повышенный расход батареи.

K>Тогда не понятно. Если вы не "играющийся с маргинальными языками", то вроде бы это означает, что вы с маргинальными языками не играете. Где тут ошибка?

Не знаю что вам непонятно. ) Знать язык и использовать его — это абсолютно разные вещи. Знаю я много языков, использую в реальных проектах очень мало.

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

K>Я же говорю, я понял, что иммутабельностью вы называете возможность кастить между двумя типами, один из которых вроде как иммутабельный (на самом деле нет). Такое достигается без переделки языка написанием/генерированием иммутабельных оберток для мутабельных классов.
K>Впрочем, если вы не видите принципиальной разницы между ручной и автоматической оптимизацией, удивительно видеть, как вы проводите разницу между ручной и автоматической проверкой (которую вы в демонстрируемых примерах сами же легко обходите).

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

В этом смысле D занимает странное положение. По расширяемости он существенно превосходит и C++, но при этом в силу пока небольшого сообщества, библиотек на все случаи жизни пока нет. В то время как в C++ есть совершенно невероятные библиотеки на все случая жизни, которые выжимают из языка уже даже больше, чем он может дать.

K>Многим "матерым практикам по X" вообще ничего кроме обоснования ненужности отсутствующего в X отсутствием в X не интересно. Самопровозглашенные матерые практики они такие.

Я думаю что очень многие программисты мечтали бы иметь такую репутацию, как авторы D. )

K>Речь шла про иммутабельность структуры данных. Естественно, для любой мутабельной структуры данных можно написать код, в котором ее мутабельность не наблюдается. Это очень просто, например такой вот код "" не содержит наблюдаемых изменений любой возможной мутабельной структуры данных на почти любом языке.
K>При таком подходе разницы между мутабельными и иммутабельными структурами действительно нет, поздравляю.

О, наконец то вы это осознали. )

K>Вы его публично выложили на форум в качестве якобы "иммутабельной" структуры данных.
K>При этом не понятно, зачем там вообще все эти приседания с immutable.

Кстати говоря в D immutable имеет важный смысл при работе с многопоточностью в D.

K>Я вам ее показал, но как обычно, вы в упор не видите то, что вам показывают. Впрочем, остается еще вариант, что вы под словами "точка мутабельности" понимаете что-то совершенно невообразимое.

Если признать вашу логику, то тогда любые данные в любых языках выделенные не с помощью прямого вызова VirtualAlloc не могут быть иммутабельными. )

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

_>И зачем мне терабайты для загрузки программы размером в несколько мегабайт? )
Опять про белого бычка. Если у вас вся статика отдаётся программой размером в несколько мегабайт, то и аналогичный набор статических файлов будет весить несколько мегабайт, и будет отдаваться в худшем случае из кэша ФС. А в хорошем случае он будет отдаваться сразу из kernel-кэша. Поэтому ваша "программа" никого никогда не порвёт.

_>Очаровательно) Ты мне тут излагаешь свои теории, а я тебе рассказываю практику. Что всё отлично работает. Причём на таком же железе классическая конфигурация (LAMP) просто дохнет от малейшей нагрузки.
Классическая конфигурация — это гарантированный тормоз, т.к. в ней участвуют одновременно самый неэффективный HTTP-демон и самый неэффективный скриптовый движок.

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

S>Опять про белого бычка. Если у вас вся статика отдаётся программой размером в несколько мегабайт, то и аналогичный набор статических файлов будет весить несколько мегабайт, и будет отдаваться в худшем случае из кэша ФС. А в хорошем случае он будет отдаваться сразу из kernel-кэша. Поэтому ваша "программа" никого никогда не порвёт.

Да на этой машине Windows Server с IIS вообще наверное не запустятся. )))

S>Классическая конфигурация — это гарантированный тормоз, т.к. в ней участвуют одновременно самый неэффективный HTTP-демон и самый неэффективный скриптовый движок.

А никто и не спорит, но тестировали не только его. )

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

_>Да на этой машине Windows Server с IIS вообще наверное не запустятся. )))
Характеристики — в студию.

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

S>Характеристики — в студию.

http://www.hetzner.de/en/hosting/produkte_vserver/vq7 такого типа. )

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

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

_>ОК, тогда опиши подробно какую задачку надо решить и я скажу о вариантах на vibe.d.

Да вроде все понятно — есть N книг в формате навроде epub на сервере. Нужен веб-интерфейс для чтения. Заодно покажи куда ты приспособишь генерацию темплейтов по темплейтам.

_>Вот как раз в области высоконагруженных он существенно устипил nginx'у. Ещё год назад об это статья была подробная.

Пудозреваю дело было не в нагрузке а в стоимости решения. Есть ссылка ?

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

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

_>Ну покажи пример. )

<megafooter />

В коде директивы megafooter пишешь джаваскриптовый код, который делает все что тебе нужно — т.е. выставляет нужную тебе разметку.

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

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

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

Ты вероятно, не понял — CDN означает, что реквесты на статику вообще никогда, ни разу не придукт к твоему серверу. Так понятно ?

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

_>Ну на клиенте, так на клиенте — всё в твоих руках.

У тебя какая то военная технология — отдавать статику с CDN при этом генерить её будет твой сервер по каждому запросу. В реальном мире или одно или другое.

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

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

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



_>Да, ну так и что у нас с обработкой поисковыми машинами чисто ajax'ых страниц? )

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

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

_>А зачем отключать своп на сервере? )

Затем, что работа со свопом стоит очень дорого — 1-15мс на кластер данных. Есть только один способ избавиться от этой задержки — держать вообще всё в памяти. Для среднего веб-приложения это 4-8гб памяти, включая все необходимые функции OS.

Нет разницы между чтением из файла и подкачкой из свопа. То есть — вообще.

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

_>И зачем мне терабайты для загрузки программы размером в несколько мегабайт? )

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

Что бы исключить обращения к диску, всю эту кухню надо держать в RAM, а не в свопе.

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

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

_>Очаровательно) Ты мне тут излагаешь свои теории, а я тебе рассказываю практику. Что всё отлично работает.

Работает, но не так как ты думаешь. У всех виртуальных серверов большие проблемы с временем отклика.

>Причём на таком же железе классическая конфигурация (LAMP) просто дохнет от малейшей нагрузки. Нормальная конфигурация (nginx + python и т.п.) в принципе работает, но при увеличение числа клиентов быстро начинает подтормаживать. А вот обсуждаемая штука спокойно летает даже на этой дохлой железке.

Это чушь. Ты путаешь железо физическое и виртуальное. vps не ставится на дохлое железо. А вот виртуальное железо на таком сервере может быть очень даже дохлым и дешовым.
Скорость работы получается адекватная не потому, что клауд, а потому, что физический хост обеспечивает адскую производительность.

vps нужен всего лишь для того, что бы железо не простаивало и можно было приложения изолировать друг от друга. Делается это за счет распыления ресурсов.

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

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

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

_>Очаровательно) Ты мне тут излагаешь свои теории, а я тебе рассказываю практику. Что всё отлично работает. Причём на таком же железе классическая конфигурация (LAMP) просто дохнет от малейшей нагрузки. Нормальная конфигурация (nginx + python и т.п.) в принципе работает, но при увеличение числа клиентов быстро начинает подтормаживать. А вот обсуждаемая штука спокойно летает даже на этой дохлой железке.

Мне сразу вспомнился спор с выпускником гуманитарного техникума. Он утверждал, что Pentium 100 работает под виртуалкой быстрее, чем его PII, раза в три. При этом он забыл уточнить, что виртуалка, где был Pentium 100 работала на PIV.

Похоже, тебя всерьез заинтересовали идеи таких гуманитарщиков.

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

_>>Очаровательно) Ты мне тут излагаешь свои теории, а я тебе рассказываю практику. Что всё отлично работает. Причём на таком же железе классическая конфигурация (LAMP) просто дохнет от малейшей нагрузки.
S>Классическая конфигурация — это гарантированный тормоз, т.к. в ней участвуют одновременно самый неэффективный HTTP-демон и самый неэффективный скриптовый движок.

Не, он про другое — он про магию клауда. Типа — если сайт тормозит на домашнем железе, то купив такое же железо, но VPS, сайт резко начнет летать. Товарищ почему то не в курсе, что хостовое железо на порядок быстрее любого из VPS что на нём крутятся.