When building a production application, you are usually on the lookout for ways to optimize its performance while keeping any possible trade-offs in mind. In this post, we’ll take a look at an approach that can give you a quick win when it comes to improving the way your Node.js apps handle the workload. An instance of Node.js runs in a single thread which means that on a multi-core system (which most computers are these days), not all cores will be utilized by the app.
Don’t you hate it when you see an uncaughtException error pop up and crash your Node.js app? Yeah… I feel you. Can anything be worse? Oh yeah, sorry, unhandledRejection I didn’t see you there. What a nightmare you are. 😬 I maintain all Node.js open-source repos at Sematext. A few of them can help you out with error handling, but more about that further down. Here at Sematext, we take error handling seriously! I want to share a bit of that today.
We just released a Magic Dashboard for Garbage Collection stats for our Node.js integration. If you are leaking memory, this dashboard will help you discover and fix this problem. No setting up is required, this dashboard will magically automatically appear among the rest of your dashboards. ✨
Building SaaS products is hard. Making customers happy is even harder. I should know, I’ve built a start-up that failed! But, not everything is that bad. I learned a lot. Now I maintain a few open-source Node.js projects at Sematext. It’s an observability SaaS. I joined to help make the log management features as good as they can be. If you’ve never heard that term before, my co-worker wrote a great introductory explanation of what Log Management is right here.
There is more to Distributed Tracing with Jaeger than just capturing machine data as with metrics, or tailing log files. To start, you should read this primer. In this article, I will walk you through the initial principles you’ll need before executing anything within your codebase. This is going to focus on Node.js, as slight differences and concerns exist for browser applications.
Monitoring for your Node.js apps can be hard. The tricky part is understanding what you need to monitor, instrumenting your code, and then making sense of all the data that’s been emitted. (That’s almost every part you might say 😅 ). At AppSignal, we dogfood our product and understand the pain users feel ourselves. The key points we focus on are the ease of use, flexibility, and developer experience.
Performance monitoring is great because it lets you see whether your application is fast or slow, and which parts need speeding up. For Node developers, those “parts” are most often endpoints handling incoming requests. Since the introduction of our performance monitoring offering in July 2020, Node devs have been able to use the Sentry SDK, @sentry/node, to measure the total time it takes to process each request, but we made some significant improvements since then.
Application developers are turning to Node.js as one of the most popularly used Javascript frameworks for microservice development. Node.js tops the list of most utilized frameworks amongst the developers worldwide in 2020 by 51.4 percent. With the increasing demand for Node.js technology, it has become crucial to monitor the performance of the applications, servers, and other metrics.
Do you know how many errors your Node.js application had last week? How many users were affected? Which servers were high on CPU/Memory/Disk? If you do know, how many different tools did you have to install, and how many hours you’ve spent configuring all those tools? AppSignal is here to change the way you monitor your apps and simplify your life as a developer. Today, we officially launch the 1.0 version of @appsignal/node.js.
