DEV Community: Mikiya Ichino

Single-Threaded vs Multi-Threaded Servers: An Experiment with Node.js and Java

Mikiya Ichino — Thu, 18 May 2023 02:14:54 +0000

Introduction

As a fullstack developer who started my career with Java and SpringBoot, I've become familiar with how Apache servers handle multiple requests using a multi-threading mechanism.

Each request received by the server initiates a new process, allowing simultaneous handling of multiple requests.
However, this traditional approach led to a known issue called the C10K problem, a constraint that makes it challenging for servers to efficiently manage ten thousand concurrent connections.

In contrast, event-driven, single-threaded servers like Node.js have introduced a new way of handling high concurrent connections more effectively. In this article, I aim to compare the behavior of single-threaded (Node.js) and multi-threaded (Apache) servers when dealing with CPU-intensive requests under high load conditions.

Theoretical Expectations

Predicting the outcome, I anticipate that when a server receives a CPU-intensive request that takes a considerable amount of time to process, the single-threaded server will struggle more than a multi-threaded server. A multi-threaded server can process multiple CPU-intensive tasks concurrently, whereas a single-threaded server can only handle one task at a time.

Single-Threaded vs Multi-Threaded

Before we dive into the experiment, let's briefly distinguish between single-threaded and multi-threaded servers.

Single-threaded servers like Node.js operate on a single thread, executing one operation at a time. Node.js, being non-blocking and event-driven, can handle many concurrent connections with minimal overhead.

Conversely, multi-threaded servers like Java can execute multiple operations concurrently by initiating additional threads. This ability makes them more suitable for CPU-intensive tasks. However, the overhead associated with creating and managing threads can reduce efficiency when dealing with a large number of concurrent connections.

The Experiment

To illustrate the difference in performance between Node.js and Apache servers under high load, I've created simple servers using both languages.
These servers feature a single endpoint that calculates the 40th Fibonacci number, a CPU-intensive task.
We will use a load testing tool to simulate a high number of concurrent requests.

High Load Testing

High load testing is a form of performance testing that exposes a server or system to a workload nearing or exceeding its limit. It helps identify potential bottlenecks or performance issues under high stress conditions.

In our experiment, we'll use a benchmarking tool called Autocannon, capable of generating a high load by making numerous HTTP requests to a server.

The tools

autocannon

Autocannon is a Node.js-based benchmarking tool, supporting HTTP pipelining, HTTPS, and providing detailed performance statistics. Here's how to install Autocannon using npm:

npm install -g autocannon

To simulate a high load, we'll run Autocannon as follows:

This command means "send as many requests as possible to localhost:8080/ for 10 seconds, using 50 concurrent connections"

autocannon -c 50 -d 10 http://localhost:3000/

The number of request is depending on several factors , capacity of the network,response time of the server ,etc ...

Node.js Server

Here's the code for our Node.js server:

fibonacci.js 

const http = require('http');
const os = require('os');

function fibonacci(n) {
  if (n < 2)
    return 1;
  else
    return fibonacci(n-2) + fibonacci(n-1);
}

const server = http.createServer((req, res) => {
  const fibNumber = fibonacci(40); // This will take some time
  res.end(`Fibonacci result: ${fibNumber}`);
});

server.listen(3000, () => {
  console.log('Server listening on port 3000');
});

In this script, we create an Express server with a single route /fibonacci that calculates the 40th Fibonacci number.

run the server

node fibonacci.js

execute this command

autocannon -c 50 -d 10 http://localhost:3000/

The result is
Sent 100 requests , but it causes 41 timeouts.

Apache Server
FibonacciController.java

Here's the corresponding Java code using Spring Boot:

package com.example.demo;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class FibonacciController {
    @GetMapping("/")
    public String calculateFibonacci() {
        int fibNumber = fibonacci(40);
        return "Fibonacci result: " + fibNumber;
    }

    private int fibonacci(int n) {
        if (n <= 1) return n;
        else return fibonacci(n-1) + fibonacci(n-2);
    }
}

run the server

./gradlew bootrun

execute this command

autocannon -c 50 -d 10 http://localhost:8080/

The result is
Sent 162 requests , no timeouts.

Result

Here is the result of conducting this command for each server.

autocannon -c 50 -d 10 http://localhost:8080/

The result(Node) is
100 requests , but it causes 41 timeouts.

The result(Apache) is
162 requests , no timeouts.

From these result, we can draw conclusions in terms of 3 aspects.

Concurrency Handling: The single-threaded Node.js server struggled to handle the concurrent requests as efficiently as the multi-threaded Apache server. This is indicated by the 41 timeouts out of 100 requests, meaning 41% of the requests were not fulfilled within the given timeframe. This is likely due to the blocking nature of the CPU-intensive Fibonacci calculation, which prevents Node.js from efficiently handling other incoming requests concurrently.

Throughput: The multi-threaded Apache server was able to handle a higher number of requests (162 requests) within the same timeframe, and without any timeouts. This demonstrates that for CPU-intensive tasks, a multi-threaded server like Java can potentially have higher throughput compared to a single-threaded server like Node.js.

Resiliency: The Apache server appeared to be more resilient under high load, given that it didn't experience any timeouts. This suggests that for applications where high resiliency under load is important (especially for CPU-bound tasks), a multi-threaded server might be a more appropriate choice.

Conclusion

This experiment provides a clear illustration of how single-threaded and multi-threaded servers handle high load differently. However, it's important to note that neither model is universally better than the other. Node.js, with its event-driven, non-blocking model, excels at handling many concurrent connections, making it a great choice for real-time applications. Java, with its multi-threading capabilities, is often better suited for CPU-intensive tasks.

When choosing a technology stack for a server application, consider the specific requirements of our project, the expertise of your development team, and the strengths and weaknesses of the available technologies.

Building a CRUD App with Clean Architecture in Go

Mikiya Ichino — Sat, 06 May 2023 04:47:11 +0000

Introduction

In this article, I will create an API with CRUD (Create, Read, Update, Delete) functionality using Clean Architecture. I will use MySQL as our database, Echo as our framework, and GORM as our ORM.

What I Will Build

I will create an API with Create, Read, (Update), and Delete functionality. The Update function is not implemented yet, so feel free to add it yourself!

Target Audience

People who have set up a Go environment and want to create a simple API.

Technologies Used

What is Clean Architecture?

Clean Architecture is well known for the following diagram:

The purpose of Clean Architecture is the separation of concerns, which is achieved by paying attention to the dependencies between layers. This separation leads to improved code readability and a more robust design. For more information on the benefits and details of Clean Architecture, please refer to the reference articles.
In the above diagram, arrows point from the outer layers to the inner layers, indicating the direction of dependencies. Dependencies are allowed from the outer layers to the inner layers, but not vice versa.
In other words, you can call items declared in the inner layers from the outer layers, but you cannot call items declared in the outer layers from the inner layers.
In this article, I will introduce the code while paying attention to the direction of dependencies.

Endpoints

The endpoints for each function are as follows:

GET: /users POST: /users DELETE: /users/:id

Directory Structure

The layers of Clean Architecture can be aligned with the directory structure as shown below:

domain

In the domain layer, the Entity is defined. As it is at the center, it can be called from any layer.

/src/domain/user.go

package domain

type User struct {
    ID   int    `json:"id" gorm:"primary_key"`
    Name string `json:"name"`
}

In this example, I will create a User with an ID and Name column, with the ID set as the primary key.

Regarding json:"id" gorm:"primary_key", json:"id" is for JSON mapping, and gorm:"primary_key" is for tagging models in GORM. You can also define other SQL table properties such as not null, unique, and default.
Reference: GORM Declaring Model

Infrastructure

The outermost layer, Infrastructure, deals with the parts of the application that interact with external components. In this case, I define the database connection and router here.

Since it is the outermost layer, it can be called without being aware of any other layers.

/src/infrastructure/sqlhandler.go

package infrastructure

import (
    "gorm.io/driver/mysql"
    "gorm.io/gorm"

    "echoSample/src/interfaces/database"
)

type SqlHandler struct {
    db *gorm.DB
}

func NewSqlHandler() database.SqlHandler {
    dsn := "root:password@tcp(127.0.0.1:3306)/go_sample?charset=utf8mb4&parseTime=True&loc=Local"
    db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
    if err != nil {
        panic(err.Error)
    }
    sqlHandler := new(SqlHandler)
    sqlHandler.db = db
    return sqlHandler
}

func (handler *SqlHandler) Create(obj interface{}) {
    handler.db.Create(obj)
}

func (handler *SqlHandler) FindAll(obj interface{}) {
    handler.db.Find(obj)
}

func (handler *SqlHandler) DeleteById(obj interface{}, id string) {
    handler.db.Delete(obj, id)
}

For the database connection, the official documentation was helpful:
gorm.io

Next is routing. In this example, I use the Echo web framework. The official documentation was also helpful for this, and it is where I define our API methods and paths:
echo.labstack

/src/infrastructure/router.go

package infrastructure

import (
    controllers "echoSample/src/interfaces/api"
    "net/http"

    "github.com/labstack/echo"
)

func Init() {
    // Echo instance
    e := echo.New()
    userController := controllers.NewUserController(NewSqlHandler())

    e.GET("/users", func(c echo.Context) error {
        users := userController.GetUser() 
        c.Bind(&users) 
        return c.JSON(http.StatusOK, users)
    })

    e.POST("/users", func(c echo.Context) error {
        userController.Create(c)
        return c.String(http.StatusOK, "created")
    })

    e.DELETE("/users/:id", func(c echo.Context) error {
        id := c.Param("id")
        userController.Delete(id)
        return c.String(http.StatusOK, "deleted")
    })

    // Start server
    e.Logger.Fatal(e.Start(":1323"))
}

Interfaces

In the Controllers and Presenters layers, We need to be aware of dependencies.

Calling the domain and usecase layers from the interface layer is not a problem, but we cannot call the infrastructure layer directly. Instead, we define an interface (the sqlHandler interface defined in the infrastructure layer).

/src/interfaces/api/user_controller.go

package controllers

import (
    "echoSample/src/domain"
    "echoSample/src/interfaces/database"
    "echoSample/src/usecase"

    "github.com/labstack/echo"
)

type UserController struct {
    Interactor usecase.UserInteractor
}

func NewUserController(sqlHandler database.SqlHandler) *UserController {
    return &UserController{
        Interactor: usecase.UserInteractor{
            UserRepository: &database.UserRepository{
                SqlHandler: sqlHandler,
            },
        },
    }
}

func (controller *UserController) Create(c echo.Context) {
    u := domain.User{}
    c.Bind(&u)
    controller.Interactor.Add(u)
    createdUsers := controller.Interactor.GetInfo()
    c.JSON(201, createdUsers)
    return
}

func (controller *UserController) GetUser() []domain.User {
    res := controller.Interactor.GetInfo()
    return res
}

func (controller *UserController) Delete(id string) {
    controller.Interactor.Delete(id)
}

The controller calls the usecase and domain layers, which is not a problem.

src/interfaces/api/context.go

package controllers

type Context interface {
    Param(string) string
    Bind(interface{}) error
    Status(int)
    JSON(int, interface{})
}

Regarding the database:

src/interfaces/database/user_repository.go

package database

import (
    "echoSample/src/domain"
)

type UserRepository struct {
    SqlHandler
}

func (db *UserRepository) Store(u domain.User) {
    db.Create(&u)
}

func (db *UserRepository) Select() []domain.User {
    user := []domain.User{}
    db.FindAll(&user)
    return user
}
func (db *UserRepository) Delete(id string) {
    user := []domain.User{}
    db.DeleteById(&user, id)
}

In the repository, the sqlHandler is called, but instead of directly calling the infrastructure layer's sqlHandler, we call it through the sqlHandler interface defined in the same layer.
This is known as the Dependency Inversion Principle.

src/interfaces/db/sql_handler.go

package database

type SqlHandler interface {
    Create(object interface{})
    FindAll(object interface{})
    DeleteById(object interface{}, id string)
}

With this, we can call the sql_handler's functions.

usecase

Lastly, we have the usecase layer.

src/usecase/user_interactor.go

package usecase

import "echoSample/src/domain"

type UserInteractor struct {
    UserRepository UserRepository
}

func (interactor *UserInteractor) Add(u domain.User) {
    interactor.UserRepository.Store(u)
}

func (interactor *UserInteractor) GetInfo() []domain.User {
    return interactor.UserRepository.Select()
}

func (interactor *UserInteractor) Delete(id string) {
    interactor.UserRepository.Delete(id)
}

Here, as before, we need to apply the Dependency Inversion Principle, so we define user_repository.go.

src/usecase/user_repository.go

package usecase

import (
    "echoSample/src/domain"
)

type UserRepository interface {
    Store(domain.User)
    Select() []domain.User
    Delete(id string)
}

With this, our implementation is complete.
Now, by running MySQL using docker-compose.yml and starting the server, the API should work.

version: "3.6"
services:
  db:
    image: mysql:5.7
    container_name: go_sample
    volumes:
      # mysql configuration
      - ./mysql/conf:/etc/mysql/conf.d
      - ./mysql/data:/var/lib/mysql
    command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    ports:
      - 3306:3306
    environment:
      MYSQL_DATABASE: go_sample
      MYSQL_ROOT_PASSWORD: password
      MYSQL_USER: root
      TZ: "Asia/Tokyo"

src/server.go

package main

import (
    "echoSample/src/domain"
    "echoSample/src/infrastructure"

    "github.com/labstack/echo/v4"
    "gorm.io/driver/mysql"
    "gorm.io/gorm"
)

var (
    db  *gorm.DB
    err error
    dsn = "root:password@tcp(127.0.0.1:3306)/go_sample?charset=utf8mb4&parseTime=True&loc=Local"
)

func main() {
    dbinit()
    infrastructure.Init()
    e := echo.New()
    e.Logger.Fatal(e.Start(":1323"))
}

func dbinit() {
    db, err = gorm.Open(mysql.Open(dsn), &gorm.Config{})
    if err != nil {
    }
    db.Migrator().CreateTable(domain.User{})
}

Run Mysql

docker-compose up -d

Run Server

go run serve.go

Call API

POST: /users

curl --location --request POST 'localhost:1323/users' \
--header 'Content-Type: application/json' \
--data-raw '{
    "name":"J.Y Park"
}'
curl --location --request POST 'localhost:1323/users' \
--header 'Content-Type: application/json' \
--data-raw '{
    "name":"Eron Mask"
}'

GET: /users

curl --location --request GET localhost:1323/users'

It works!

Conclusion

By not only reading articles about Clean Architecture but also actually creating a simple API and testing its functionality, your understanding will deepen.
However, to be honest, the advantage of Clean Architecture might not be fully appreciated when working on a project of the CRUD app scale.
Clean Architecture not only improves code readability and productivity but also has the characteristic of being resistant to change. So, it would be nice to experience its benefits by adding various features to the app I created this time…!