Какие различия между сервером на Python и сервером на Node.js?

в python 3.6 сетевые приложения сильно эффективнее nodejs, сам python как и прежде сильно медленнее nodejs

в python 3.6 сетевые приложения сильно эффективнее nodejs, сам python как и прежде сильно медленнее nodejs

Как их сравнивать? Нода асинхронна бай дизайн, а пайтон только начал

в пайтоне ж вроде надо рукаме эвентлуп вращать. не?

Как их сравнивать? Нода асинхронна бай дизайн, а пайтон только начал

в питон портировали libuv, в стандартной библиотеке есть eventloop, и это сильно быстрее ноды, рокет-фаст просто

За счет чего?

За счет чего?

там нет v8, использование сишных биндингов из питона намного эффективнее

Это может быть

но да, научиться писать смешанный синхронный и асинхронный код с async/await очень непросто, плюс очень низкие и пока плохие абстракции в asyncio, но выигрыш по сети местами в порядок можно получить

И еще либы искать, которые будут работаться со всем этим

Как их сравнивать? Нода асинхронна бай дизайн, а пайтон только начал

"Только начал" — это это сколько? Я на twisted ещё лет восемь назад писал, tornado и gevent тоже давно существуют.

но да, научиться писать смешанный синхронный и асинхронный код с async/await очень непросто, плюс очень низкие и пока плохие абстракции в asyncio, но выигрыш по сети местами в порядок можно получить

в питоне теперь тоже есть async/await?

Ага.

И еще либы искать, которые будут работаться со всем этим

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

в питоне теперь тоже есть async/await?

причем опять же круче ноды, он там есть гораздо шире и эффективнее: в контекстных менеджерах, в итераторах, есть возможность управлять awaitable логикой любого объекта

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

С gevent и этого не надо. Он подменяет встроенные сокеты и ещё некоторые вещи на свои, и в итоге почти любой синхронный код работает асинхронно.

С gevent и этого не надо. Он подменяет встроенные сокеты и ещё некоторые вещи на свои, и в итоге почти любой синхронный код работает асинхронно.

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

да, но встает вопрос - а нафига такая скорость

один хрен бд придется ждать

кто нить может рассказать как на ноде организуется переиспользование коннектов к бд? или ткнуть чего почитать на эту тему

должно же быть что то вроде DI

На какой ноде?

0.11 вестимо

кто нить может рассказать как на ноде организуется переиспользование коннектов к бд? или ткнуть чего почитать на эту тему

Должен быть пул соединений, когда хочешь сделать запрос к базе берешь свободный коннект из пула

Должен быть пул соединений, когда хочешь сделать запрос к базе берешь свободный коннект из пула

Лучше каждый раз создавать соединение :D

ну да, это впринципе понятно, но не в глобал же это пихается?)

ну да, это впринципе понятно, но не в глобал же это пихается?)

Про модули слышал?

+

осваиваюсь после пыхи потихоньку

Ну вот в модуле коннектишься к базе, этот модуль будет как синглтон, просто потом require его

один хрен бд придется ждать

смотря какую, смотря где, постгрес местами эфективно может заменять монгу или ресинкдб, а там механика другая

Ну вот в модуле коннектишься к базе, этот модуль будет как синглтон, просто потом require его

видимо надо будет перечитать про то как модули работают все же))

видимо надо будет перечитать про то как модули работают все же))

модули кешируются так-то

Одно из основных отличий пхп от ноды в том, что в пхп скрипт выполняется каждый раз целиком для каждого запроса. В ноде программа запускается один раз, и далее все запросы обрабатываются в этом процессе. Поэтому каким-то особым образом управлять соединениями к БД не нужно. Соединение создается и остается открытым (в идеале) на всё время работы программы.

* я ведь прав насчет пхп? )

* не совсем

Одно из основных отличий пхп от ноды в том, что в пхп скрипт выполняется каждый раз целиком для каждого запроса. В ноде программа запускается один раз, и далее все запросы обрабатываются в этом процессе. Поэтому каким-то особым образом управлять соединениями к БД не нужно. Соединение создается и остается открытым (в идеале) на всё время работы программы.

кеш-байткода?

один хрен бд придется ждать

с чего бы вдруг такое утверждение?

кеш-байткода?

не понял вопроса )

Одно из основных отличий пхп от ноды в том, что в пхп скрипт выполняется каждый раз целиком для каждого запроса. В ноде программа запускается один раз, и далее все запросы обрабатываются в этом процессе. Поэтому каким-то особым образом управлять соединениями к БД не нужно. Соединение создается и остается открытым (в идеале) на всё время работы программы.

ну в целом да. вопрос был скорее как грамотно обращаться с дб в ноде

не понял вопроса )

>скрипт выполняется каждый раз целиком для каждого запроса зачем каждый раз заниматься парсингом, построением ast и генерацией байткода, если можно просто закешить байткод? ну и есть php daemon

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

>скрипт выполняется каждый раз целиком для каждого запроса зачем каждый раз заниматься парсингом, построением ast и генерацией байткода, если можно просто закешить байткод? ну и есть php daemon

ну fpm по крайней мере так и делает (я про кеш)(точнее вроде не сам fpm даже а расширение opcache)

причем опять же круче ноды, он там есть гораздо шире и эффективнее: в контекстных менеджерах, в итераторах, есть возможность управлять awaitable логикой любого объекта

Напрашивается вопрос: Если python так же эффективен как и нода, то не лучше ли выбрать python ? Подводные камни или просто дело вкуса ?)

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

*в отличии от всех других языков)

Напрашивается вопрос: Если python так же эффективен как и нода, то не лучше ли выбрать python ? Подводные камни или просто дело вкуса ?)

Бенчмарки - вещь странная. В блоге по PHP всегда графики показывают, что PHP быстрее любого языка. В блоге по Python, node.js и пр. аналогично

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

php-daemon жи.

Напрашивается вопрос: Если python так же эффективен как и нода, то не лучше ли выбрать python ? Подводные камни или просто дело вкуса ?)

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

php-daemon жи.

принцип один запрос - один воркер (процесс) это не изменяет. поэтому php и днище. fastcgi неприлично устарел

сори за оффтоп :) а накидайте интересных ссылок по микросервисным архитектурам в ноде и околонодовой инфраструктуре? я тут планирую недельку выделить и поресерчить че интересного появилось за последнее время пока список такой: https://istio.io/ https://github.com/hemerajs/hemera

сори за оффтоп :) а накидайте интересных ссылок по микросервисным архитектурам в ноде и околонодовой инфраструктуре? я тут планирую недельку выделить и поресерчить че интересного появилось за последнее время пока список такой: https://istio.io/ https://github.com/hemerajs/hemera

На хабре буквально вчера была статья про это

Бенчмарки - вещь странная. В блоге по PHP всегда графики показывают, что PHP быстрее любого языка. В блоге по Python, node.js и пр. аналогично

бенчмарк всегда можно повторить самому, а еще сделать свой

бенчмарк всегда можно повторить самому, а еще сделать свой

Так ли просто сделать объективный и правильный бенчмарк?

Так ли просто сделать объективный и правильный бенчмарк?

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

принцип один запрос - один воркер (процесс) это не изменяет. поэтому php и днище. fastcgi неприлично устарел

нет же. в php-daemon тот же event loop

Напрашивается вопрос: Если python так же эффективен как и нода, то не лучше ли выбрать python ? Подводные камни или просто дело вкуса ?)

всмысле "эффективен"?

нет же. в php-daemon тот же event loop

не знал, да, это уже что-то, но libevent под капотом и поодержка третьих лиц. ну лет 5 назад было бы ок

не знал, да, это уже что-то, но libevent под капотом и поодержка третьих лиц. ну лет 5 назад было бы ок

а что не так с libevent?

а что не так с libevent?

по кросс-платформенности и скорости несравнима с libuv, нода подарила миру супер-быструю и переносимую библиотеку, которую притащили в python, rust, lua, .net. в python она кстати быстрее чем в nodejs, для которого была создана.

плюс libuv умеет эффективно файлы и треды, это очень мощное преимущество

сори за оффтоп :) а накидайте интересных ссылок по микросервисным архитектурам в ноде и околонодовой инфраструктуре? я тут планирую недельку выделить и поресерчить че интересного появилось за последнее время пока список такой: https://istio.io/ https://github.com/hemerajs/hemera

Я когда-то подписался на рассылку, но все время откладываю почитать на потом. Может вам пригодится — http://us9.campaign-archive2.com/home/?u=510d6f81b948a39e0d9c32ec3&id=7b3139f09c

спасибо

libevent же дает инвентарь уровня 5-7 летней давности, это совсем никуда

Бенчмарки - вещь странная. В блоге по PHP всегда графики показывают, что PHP быстрее любого языка. В блоге по Python, node.js и пр. аналогично

Согласен. Но PHP это другое. Он просто изначально построен так, что всегда умирает. Демонизация в нем вызывает дискомфорт лично у меня.

спасибо

https://github.com/mfornos/awesome-microservices вот тут по всей инфраструктуре, не только про ноду

ERROR: S client not available

сори за оффтоп :) а накидайте интересных ссылок по микросервисным архитектурам в ноде и околонодовой инфраструктуре? я тут планирую недельку выделить и поресерчить че интересного появилось за последнее время пока список такой: https://istio.io/ https://github.com/hemerajs/hemera

Ещё обычно помогает загуглить „awesome <ТО, ЧТО ИНТЕРЕСУЕТ>“

Ах, опередил ))

ну в awesome пихают все подряд, везде полно откровенного шлака

ну в awesome пихают все подряд, везде полно откровенного шлака

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

всмысле "эффективен"?

Ну я имел ввиду, что за те же ресурсы, получаем ту же производительность. Т.е. они могут конкурировать на одинаковых задачах.

Ну я имел ввиду, что за те же ресурсы, получаем ту же производительность. Т.е. они могут конкурировать на одинаковых задачах.

Если это конечно так. Могу ошибаться. Поэтому и задал вопрос

по кросс-платформенности и скорости несравнима с libuv, нода подарила миру супер-быструю и переносимую библиотеку, которую притащили в python, rust, lua, .net. в python она кстати быстрее чем в nodejs, для которого была создана.

во-первых, там много нюансов, начиная с только что poll watchers в винде умеют только сокеты и заканчивая тем что максимальное разрешение таймеров огрубляется до 1ms.

плюс libuv умеет эффективно файлы и треды, это очень мощное преимущество

всмысле?

Ну я имел ввиду, что за те же ресурсы, получаем ту же производительность. Т.е. они могут конкурировать на одинаковых задачах.

сильно зависит от. обслуживание event loop не бесплатное и в cpu bound задачах это будет видно. если же сравнивать nodejs и python(в лице pypy), то нода быстрее(но можно накорябать сишное расширение).

во-первых, там много нюансов, начиная с только что poll watchers в винде умеют только сокеты и заканчивая тем что максимальное разрешение таймеров огрубляется до 1ms.

там же iocp давно есть

всмысле?

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

там же iocp давно есть

и? причем тут poll watchers?

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

>epoll, например, не умеет файлы умеет, через inotify

если же про готовность чтения/записи, то обычный файл всегда готов

>epoll, например, не умеет файлы умеет, через inotify

раньше не умел никак, а с какой версии ядра? чтение/запись всегда неблокирующаяся?

сильно зависит от. обслуживание event loop не бесплатное и в cpu bound задачах это будет видно. если же сравнивать nodejs и python(в лице pypy), то нода быстрее(но можно накорябать сишное расширение).

Ну так не нужно cpu bound. Изначально вроде event loop заточен под io bound. cpu bound задачи, должны вроде решаться за пределами event loop, если я правильно понял концепцию.

Ну так не нужно cpu bound. Изначально вроде event loop заточен под io bound. cpu bound задачи, должны вроде решаться за пределами event loop, если я правильно понял концепцию.

в питоне cpu-bound задачи (это в 90% случаев вычисления) решаются лучше всего, весь ML/DL там

раньше не умел никак, а с какой версии ядра? чтение/запись всегда неблокирующаяся?

если данные есть в page cache - да :)

если нет - да, процесс будет заблокирован и это решается пулом потоков в который сгружаются такие операции

libuv именно так и делает.

libuv именно так и делает.

этим он и хорош, а есть где почитать подробно про epoll -inotify? я не знал про это

если нет - да, процесс будет заблокирован и это решается пулом потоков в который сгружаются такие операции

вот в питоне asyncio (uvloop) файлы не умеет, там тоже с файлами надо работать через потоки, вот это совсем плохо когда нужно писать логику и продукт а приходится познавать особенности ядра (хотя это и интересно очень)

О круто https://medium.com/npm-inc/npm-5-is-now-npm-latest-d674e9e3b0ec

Господа, шалом. кто-нибудь фиксил 503 ошибку при фетче поста с клиента на сервер в heroku? На локале все норм. Деплоится на хероку тоже норм но как только тригерю фетч все крашится с 503. React-express

ну и туда же https://medium.com/@treyhuffine/whats-new-in-node-8-e1cce6539a71

ну и туда же https://medium.com/@treyhuffine/whats-new-in-node-8-e1cce6539a71

с аддонами прям прорыв, наконец эта жесть с api закончится может

О, пришёл с новостями, а вы уже

Самый быстрый шитпостинг на диком западе

То есть импорт стейтменты опять не сделали(

типа import как в бабеле?

Да, уже 2 года не родят никак