Performance

[franciscop]

At this stage performance is something not to worry about; however it is a future concern so this thread should work as a general guideline and plan. Server's big advantage has nothing to do with performance so as long as it's competitive performance-wise it's okay.

1. Usability >> performance.

2. Optimize only the slowest paths. No micro-optimizations that don't change the bottom line.

3. A bunch of it will probably come for free as V8 gets improved, notably on Promises-related code. See this.

The objective for 1.x is that server performs decently when compared with raw Express 4.0 (in which it's based). Right now it can perform 37.4% of the total requests that express can for a hello world example.

[joshmorel]

Hi @franciscop, I just came upon this project and am intrigued. However, can you help me understand, what exactly you mean by:

Right now it can perform 37.4% of the total requests that express can for a hello world example.

[franciscop]

Ah sorry, it means that when comparing performance, server.js can handle only 34.7% of the requests number per second when compared with raw express.js. Main reason is that there's some extra middleware.

[joshmorel]

That's what I thought, it just seemed like quite a big difference so I thought I'd ask.

But would I be correct in assuming the number of requests you were feeding express.js in this performance test was quite a lot higher than would be expected for a small or medium project (as per use cases identified in readme)?

[franciscop]

Sure! There are two things:

• If you are handling hundreds of requests per second it's no way a small to medium project and you probably know what you are doing.

• Rarely the framework is the limit anyway. The code that you or other users write is normally much slower than the framework, this was just a quick sanity test to see that it's in the same order of magnitude than express (which it is). User code can be fixed with caches at different levels and many other ways. I'd be really surprised if server.js was the performance bottleneck, though it could happen of course.

I had a project using server.js more heavily than normal (5 requests to the library/visit) on the main page of Hacker News without a problem (50% of CPU peak and it was mainly to parsing the HTML). So yeah, there's no problem with performance for those projects.