Go (Golang) vs Node JS: Performance Benchmark

Summary

This video compares Node.js and Golang by deploying microservices using Kubernetes, Istio, and Gateway API. It leverages Kiali, Prometheus, and Grafana for real-time monitoring and performance analysis. The test involves redirecting requests, handling time data, and image processing with S3-compatible Minio and MongoDB. The script also covers deployment strategies, connection management, and resource utilization, concluding that Golang is more efficient in resource handling and load management.

Takeaways

• 🔧 The video compares Node.js and Golang by building microservices and utilizing Istio service mesh with Gateway API.
• 📈 Real-time monitoring of microservices is possible, with the example showing 1.5 requests per second for service-a in Node.js namespace.
• 🔍 Health monitoring is available through the Kiali dashboard, which can show error rates, such as a 22% increase for service-b.
• 📊 Performance metrics like latency, CPU, and memory usage are compared using Prometheus and Grafana for both Node.js and Golang services.
• 💾 Source code and scripts for setting up the test environment are available on the presenter's GitHub repository.
• 🛠️ The test setup includes deploying service-a and service-b in Kubernetes, using Gateway API and Istio for service exposure.
• 🔄 Service-a redirects requests to service-b, which fetches the current time and sends it back, demonstrating inter-service communication.
• 🖼️ In the second test, service-a downloads an image from a Minio S3-compatible service and sends the last modified date to service-b for storage in MongoDB.
• 📈 The presenter suggests that Minio is more efficient for big data analysis than Hadoop, using less disk space with the same replication factor.
• 📊 The test results indicate that Golang services use fewer system resources and handle load better than Node.js services.
• 🔗 The video concludes with a link to the GitHub repository for the source code and an invitation to watch another video comparing Golang with Rust.

Q & A

What is the main focus of the video?

The video focuses on comparing Node.js and Go (Golang) by building multiple microservices and using Istio service mesh with a new Gateway API.

Why is Gateway API used instead of Ingress to expose services?

Gateway API is used to provide a more modern and flexible way to expose services to the internet, as opposed to the traditional Ingress approach.

How can one monitor the traffic and health of microservices in the video?

The video suggests using the Kiali dashboard for real-time monitoring and visualizing the health of microservices, as well as Prometheus and Grafana for detailed metrics.

What is the significance of the error rate increase to 22% mentioned in the script?

The error rate increase to 22% indicates a significant issue with service-b, which is visualized through red lines in the Kiali dashboard, signaling failed status codes.

What are the two main tests described in the video?

The first test involves a GET request to /api/time, which is a simple request to return the current time. The second test involves downloading an image from an S3-compatible service and saving its last modified date into MongoDB.

Why is Minio chosen for the S3-compatible API service?

Minio is chosen because it is more efficient from a storage perspective than Hadoop, especially for big data analysis, as it requires less disk space with the same replication factor.

What is the purpose of the podAntiAffinity setting mentioned in the script?

PodAntiAffinity is used to ensure that all the pods are deployed on different nodes to prevent resource contention and improve the overall resilience of the system.

How does the video script describe the use of Istio for monitoring sidecars?

The script describes adding an 'istio=monitor' label to each pod and using the Prometheus custom resource 'PodMonitor' to select and add them as targets for monitoring.

What is the role of the k6 monitoring tool in the video?

The k6 tool is used to perform the actual tests with different stages of virtual users, providing statistics such as multiple percentiles and overall performance insights.

What are the key performance metrics compared between Node.js and Go services in the video?

The key performance metrics compared include latency from the gateway, CPU usage, and memory usage for each microservice.

How does the video script suggest deploying the services for a fair test?

The script suggests using podAntiAffinity to ensure pods are deployed on different nodes and adjusting the settings to include multiple namespaces for a fair comparison.

What additional components are deployed alongside Prometheus and Grafana for monitoring in the video?

Additional components include the Kiali dashboard, MongoDB, and a deploy script to reproduce the setup.

Why is the connection pool handling different between Node.js and Go services in the test?

The script suggests that the difference in connection pool handling is due to the way each service maintains connections to MongoDB, which affects CPU usage during idle states.

What does the video suggest about the overall resource usage and load handling between Node.js and Go?

The video suggests that Go uses fewer system resources and handles load better than Node.js based on the test results and the observations made during the tests.

Outlines

00:00

🛠️ Microservices Benchmark with Node.js and Golang

This paragraph introduces a comparative study of Node.js and Golang through the deployment of microservices, utilizing Istio service mesh and the Gateway API for service exposure. The setup includes real-time monitoring of microservices, with examples of traffic and error rate monitoring using the Kiali dashboard. The paragraph also mentions the use of Prometheus and Grafana for side-by-side performance comparison, focusing on latency, CPU, and memory usage. The source code is available on GitHub, and the video promises a detailed explanation of the test setup, which is designed to be reproducible for both benchmarking and daily operations.

05:02

📈 Performance Analysis of Node.js vs. Golang Microservices

The second paragraph delves into the specifics of the performance tests conducted on microservices developed in Node.js and Golang. It describes the process of deploying services to Kubernetes, using Gateway API and Istio for traffic management. The tests involve a time retrieval operation and an image downloading scenario from an S3-compatible Minio service, with the latter's efficiency being compared to Hadoop for big data analysis. The paragraph outlines the deployment of MongoDB in Kubernetes and the monitoring setup using Istio sidecars, Prometheus, and Grafana. It also discusses the importance of resource allocation and the use of the k6 tool for load testing, providing insights into the performance differences observed between the two programming environments, with Golang showing better resource management and load handling capabilities.

Keywords

💡Node.js

Node.js is an open-source, cross-platform JavaScript runtime environment that executes JavaScript code outside a browser. In the video's context, it is one of the two technologies being compared for building microservices. The script mentions deploying 'service-a' using Node.js, indicating its role in the test for performance evaluation.

💡Go (Golang)

Go, often referred to as Golang, is a statically typed, compiled programming language designed at Google. It is known for its efficiency and performance. In the video, Golang is compared against Node.js in terms of building microservices and handling system resources, with the script highlighting its lower CPU usage and better load management.

💡Microservices

Microservices is an architectural style that structures an application as a collection of small, loosely coupled services, which implement business capabilities. The video is centered around comparing Node.js and Golang by building multiple microservices and evaluating their performance.

💡Istio

Istio is an open-source service mesh that provides a uniform way to secure, connect, and monitor microservices. The script mentions using Istio with a service mesh for real-time monitoring of microservices, emphasizing its role in the test setup.

💡Gateway API

The Gateway API is a project that aims to establish a standard way to manage network routing in Kubernetes. In the video, the Gateway API is used instead of an ingress to expose services to the internet, indicating a modern approach to service exposure.

💡Kiali

Kiali is an observability console for managing, monitoring, and validating communication between microservices in an Istio service mesh. The script describes using the Kiali dashboard to monitor the health of microservices, with red lines indicating failed status codes.

💡Prometheus

Prometheus is an open-source systems monitoring and alerting toolkit. The video mentions using Prometheus alongside Grafana to compare the microservices' performance, specifically measuring latency, CPU, and memory usage.

💡Grafana

Grafana is an open-source platform for monitoring and observability. It is used in the video to visualize metrics collected by Prometheus, providing a side-by-side comparison of the microservices' performance.

💡Minio

Minio is an object storage server released under the GNU Affero General Public License v3.0. It is compatible with Amazon S3 (Simple Storage Service) APIs. The script discusses using Minio for the S3-compatible API in the test involving image downloading and storage.

💡MongoDB

MongoDB is a NoSQL document-oriented database that stores data in JSON-like documents with optional schemas. In the video, MongoDB is used to store the last modified date of an image downloaded by a microservice, showcasing its use in data persistence within the microservices architecture.

💡k6

k6 is an open-source load testing tool built by the Grafana team. The video script describes using k6 to perform tests with different numbers of virtual users, providing insights into the performance characteristics of the microservices under load.

Highlights

The video compares Node.js with Golang by building multiple microservices.

Istio service mesh and Gateway API are used to expose services to the internet.

Real-time monitoring of microservices is possible through the video's demonstration.

Service-a from Node.js and Golang namespaces are shown to handle similar loads.

Kiali dashboard is used to monitor the health of microservices, including error rates.

Prometheus and Grafana are utilized for side-by-side comparison of microservices' metrics.

Source code for the project is available on GitHub for further exploration.

The video outlines a test setup for deploying service-a and service-b in Kubernetes.

Gateway API and Istio are used for service exposure and client request redirection.

Service-b interacts with an S3-compatible API provided by Minio for image handling.

Minio is highlighted as more efficient for big data analysis compared to Hadoop.

Service-a downloads images and sends metadata to service-b, which then saves it to MongoDB.

A deploy script and build script are provided for Docker image creation and Kubernetes setup.

PodAntiAffinity ensures pods are deployed on different nodes for a fair test.

Istio sidecars are monitored with specific labels and Prometheus podMonitor resources.

Grafana dashboards require resource blocks with requests and limits for accurate monitoring.

The k6 monitoring tool by the Grafana team is used for load testing the microservices.

Local testing can be performed using docker-compose for Minio and MongoDB.

Golang services show higher CPU usage in idle state due to connection handling with MongoDB.

Node.js and Golang services are compared in terms of latency, CPU, and memory usage.

Golang demonstrates better resource handling and load management compared to Node.js.

A link to the GitHub repository with Golang and Node.js source code is provided for reference.

The video suggests watching another test comparing Golang with Rust for further insights.

Transcripts

In this video, we'll compare nodejs with golang by building multiple microservices.

For the test, we'll also use Istion service mesh with a new Gateway API as well, as we'll

use gateway API instead of ingress to expose our services to the internet.

You can monitor in real-time all your microservices.

For example, service-a from the nodejs namespace just started to get traffic and getting around

1.5 requests per second.

We can see a similar load on the service-a from the golang namespace.

I'll explain in detail what the test will look like in a second.

You can also monitor the health of all your microservices using the kiali dashboard.

For example, if something happens with service-b, you'll see red lines that represent failed

status codes.

You can notice that the error rate has increased to 22%.

We'll also use Prometheus and grafana to compare side by side those microservices.

We'll measure latency from the gateway, as well as CPU and memory for each microservice.

You can find the source code in my github repository.

In this video, we're not going to go over all of it because it's a lot, but I'll point

out some important parts; if you're familiar with Kubernetes, you'll be able to reproduce

this setup, not just to run the benchmark but for day to day operations.

For the first test, we'll deploy service-a and service-b in Kubernetes.

To expose service-a, we'll use Gateway Api and istio.

When the client sends a get request to /api/time to the service-a, it will redirect that request

to service-b.

Service-b will get the current time and send it back to service-a, and service-a will send

it back to the client.

For the second test, when the client sends get request to /api/images to the service-a,

it will download the image from the S3.

For the S3, we'll use a Minio, which has S3-compatible API and can be deployed anywhere, including

on-premises.

In my opinion, it's even better and more efficient from the storage perspective than Hadoop if

you want to use it for big data analysis.

It simply takes less disk space than Hadoop with the same replication factor.

When service-a downloads the image, it takes the last modified date of the image and sends

a post request to service-b.

Then service-b saves it into MongoDB (object-oriented database), which we also deploy in Kubernetes.

Along with Prometheus, Grafana, and a bunch of other monitoring components.

I have a deploy script that you can use to reproduce the setup.

I also have a build script that builds the docker images, but you would need to provide

a few environment variables to point it to your ECR repository.

Obviously, to make it a fair test, we'll need to make sure that all the pods are deployed

on different nodes.

For that, you would use the podantiaffinity.

But by default, it only evaluates pods in the same namespace; in our case, we have multiple

namespaces, which we need to include here.

Now to monitor istio sidecars, we want it to visualize the microservices topology that

you saw at the beginning of the video; you would need to add istio equal to monitor label

to each pod and use podMonitor prometheus custom resource to select and add them to

prometheus as targets.

Kiali dashboard works by pulling data from Prometheus.

Since we use gateway api, you also want to make sure that you update the hostnames on

the http routes that point to the gateway.

Finally, for grafana dashboards to properly work and display CPU and memory usage as a

percentage of the limit, you need to include a resource block with requests and limits

to each pod you want to monitor.

To perform the actual test, we'll use the k6 monitoring tool built by the grafana team.

Here, for example, we define multiple stages with different numbers of virtual users.

For instance, in the first stage, for 5 minutes, we'll run 30 users in parallel, then it will

gracefully scale virtual users to 1, and so on.

Also, in the end, it returns statistics about the test, such as multiple percentiles.

If you want to play locally, you can use docker-compose to bring up minio and MongoDB using containers.

At this point, we have deployed both service-a and service-b to Kubernetes.

Let's run the first test and use /api/time endpoint.

Each test takes 30 minutes to run, but I'll speed up the time.

Right away, you can notice that golang CPU usage is higher than a node in an idle state.

In my opinion and based on the kiali dashboard, it's due to the maintaining connection to

the MongoDB even though we are not using it in this test.

However, we do initialize the MongoDB client in the nodejs app as well.

But it looks like they handle the connection pool differently.

After we start a test, you can immediately notice a huge difference in the usage.

On the first graph, you can see the p95 percentile, which is the time it takes to complete 95

percent of all requests.

On the second left graph, we have CPU usage for service-a on the right-hand side memory

usage for the same service-a.

On the bottom, we have similar graphs CPU and Memory usage for the service-b.

In the first test, we simply return the current time from the service-b.

You can also notice the spikes, it's due to having multiple stages.

The first spike is caused by spinning up 30 virtual clients.

Alright, so basically, we have two spikes, and roughly in the middle, we have a gap with

one single user.

Now let's run the second test when we download the image and save the last modified date

to MongoDB.

It's going to take another 30 minutes to complete.

You can also notice a significant difference in the usage.

The blue lines represent the golang services and the green lines are for nodejs.

It looks like the latency for the nodejs hit 5 seconds which could be a timeout from the

MongoDB or minio.

Finally, in the overall timespan between all tests, you can notice that golang uses fewer

system resources and handle load way better than the nodejs.

The source code for the golang and nodejs you can also find in my github repository.

I'll put the link to the description.

If you liked this video, you might want to look at another test where I compare golang

vs. rust.

Thank you for watching, and I'll see you in the next video.