Прошу прощения, что лезу в ваши личные предпочтения относительно архитектуры приложения, но в вашем гипотетическом случае я бы не стал серверу приложений давать больше работы, чем ему нужно — разобрал запрос, сделал редирект на нужный файл и дальше nginx, возможно даже на другом сервере или на связке серверов отдает эти файлы.
Вы сами понимаете, что «нод в отличие от апача держит огромное количество запросов» ничего о масштабируемости не говорит? Нод действительно может обслужить больше параллельных запросов чем апач на том же сервере.
Может мы с вами по-разному понимаем одни и те же выражения, но архитектура event-driven приложений это на мой взгляд именно продукт пути, который проходит unix. С другой стороны unix-way, как понятие, означает не эволюцию, а идеологию и в этом контексте node.js не соответствует букве, хотя и пропитана духом unix-way.
inetd это ведь unix-way? Он же призван встроиться в цепочку от консольной программы до пользователя сети (как pipe, только на уровне сети). nginx выполняет ту же роль. Вы помните почему inetd перестал пользоваться спросом? Он вел себя точно так же как apache — плодил процессы и подгружал программы полными экземплярами. Этот подход оправдывал себя не долго и от него отказались в пользу постоянно висящих в памяти демонов. Разумеется вам никто не мешает поднять старичка из могилы для того, чтобы писать сетевые сервера на shell, но современным требованиям к коммерческим системам это уже не соответствует. То же происходит и с веб-серверами: cgi отмирает из-за низкой эффективности и на его место приходят сервера приложений, управляемые событиями. Node.js просто один из экспериментальных представителей этой эволюции. Выживет он или не пройдет естественный отбор, покажет время, но эволюционный шаг unix, начавшийся с отказа от inetd в любом случае будет сделан. И пока не ясны все особенности приходящей парадигмы, сложно прогнозировать результаты этого эксперимента. А автор, в силу юношеской категоричности, ищет грань между черным и белым в сером мире, цепляясь за свое прошлое и навязывая его восприимчивому читателю.
Если загнать ОС в глубокий SWAP, то может и больше. Но в данном случае конечно большая часть процессорного времени была занята тяжелой рекурсивной функцией.
Между «меньше-чем-эксперты» и «серьезные деньги» — пропасть.
Вас всерьез беспокоит чем увлекаются другие? Вы сокрушаетесь, что кто-то сделает не достаточно хорошо (по вашим меркам) только потому, что пошел на поводу у лукавой рекламы? Или вам никто не рассказал, что это плохо — негодовать по поводу чужих предпочтений, не совпадающих с вашими? Доводы автора о не правдивости рекламы node.js несостоятельны — порог вхождения действительно ниже и существует круг задач, где эта технология имеет свои преимущества. А то, что Тэд искал в ней универсальность викторинокса — личные проблемы Тэда и других страдающих психозом перфекционизма. Не существует самого лучшего языка или архитектуры, есть лишь удачные для определенного круга задач.
Не говоря уже о том, что благодаря EC2 и Azure можно начинать экспериментировать с масштабируемостью и без особых денег и/или знаний.
Боюсь вы введены в заблуждение. Приступая к использованию этих платформ начинать экспериментировать с масштабиемостью уже поздно — на момент запуска проекта на этих сервисах надо уже четко осознавать что и для чего ты делаешь, чтобы избегать блокировок уровня архитектуры кластера. А при этом возникают проблемы, в сравнении с которыми блокировка потока node.js покажется цветочками. (Ну запустил для вашей задачи EC2 копию вашего сервера на соседнем ip, как вы собираетесь синхронизировать копии данных? Заблокируете копии приложения обращением к одной базе данных с разных серверов? Включите зеркальную репликацию данных между серверами, создав затор обменом между копиями СУБД?). Нет, тут уже не отделаешься простыми решениями, за которые так ратует автор поста. Тут придется разбираться со всякими Hadoop и/или RabbitMQ, которые бесконечно далеки от любимого Тэдом CGI-подхода (распараллеливания процессов полными экземплярами). Вот так поэкспериментируешь с EC2 и дойдет в чем главные преимущества однопоточной архитектуры для масштабирования. И перестанете слушать всяких троллей. Может на node.js не остановитесь, но уж чем Tornado или OTP лучше любимого Тэдом django в нагруженных проектах, усвоите на зубок.
«Пусть распустятся сто цветов, пусть откроются сто школ». Какая вам разница что кто-то будет делать свой проект на «не правильном» с вашей точки зрения фреймворке? Коснется вас, тогда и аргументируйте своему системному архитектору или инвестору, что вы собираетесь придерживаться другой школы. Рынок всё расставит по своим местам. Не досужая болтовня о том, что кто-то не прав, а конкретные проекты с конкретной выручкой. Так пусть дерзают. Повезет — разовьют эту технологию до каких-то высот, не повезет — дадут опыт набитых шишек. Всё это ценно, а неконструктивная критика — нет.
Вы не ощущали как тормозит сервер, у которого Apache + mod_php так размножились в памяти, что ушли в swap? А такое легко случается с синхронными приложениями при высокой нагрузке. Тогда как асинхронные всего-лишь могут выпасть по таймауту при переполнении запросами. То есть система останется стабильной и обслужит максимум запросов максимально используя ресурсы. Node.js на мой взгляд не лучший представитель этой архитектуры, но то, что пишет автор — просто бред.
Node.js не язык, а однопоточный сервер приложений на языке javascript. То, что автор указал как трагедию, не трагедия, а глупость. Он занял процессор на 5 секунд и начал негодовать, что все 5 секунд ему пришлось ждать результата. На своем любимом Django он получил бы точно такой же результат — 5 секунд ожидания. Это не проблема Node.js. Хотя в нем проблем действительно хватает.
Обсуждаемые «недостатки» существуют только в воображении автора. Он рассчитывал сделать шоковую новость для начинающих и ему это удалось. Но те, кто разбираются, знают, что проблемы конечно есть, но они меньше и в другом месте. А указанное автором — глупость.
Я отвечал на первый :)
С буквой всё понятно, но даже духа не признаете?
Вас всерьез беспокоит чем увлекаются другие? Вы сокрушаетесь, что кто-то сделает не достаточно хорошо (по вашим меркам) только потому, что пошел на поводу у лукавой рекламы? Или вам никто не рассказал, что это плохо — негодовать по поводу чужих предпочтений, не совпадающих с вашими? Доводы автора о не правдивости рекламы node.js несостоятельны — порог вхождения действительно ниже и существует круг задач, где эта технология имеет свои преимущества. А то, что Тэд искал в ней универсальность викторинокса — личные проблемы Тэда и других страдающих психозом перфекционизма. Не существует самого лучшего языка или архитектуры, есть лишь удачные для определенного круга задач.
Боюсь вы введены в заблуждение. Приступая к использованию этих платформ начинать экспериментировать с масштабиемостью уже поздно — на момент запуска проекта на этих сервисах надо уже четко осознавать что и для чего ты делаешь, чтобы избегать блокировок уровня архитектуры кластера. А при этом возникают проблемы, в сравнении с которыми блокировка потока node.js покажется цветочками. (Ну запустил для вашей задачи EC2 копию вашего сервера на соседнем ip, как вы собираетесь синхронизировать копии данных? Заблокируете копии приложения обращением к одной базе данных с разных серверов? Включите зеркальную репликацию данных между серверами, создав затор обменом между копиями СУБД?). Нет, тут уже не отделаешься простыми решениями, за которые так ратует автор поста. Тут придется разбираться со всякими Hadoop и/или RabbitMQ, которые бесконечно далеки от любимого Тэдом CGI-подхода (распараллеливания процессов полными экземплярами). Вот так поэкспериментируешь с EC2 и дойдет в чем главные преимущества однопоточной архитектуры для масштабирования. И перестанете слушать всяких троллей. Может на node.js не остановитесь, но уж чем Tornado или OTP лучше любимого Тэдом django в нагруженных проектах, усвоите на зубок.