Pull to refresh

Comments 28

UFO just landed and posted this here
Профессиональная деформация личности?

Одна строка — одно выражение.

Это как точка с запятой + (char)10 в конце операции.
Вроде что-то и по делу написали, но слог ваш очень и очень труден для восприятия.
I'm very sorry: профдеформация + ассоциативное мышление.
Если что предложить — напишите в личку, плиз.
Блин, люди, я реально — гик?

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

«Словечки» \ «мемы» \ «выводы» \ «всё вместе взятое» — что трудности вызывает?

Если считаете что-то не понятным, пожалуйста — напишите, я же не кусаюсь.
Постараюсь пояснить или исправить «неправильные» места.

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

Разговорный стиль не подходит для текстов длиннее, чем на башорге.
То есть какие-то оттенки или вообще способ изложения называется — "разговорный стиль"!

Не знал даже. Спасибо, понятно.
Там всё переписывать нужно, оно целиком из неформального общения состоит.
Намеренно пытался написать так, чтобы было как «разговор в курилке».

Хм… не знаю что делать.
Удалять не хочется, к тому же может быть кому-то наоборот понравится именно такой стиль.

Добавлю опрос!
В целом, не стоит столь много рефлексировать на эту тему. Вероятно, написание статей просто не ваше. Такое бывает, и ничего в этом страшного нет.

Ок. Да, бывает, что получается, а бывает — что нет. Просто хотелось объяснить, что не нужно верить сферическим тестам и предоставить какой-то способ посмотреть на них со стороны.
При разговоре в курилке есть жестикуляция, есть интонация, оратора можно прервать и задать уточняющий вопрос. Но при этом нет кусков кода, таблиц, конфигов и прочей сухой технической информации. Если просто написать «чуваки, я тут пострелял по нджинксу и ноде, и выходит, что нода-то медленнее всего в 3-5 раз, а не на порядок», то будет нормально, но такие утверждения надо подтверждать конфигами, кодом стрелялки и таблицей с результатами, а посреди такого текста они смотрятся неуместно.
Тест не репрезентативный, единственное, что он показывает — что на моей очень слабой машине нода отстаёт на пол порядка всего. Нода, как и Nginx, почти ничего не делают, в этом смысле они «равны». Конфиги вроде же приложил. GIT тоже. Хотел показать, что есть taskset, что нода может не перегружать проц при определённых условиях, что не нужно верить тестам.

Насчёт манеры изложения — понятно. Почему-то показалось, что если мне забавно «звучит», то и всем остальным будет тоже. Прям вот сидел и представлял как люди будут улыбаться, читая этот бред :)
«Node.js не подходит для хайлоада».
это совсем по другому поводу сказано. Очевидно же отдачу сервера с отдачей статики никто не сравнивает, поэтому сравнивать корректно именно с апачем. Так вот апач она рвет как грелку. Но проблема у совсем ноды за которую ее критикуют совсем в другом, это язык, программисты и блокирующая однопоточность. Для хайлоада она очень даже подходит, просто нужно УМЕТЬ ПРОГРАММИРОВАТЬ, она по своему более критична к качеству кода в больших проектах. Обязательно тесты, грамотный кодер в проекте и вы почувствуете ее преимущества в хайлоаде.
Абсолютно согласен.

Просто в той самой статье, с которой я решил таки высказаться было утверждение типа: «node.js, откровенно говоря, разочаровал»…

Мне стало обидно, т.к. имхо сравнивают ежа с ужом.

Поэтому я вспомнил про свой давным давно запиленный «идеальный тест», выложил его на гит и набросал этот топик.
Как бы ваш тест ничем не лучше. Булшитная методика со сферическими целями.
А что Вам не нравится в буллшитности методики? Способ измерения, или цели, или всё вместе взятое?

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

Представьте свой не буллшитный тест :)
Булшитность в том, что как раз тест ни разу не репрезентативен. В итоге ценность «для истории» вашего заявления равна ценности заявлений, побудивших вас к опусу.
А что по Вашему мнению должен был показать тест? Что он должен делать, чтобы стать репрезентативным?
Зиповать архивы? Слать статику?

Или всё же показать, что удержание N-соединений вообще возможно в неких условиях?
То есть Вы тоже согласны, что сравнивать Node.JS и Nginx — слишком толсто, так?

Просто, я как бы тоже могу грозными словами покидаться, буллшитность там, опусы. Как бы и так уже очевидно, что смысл был постебаться, но с некоторыми выводами. То есть — Вы кому верить будете, Себе или мне?

Если будете верить каким-то там тестам в интернете, то есть даже этому — искренне «поздрваляю»!
У вас серьезные проблемы с изложением мыслей.
Я в курсе, спасибо. Это у меня давно. Почему-то кажется, что все незнакомые люди уже идут от туда, куда я только собираюсь пойти.
Как автор «той» статьи, не могу пройти мимо.
— NGINX отдаёт только свою дефолтную статическую страницу index.html.
— Сервер Node должен вести подсчёт соединений и выдавать в каждом ответе результат, так же считать и максимальное количество.

Вы выставляете неравные условия участникам. Допустим, в nginx и ОС не реализовано кеширование файлов. Тогда nginx заведомо бежит с гирей на ноге.
Почему бы Node тоже не отдавать файл? Пока непонятно, почему именно такая постановка задачи.
Сразу скажу, что все тесты я крутил минут по 10, занимаясь при этом обычными задачами типа кода и сёрфинга.

Ой, это зря. Хотя вы упоминали что пишите только на JS (т.е. надеюсь не было компиляций С++ кода и прочих убийц CPU в процессе тестирования).
ПО для запросов я тоже написал на ноде через request.js.

Хм, а вы уверены что ваше ПО для запросов способно физически выдать больше запросов/сек, чем показал ответов nginx :)?
Покажите результаты с weighttp.
С аффинити я вообще ничего не понял если честно. Т.е. понятно, что вы тестили с вызовом taskset -pc и без него и в этом суть ваших измерений, но результаты осмыслить не смог. С вашего позволения, прогоню тесты у себя, скажите что ставить в аффинити и какой из скриптов брать (test_httpserver.js или overload.js)?
Почитал про affinity в linux. Выяснилось, что сложность планировщика при переключении задач между ядрами CPU в 2.6 ядре составляет аж O(1). Кроме того, без isolcpus то что вы пытаетесь делать вообще лишено смысла. Окончательную точку может поставить только эксперимент, но для этого мне нужно понять как именно вы пытаетесь сыграть с taskset, понять вашу идею.
Привет :) Не мог ответить раньше, был вообще вне компа.

Идея. Допустим у нас 2 ядра, нулевое и первое. Я хочу, чтобы нода крутилась только на первом ядре.

Поэтому я просто делаю, изнутри самой ноды:

taskset -pc 1 PROCESS_ID

Надеясь, что это сработает так, как я хотел, т.е. именно мой процесс будет использовать только это ядро. Наблюдал долго через htop. Бывает, что перекидывает, но потом возвращает. Насколько я понял, что из-за сложности планировщика непосредственно указать ядро для самого процесса практически не возможно. С того самого времени как я это прочёл, где-то на stackoverflow, без особого энтузиазма пытаюсь понять как именно мне сделать так, чтобы это ядро не было занято вообще ничем кроме ноды. Вот это было бы здорово!

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

Да, спасибо Вам, что ответили, это тоже очень здорово.

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

Тестил я только с вызовом taskset -pc.
А «без affinity» — значит, что я никак не игрался с планировщиком в этом случае, оставляя все игры на откуп системы.

test_httpserver.js — это скрипт, который на 8000 порту создаёт HTTP сервер, т.е., не полноценный, просто ответы по этому порту.

test_requester.js — эта штука делает запросы, она же считает количество своих соединений, это последняя цифра после символа |

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

isolcpus

На остальное скажу одно: в моем бенче выявлены грубые нарушения (в т.ч. и вами, но дело тут не только и не столько в affinity, сколько в общем макс. количестве потоков сервера\клиента на N-ядерном процессоре), в ближайшие дни часть «результаты» будет полностью переделана.
Да, и, я не преследовал цели там обидеть или что такое, мне просто жалко ноду и хочется разобраться.

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

Я упёрся как-то в эту вещь: kernel.max_lock_depth. Она по умолчанию маленькая.

В интернетах пишут, что если нужно увеличивать, то нужно это где-то в сишном коде править.

Если ничего не менять, то после node test_requester.js нужно нажать Enter один раз, чтобы запустить запросы.
Сервер запускается как node test_httpserver.js.
Для этих целей в package.json зарезервирован блок scripts.
Для второго можно использовать npm start, указав start-команду. А первое похоже на тест, поэтому для него вполне можно применить npm test. Указывается test-команда.
npm scripts
Sign up to leave a comment.

Articles