Not on techempower benchmarks?

[ibsusu]

So I know that this project is specifically for web sockets but the speed is also very much there for normal http. Why isn't it on techempower benchmarks?

[ghost]

Because tech empower are retards.

[ibsusu]

OK so I get what your saying but after reading what you've written inside of the benchmarks directory what they should be doing is stress testing each of the servers with enough input to ensure 100% CPU time which means no waiting on a DB or the NIC. My assumption would be that using a modified load_test.c that you have on more cores on the same machine than the server that's being tested would be the best way to truly find out which server was the best in terms of performance.

Yea or nay?

[ibsusu]

Obviously any confounding factors such as the db need to be separated from the metrics that we care about and be measured on their own.

[ibsusu]

I find this kinda funny. What you've essentially done is get uWebSockets to the point where it has as little overhead as possible versus the kernel networking stack itself but the more I think about it the more I realize that most people's clumsy attempts to utilize uWebSockets will go to waste. In my project I have to talk to the db, I have to write to disk and uws stays out of my way. It's always my crap that slows it down.

[ghost]

The nic is to the web server what the hdd is to the database; you can include them in your test but if those become the bottleneck you're not really measuring the database or the web server you're measuring hardware.

Software runs on CPU-time so if you want to isolate and measure the CPU-time overhead of the web server or database (such as algorithmic complexities, memory allocations, etc) you have to put the CPU-time as the bottleneck.

Sometimes you can do that easily, such as on the raspberry pi where CPU-time is naturally limited.

Tech empower puts their measurements on Intel gold server CPUs where no software will ever bottleneck on CPU-time so they pretty much the up measuring their Nic (which is a constant) so the only difference between the top 30 entries become random noise.

With databases you also have scheduling and packing to take into account but we're not talking about databases here.

[ghost]

Yes performance is always the weakest link of a chain. USING something fast doesn't MAKE everything fast it only unlocks the POTENTIAL to MAKE everything fast.