Боюсь, что я "делаю не то" здесь, если так, удалите меня, и я извиняюсь.В частности, я не вижу, как я создаю аккуратные маленькие аннотации, которые создали некоторые люди.Тем не менее, у меня есть много проблем / замечаний, которые можно сделать в этой теме.
1) Комментируемый элемент в псевдокоде в одном из популярных ответов
result = query( "select smurfs from some_mushroom" );
// twiddle fingers
go_do_something_with_result( result );
по сути является поддельным.Если поток вычисляет, то он не крутит большие пальцы, он выполняет необходимую работу.Если, с другой стороны, он просто ожидает завершения ввода-вывода, то он не использует процессорное время, весь смысл инфраструктуры управления потоками в ядре состоит в том, что процессор найдет что-то полезное для выполнения,Единственный способ «перевернуть пальцы», как предлагается здесь, состоит в создании цикла опроса, и никто, кто закодировал реальный веб-сервер, не способен на это.
2) «Потоки трудны», толькоимеет смысл в контексте обмена данными.Если у вас есть по существу независимые потоки, как, например, в случае обработки независимых веб-запросов, то создание потоков является тривиально простым, вы просто кодируете линейный поток обработки одной работы и сидите, зная, что она будет обрабатывать несколько запросов, и каждыйбудет эффективно независимым.Лично я бы рискнул, что для большинства программистов изучение механизма замыкания / обратного вызова является более сложным, чем простое кодирование версии потока сверху вниз.(Но да, если вам нужно общаться между потоками, жизнь становится действительно тяжелой и очень быстрой, но тогда я не уверен, что механизм закрытия / обратного вызова действительно меняет это, он просто ограничивает ваши варианты, потому что этот подход все еще достижим с потокамиВо всяком случае, это совсем другое обсуждение, которое на самом деле здесь не актуально).
3) Пока никто не представил никаких реальных доказательств того, почему один конкретный тип переключения контекста будет более или менее трудоемким, чем любойдругой тип.Мой опыт создания многозадачных ядер (в небольшом масштабе для встроенных контроллеров, ничего более необычного, чем «настоящая» ОС) подсказывает, что это не так.
4) Все иллюстрации, которые у меня естьДо сих пор мы видели, что этот термин призван показать, насколько быстрее Node, чем другие веб-серверы, ужасно испорчены, однако, они испорчены таким образом, что косвенно иллюстрируют одно преимущество, которое я определенно принял бы для Node (и оно отнюдь не незначительно).Узел не выглядит так, как будто он нуждается (и даже не разрешает) в настройке.Если у вас есть многопоточная модель, вам нужно создать достаточное количество потоков для обработки ожидаемой нагрузки.Сделайте это плохо, и вы получите плохую производительность.Если потоков слишком мало, то процессор простаивает, но не может принять больше запросов, создать слишком много потоков, и вы будете тратить впустую память ядра, а в случае среды Java вы также будете тратить впустую память основной кучи,Теперь, для Java, тратить кучу - это первый, лучший способ поднять производительность системы, потому что эффективный сбор мусора (в настоящее время это может измениться с G1, но кажется, что жюри все еще находится на этом этапе по состоянию на начало 2013 годапо крайней мере) зависит от наличия большого количества запасной кучи.Итак, есть проблема: настройте его на слишком малое количество потоков, у вас незанятые процессоры и низкая пропускная способность, настройте его на слишком много, и он застрянет другими способами.
5) Есть еще один способ, которым я принимаю логику утверждения, что подход Node «быстрее по замыслу», и это так. В большинстве потоковых моделей используется модель переключения контекста с разбивкой по времени, расположенная поверх более подходящей (оповещение о ценности :) и более эффективной (не оценочной) модели с вытеснением. Это происходит по двум причинам: во-первых, большинство программистов, по-видимому, не понимают приоритетное вытеснение, и, во-вторых, если вы изучаете многопоточность в среде Windows, существует временная зависимость, нравится вам это или нет (конечно, это усиливает первую точку Примечательно, что в первых версиях Java использовалось приоритетное вытеснение в реализациях Solaris и временная привязка в Windows. Поскольку большинство программистов не понимали и жаловались на то, что «многопоточность не работает в Solaris», они везде изменили модель на временную шкалу). В любом случае, суть в том, что временная привязка создает дополнительные (и потенциально ненужные) переключатели контекста. Каждое переключение контекста отнимает процессорное время, и это время эффективно удаляется из работы, которую можно выполнить в реальной работе под рукой. Однако время, затрачиваемое на переключение контекста из-за временного среза, не должно превышать очень небольшой процент от общего времени, если только не происходит что-то довольно странное, и я не вижу причин ожидать, что это произойдет в простой веб-сервер). Итак, да, избыточные переключатели контекста, связанные с временным разделением, неэффективны (и, как правило, в потоках kernel , как правило, кстати), но разница будет в несколько процентов пропускной способности, а не в виде факторы целого числа, которые подразумеваются в заявках на производительность, которые часто подразумеваются для узла.
Во всяком случае, извинения за то, что все это было длинным и грубым, но я действительно чувствую, что обсуждение пока ничего не доказало, и я был бы рад услышать от кого-то в любой из этих ситуаций:
a) реальное объяснение того, почему Node должен быть лучше (помимо двух сценариев, которые я обрисовал выше, первый из которых (плохая настройка), я считаю, является реальным объяснением всех тестов, которые я видел до сих пор. ([править], на самом деле, чем больше я об этом думаю, тем больше мне интересно, может ли здесь быть значимой память, используемая огромным количеством стеков. Размеры стеков по умолчанию для современных потоков, как правило, довольно велики, но память выделенная системой событий на основе замыканий будет только то, что нужно)
b) реальный эталонный тест, который фактически дает реальную возможность выбранному многопоточному серверу. По крайней мере, таким образом, я должен был бы перестать верить, что утверждения по сути ложные;> ([править] это, вероятно, намного сильнее, чем я предполагал, но я чувствую, что объяснения, приведенные для повышения производительности, в лучшем случае неполны, и показанные критерии являются необоснованными).
Ура,
Toby