Comments 5
Все слишком очевидно. Тут нет ничего nodejs-специфичного, это все общие советы по оптимизации. А вот, сборка приложения в бандл при помощи приложения esbuild здесь нет, а это важно. Вот лучше разберитесь как его лучше настраивать для nest/next/nuxt, что бы оно вырезало не используемый код и напишите об этом статью.
Async/await работает медленней обычных промисов (а те в свою очередь работают медленней колбэков). Так что async/await нужно использовать обязательно, но только не из соображений улучшения производительности)
2. Лучший способ повышения производительности - отказаться от зависимостей
3. 6. Использование диспетчера приложений, nginx и т.п. не может повысить производительность приложения, т.к. работает с приложением снаружи как с готовой единицей. Вы вдруг переключились с производительночти приложения на производительность сервера.
4. База данных не является никаким местом в приложении node.
5. Кеширование может значительно понизить производстводительность, если бездумно кешировать все подряд. А когда вы докешируетесь до свопа - производительность может упасть на всем сервере сразу, а не только в вашем приложении
7. Потоки, как и кеширование, создают оверхед, который при определеном количестве начнет работать в минус (я где-то читал что оптимальное количество примерно равно количеству ядер проца)
8. Это просто синтаксический сахар, на производительность никак не влияющий
9. 10. Профилирование и мониторинг опять же производительность только уменьшает, т.к. жрет на себя ресурсы. И никак не оптимизирует приложение
8. Это просто синтаксический сахар, на производительность никак не влияющий
Поскольку Вы не уточнили, к чему именно єто синтаксический сахар, прийдется угадывать.
В сообществе js программистов, распространен миф о том, что async/await єто синтаксический сахар к Promise. Что не отвечает официальной спецификации чуть более чем полностью
При єтом, если внимательно посмотреть ссылку на официальную спецификацию, которую я дал, а потом посмотреть там же на описание генераторов - то при очень грубом приближении, можно было бы провести аналогию между async/awaite и поведением генератора с yield.
Иными словами, если вообразить, что термин синтаксический сахар - может обозначать совокупность двух разных частей спецификации, то заявление былобы справедливо по отношению к генератору, который заворачивает в промисы каждый yield.
Чего конечно в спецификации нет, но кто нам мешает фантазировать?
Главный же вывод из єтого в том, что async/awaite нельзя назвать синтаксическим сахаром, только на основании нашего воображения.
Второй же важный вывод следует из алгоритма блокирования async функции в момент вычисления await expression, который поразительно совпадает с таким же у генераторов.
А так как, генераторы - єто одна из самых ресурсоемких частей языка JS, мы уверенно можем сделать вывод о том, что и async тратит не меньше в силу схожести алгоритма.
Как итог - Ваше утверждение по пункту 8 полностью ошибочно. Что подверждают и инженеры v8 в своем блоге разработки
10 советов по оптимизации приложения NodeJS