[HttpServer series] Will it support the Performance, and Scale ?

Project No-Web-Framework-No-Annotations using Java (11 Part Series)

1 [HttpServer Series] Who uses Java anymore ?
2 [HttpServer Series] Frameworks, Annotations, and SpringBoot
… 7 more parts…
3 [HttpServer series] Will it support the Performance, and Scale ?
4 [HttpServer series] Setting up the dev environment
5 [HttpServer series] The fight of the GenAI tools – ChatGPT, Bard, CodyAI?
6 [HttpServer series] Getting Started – First context (endpoint)
7 [HttpServer series] Testing the server
8 [HttpServer Series] The Http Router – from scratch – in Java
9 [HttpServer Series] Router – improved – more tests
10 [HttpServer series] Static File server, and Logging
11 [HttpServer Series] Authentication and Role based Authorization (RBAC)

What about “scale” and “performance” ?

SpringBoot, and all other frameworks publicise the fact that they can handle tens of thousands of requests every second.

The applications I have worked with, and I am assuming this is true for most applications sitting on the internet, and the internal applications used companies, none have ever needed that kind of scale.

Even 100 requests per minute is a lot of load. Don’t manage to hit that many. Plus, if you really look at it, the whole “keep the cache warm” or “preload all the configuration” is good for large load applications. For the small ones, a few milli seconds do not matter.

So, I am willing to take the bet that holding data, and hence memory, may not be required. The JVM is really good at garbage collecting memory. So, lets use it to our benefit.

Also, if we do not maintain too much state, we can bank on functional programming, and scale out architecture, if we really start hitting performance. And, as is required by internal applications in the enterprises, the scale out gives us the high availability check mark.

I also rely on using docker compose . So, deploying more of light weight services in a docker swarm is easy. As is expanding the swarm dynamically.

The core assumption, at this time, since I do not know the end result, and am building this out as you, the reader, are reading it, is that my application is not internet scale. A few thousand transactions a day is as far as I will plan for.

But, maintenance of the application should be cheap, because, in all probability, we will revisit this application only a few times a year, in an optimistic situation. And every time will be a different set of eyes.

So, let’s get started, and explore the Http Server API next time, and see where we need to begin.

Project No-Web-Framework-No-Annotations using Java (11 Part Series)

1 [HttpServer Series] Who uses Java anymore ?
2 [HttpServer Series] Frameworks, Annotations, and SpringBoot
… 7 more parts…
3 [HttpServer series] Will it support the Performance, and Scale ?
4 [HttpServer series] Setting up the dev environment
5 [HttpServer series] The fight of the GenAI tools – ChatGPT, Bard, CodyAI?
6 [HttpServer series] Getting Started – First context (endpoint)
7 [HttpServer series] Testing the server
8 [HttpServer Series] The Http Router – from scratch – in Java
9 [HttpServer Series] Router – improved – more tests
10 [HttpServer series] Static File server, and Logging
11 [HttpServer Series] Authentication and Role based Authorization (RBAC)

原文链接：[HttpServer series] Will it support the Performance, and Scale ?