На счёт профита я бы не сказал. Есть же ещё code reuse и, для кого-то, привычность самого языка. Пожалуй единственное, почему на Node.js пока не написали CMS или что-то подобное — лень и большое количество уже написанных движков необходимость в нормальном хостинге.
Постарался описать, почему от разрыва в основном потоке выполнения может получиться преимущество и увеличение RPS. Возможно, иллюстрации, которые я сейчас делаю, помогут в этом убедиться или наоборот придумать убедительные аргументы против моей точки зрения.
Вторые должны разруливаться асинхронными вызовами — ну это одна из задач ноды.
Тут есть одна «проблема»: libeio справится с асинхронным чтением, но для этого нужно, чтобы из основного потока поступил запрос на начало чтения. А если будет длительная (но не настолько длительная, чтобы использовать другую архитектуру) обработка файла для первого запроса, то когда бы не пришёл второй запрос, ему придётся ждать пока обработка завершится и только после этого в основном потоке начнётся его обработка и отправка запроса для libeio для асинхронного чтения. А если обработка будет разбита на отдельные кусочки с process.nextTick() между ними, то в эту обработку может вклиниться первичное получение HTTP-запроса и запрос на асинхронное чтение. За счёт этого суммарное время обслуживания первого запроса увеличится на небольшое время принятия второго HTTP-запроса, тогда как суммарное время обслуживания второго запроса уменьшится за счёт того, что асинхронное чтение начнётся раньше.
Вы однозначно правы в том, что здесь не стоит делать категоричных заявлений о преимуществах того или иного кода. Уж слишком много факторов, влияющих на результат: размеры и диапазон размеров файлов, время обработки и его возможная нелинейная зависимость от размера файла, частота запросов и размера пула потоков в libeio. Я постараюсь в ближайшее время нарисовать «планы обработки» запросов для примеров из этого топика и различных вариантов «взаимного расположения» поступающих запросов, судя по моим наброскам они намного нагляднее и понятнее. Возможно мы сойдёмся на промежуточной точке зрения :)
Согласен, нужно провести такой тест с множеством файлов. Для равномерного распределения применения не могу придумать, а случай с нормальным распределением вокруг какого-то значение подойдёт для моделирования сервиса потоковой обработки изображений.
Также видится зависимость от времени обработки, видимо выберу последние два-три варианта кода из четырёх и буду строить диаграмму в зависимости от времени обработки.
Мне, к сожалению, не хватает практического опыта для того, чтобы придумать качественный пример для тестирования :(
> Но, конечно, это работает только для серверов с активным вводом/выводом.
> Время максимальной блокировки определяется самым тяжелым вычислением.
Об этом я и говорю. Если основную часть времени занимает чтение, то это даст прирост, если вычисление длинные — прироста не будет. Само собой ничего не бывает, но в среднем от лишнего прерывания отзывчивость сервера увеличится, особенно если есть запросы с различным временем обработки. Я думаю провести тест в таких условиях в ближайшее время, надеюсь что всё подтвердится.
Есть, правда, другой вопрос: а не проще ли создать несколько процессов и в каждом обрабатывать запросы синхронно.
За счёт того, что при наличии такого промежутка в вычислениях в него может попасть начало асинхронного чтения, а значит чтение произойдёт раньше и возрастёт отзывчивость. Но, конечно, это работает только для серверов с активным вводом/выводом.
лень и большое количество уже написанных движковнеобходимость в нормальном хостинге.Уже.
Тут есть одна «проблема»: libeio справится с асинхронным чтением, но для этого нужно, чтобы из основного потока поступил запрос на начало чтения. А если будет длительная (но не настолько длительная, чтобы использовать другую архитектуру) обработка файла для первого запроса, то когда бы не пришёл второй запрос, ему придётся ждать пока обработка завершится и только после этого в основном потоке начнётся его обработка и отправка запроса для libeio для асинхронного чтения. А если обработка будет разбита на отдельные кусочки с process.nextTick() между ними, то в эту обработку может вклиниться первичное получение HTTP-запроса и запрос на асинхронное чтение. За счёт этого суммарное время обслуживания первого запроса увеличится на небольшое время принятия второго HTTP-запроса, тогда как суммарное время обслуживания второго запроса уменьшится за счёт того, что асинхронное чтение начнётся раньше.
Вы однозначно правы в том, что здесь не стоит делать категоричных заявлений о преимуществах того или иного кода. Уж слишком много факторов, влияющих на результат: размеры и диапазон размеров файлов, время обработки и его возможная нелинейная зависимость от размера файла, частота запросов и размера пула потоков в libeio. Я постараюсь в ближайшее время нарисовать «планы обработки» запросов для примеров из этого топика и различных вариантов «взаимного расположения» поступающих запросов, судя по моим наброскам они намного нагляднее и понятнее. Возможно мы сойдёмся на промежуточной точке зрения :)
Также видится зависимость от времени обработки, видимо выберу последние два-три варианта кода из четырёх и буду строить диаграмму в зависимости от времени обработки.
Мне, к сожалению, не хватает практического опыта для того, чтобы придумать качественный пример для тестирования :(
> Время максимальной блокировки определяется самым тяжелым вычислением.
Об этом я и говорю. Если основную часть времени занимает чтение, то это даст прирост, если вычисление длинные — прироста не будет. Само собой ничего не бывает, но в среднем от лишнего прерывания отзывчивость сервера увеличится, особенно если есть запросы с различным временем обработки. Я думаю провести тест в таких условиях в ближайшее время, надеюсь что всё подтвердится.
Есть, правда, другой вопрос: а не проще ли создать несколько процессов и в каждом обрабатывать запросы синхронно.