Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Framework Benchmarks

techempower.com

Post reply on HN
Print view View original

31–40 of 116 posts

Re: Web Framework Benchmarks

#31

Post by lllr_finger »

onion2k wrote: post #15

These are fun benchmarks, but every single framework in the top 250 or so is more than fast enough for most apps. Even the slowest in the list manages 366/requests per second, which is probably enough to prove an idea before optimizing for speed. We're approaching the point where speed is essentially a solved problem unless you're at Google-scale.

Is it? Concurrent connection handling at scale is a major problem, and plenty of Fortune 1000 companies would jump at the chance to have even 5% fewer instances deployed.

366 rps in a test scenario doesn't scratch the surface of what I need, and I'm not doing anything I'd consider crazy scale. When you need to support hundreds of thousands of rps, small improvements can be very noticeable.

Re: Web Framework Benchmarks

#32

Post by bpicolo »

dorfsmay wrote: post #30

It looks like the bottleneck here is the database driver (or possibly ORM when used). The plaintext test shows a very different picture: https://www.techempower.com/benchmarks/#section=#section=dat... PS: As a side note, I do not like golang, my focus has been on python and now rust, but I am very impressed by both the plaintext and the DB test!

The bottleneck on plaintext appears to potentially be physical network bandwidth.

https://github.com/TechEmpower/FrameworkBenchmarks/issues/35...

Re: Web Framework Benchmarks

#33

Post by narrator »

One thing I've noticed is that all the fastest implementations now run PostgreSQL. For the longest time MySQL was thought to be faster, so I guess PostgreSQL really caught up recently. I'm seeing it be the default database in a lot of new open source projects.

Re: Web Framework Benchmarks

#35

Post by bpicolo »

lllr_finger wrote: post #31
onion2k wrote: post #15

These are fun benchmarks, but every single framework in the top 250 or so is more than fast enough for most apps. Even the slowest in the list manages 366/requests per second, which is probably enough to prove an idea before optimizing for speed. We're approaching the point where speed is essentially a solved problem unless you're at Google-scale.

Is it? Concurrent connection handling at scale is a major problem, and plenty of Fortune 1000 companies would jump at the chance to have even 5% fewer instances deployed. 366 rps in a test scenario doesn't scratch the surface of what I need, and I'm not doing anything I'd consider crazy scale. When you need to support hundreds of thousands of rps, small improvements can be very noticeable.

> plenty of Fortune 1000 companies would jump at the chance to have even 5% fewer instances deployed.

Becoming a Fortune 1000 company isn't "most apps"

Re: Web Framework Benchmarks

#36

Post by smoe »

onion2k wrote: post #15

These are fun benchmarks, but every single framework in the top 250 or so is more than fast enough for most apps. Even the slowest in the list manages 366/requests per second, which is probably enough to prove an idea before optimizing for speed. We're approaching the point where speed is essentially a solved problem unless you're at Google-scale.

I agree with the overall sentiment. Plus almost all cases I run into performance issues with e.g. Python in general web development, that main problems were how the code was written, not what it was written in and being bottle-necked by the database.

That said I disagree a bit with saying it is a a solved problem unless you are Google-scale. In developing countries if you are in a small company without big investors, you need to do quite a bit more juggling with infrastructure budgets once you are past MVP compared to for example where I'm from Switzerland.

Re: Web Framework Benchmarks

#37

Post by basejumping »

akmittal wrote: post #23
tigershark wrote: post #17

Earlier quoted context omitted.

Vertx in Java is basically the fastest across all the benchmarks, putting it in the same speed/productivity bucket as node doesn’t make much sense...

I was talking about the compromise, if node is slower it provides better productivity.

Why would a experienced java dev be less productive than a node js one?

Re: Web Framework Benchmarks

#38

Post by pjmlp »

akmittal wrote: post #13
bilbo0s wrote: post #7

I had not checked these for a good long while. (Probably around round 10 or 11.) Looking back in on it now, holy MAN! C (C++) and Java. Wow. Even though I'm old, I'd sort of forgotten how speedy they can be. It's strange, because I actually work with Java and C in making streaming game engines. And you kind of get used to thinking in terms of millions on a set of hardware. So you think Java and C are slow. Then you r…

I'm not sure how many companies use C, C++ for Web development. In my opinion C/C++ wont be good idea to use for most. It is about choosing the best ration b/w tool speed and developer speed(productivity). There are very few companies which requires million per second request. For me Java, C#, Go, Node provide the best compromise b/w speed and productivity.

Most companies that sell embedded hardware managed remotely by Web interfaces.

Re: Web Framework Benchmarks

#39

Post by nicoburns »

Spartan-S63 wrote: post #20
christophilus wrote: post #12

Earlier quoted context omitted.

> Anything other than C or Java really Rust, C#, and Go also seem to fit the bill, according to these benchmarks. C# particularly has rocketed up since the last time I looked in depth at these. Pretty impressive work from the .NET Core folks, I'd say.

For Rust, I'm interested to see what the future holds once the community coalesces around an async IO interface. Additionally, when procedural macros stabilizes (for real), the possibilities for ergonomic frameworks in Rust become endless. Rocket has been really interesting to work with, but it only works on nightly since it relies on experimental codegen/procedural macro features. Once procedural macros stabilizes,…

> I think there's a future where Rust web frameworks are as expressive as Rails or Laravel but bring type safety and sound, zero cost abstractions to the table.

I'm really looking forward to this. The only thing I worry about is compile times. I hope they don't end up ruining an otherwise perfect solution!

Re: Web Framework Benchmarks

#40

Post by pjmlp »

bilbo0s wrote: post #7

I had not checked these for a good long while. (Probably around round 10 or 11.) Looking back in on it now, holy MAN! C (C++) and Java. Wow. Even though I'm old, I'd sort of forgotten how speedy they can be. It's strange, because I actually work with Java and C in making streaming game engines. And you kind of get used to thinking in terms of millions on a set of hardware. So you think Java and C are slow. Then you r…

Something that I learned after being part of a startup back when doing web servers in Tcl was cool (AOLServer and such), and Zope was hip, was that I never wanted to work again in software stacks that lacked a JIT or AOT compiler for production code.
Post reply on HN