Проблемы разработки Node.js
31 марта 2023 г.Это не лекция о javascript. Он хорошо служил нам в браузере на протяжении многих лет, а также хорошо служил нам на сервере.
Учитывая широкое использование JavaScript, понятно, что многие люди используют его для создания своих серверных частей.
Почему JavaScript плох для серверного программирования
ЦП
Самым существенным недостатком javascript на сервере является то, что он является однопоточным. Это означает, что он не может равномерно распределить рабочую нагрузку по ядрам сервера.
Чтобы заставить javascript использовать больше тел, вам нужно будет вручную передать часть работы воркерам; но добиться такой же эффективности, как на других платформах, сложно.
Второй и наиболее распространенный подход — запустить несколько экземпляров вашей программы, позволяя операционной системе планировать вашу работу на отдельном ядре, отличном от того, на котором работают другие ваши экземпляры. Как правило, вы должны запускать столько экземпляров, сколько ядер в вашей системе, чтобы вы могли использовать весь свой ЦП.
Веб-разработчикам, использующим Rust, Go или .net, не нужно беспокоиться об этом, потому что выбранная асинхронная среда выполнения сделает это за них.
Память
Еще один недостаток, о котором вы, возможно, не знаете, заключается в том, что V8 (движок javascript, на котором работает узел) имеет ограничение на размер кучи 2 ГБ/4 ГБ (различается в разных версиях).
Независимо от того, сколько оперативной памяти у вас есть на вашем компьютере, если вы воспользуетесь этим размером кучи, ваша программа выйдет из строя. Это может быть ужасно, если сбой вызван чрезмерным использованием, а не утечкой памяти.
Чтобы избежать этого, задайте для параметра max-old-space-size вашего процесса узла значение, подходящее для вашего сервера.
В Rust, Go или .NET нет предела памяти для скрытых программ, вызывающих сбои. a>, поэтому разработчикам не нужно беспокоиться об этом.
Производительность
Мы подошли к моменту, когда производительность javascript может быть просто фантастической благодаря многолетней конкуренции за создание самого быстрого браузера. Но не гарантируется, что он будет работать с максимальной производительностью.
Видите ли, у JavaScript есть две проблемы: во-первых, он должен иметь быстрое время «запуска из исходного кода», а во-вторых, он должен иметь возможность быстро выполнять реальную логику приложения.
Это решается с помощью многоэтапного процесса компиляции, в котором первый проход просто запускает код, не затрачивая много усилий на оптимизацию.
Когда программа поработает какое-то время, V8 определит, где стоит потратить время на оптимизацию, и отправит работу своему оптимизирующему компилятору.
Обычно это хорошо, так как после запуска процесса узла он оптимизируется, а серверы исторически были длительными процессами.
До сих пор все изменилось в эпоху бессерверных вычислений.
Когда код запускается, он выполняет только один запуск кода; это не идеально для двигателя V8, потому что у него никогда не будет возможности применить свои оптимизации. При этом было бы намного хуже, если бы он все-таки внес свои улучшения, поскольку это означало бы, что он использовал много циклов ЦП для оптимизации чего-то, что через несколько мгновений было бы уничтожено.
Разработчику Rust не нужно беспокоиться об этом, поскольку оптимизация происходит во время компиляции, и приложение с самого начала работает с максимальной производительностью.
Я надеюсь, что вы нашли это полезным и всегда цените; спасибо!
Посмотрите следующее видео для дополнительного контекста:
Также опубликовано здесь
Оригинал