SaltyAom / bun-http-framework-benchmark

Compare throughput benchmark from various Bun HTTP framework
349 stars 30 forks source link

Update Hono (bun) impl. for 20% speed boost #59

Open redbar0n opened 5 months ago

redbar0n commented 5 months ago

For example, Hono on Bun looks like it performs badly. But just go to src/bun/hono.ts and change the export to export default { ...app, host: '127.0.0.1' } (instead of export default app) for an instant 20% speed boost that puts it right up, near the top.

according to https://github.com/hattipjs/hattip/issues/114#issuecomment-1884846698

redbar0n commented 3 months ago

Benchmarks should use 127.0.0.1 (IPv4) instead of the name 'localhost', due to potential IPv6 overhead or conflict: don't use localhost (intermediate) anthony explains (4 min).

SaltyAom commented 3 months ago

I agree with the benchmark of 127.0.0.1 benchmark part, but disagree with the hattip part:

For example, Hono on Bun looks like it performs badly. But just go to src/bun/hono.ts and change the export to export default { ...app, host: '127.0.0.1' } (instead of export default app) for an instant 20% speed boost that puts it right up, near the top.

Basically, in any server more complex than hello world app, you are likely going to implemented either reverse proxy, micro-service or load balancing for multiple endpoint, eg. staging:

Setting the host ahead of time rejects all of the above implementation.

Additionally, the 20% speed boost is not only limited to Hono, but Elysia, Stric, Vixeny and most frameworks are going to benefit the speed boost as well since the hostname is known ahead of time, we can just omit the hostname entirely.

But we assume that the API staging or load balancing / reverse proxy will be implemented, that optimization doesn't match the real use case.

redbar0n commented 3 months ago

@cyco130

cyco130 commented 3 months ago

Setting the host ahead of time rejects all of the above implementation.

That was my point actually. When I ran the tests a couple of months ago, some of the tested frameworks assumed a certain host name (vixeny's hasName, stricjs's base etc.) which gave them an unfair advantage. Setting the host gives the same advantage to Hono. You can (and should) also go about the other way and disable those optimizations in those frameworks.

SaltyAom commented 3 months ago

Didn't realize Stric and Vixen hardcode basename. Alright, going to remove the basename and rerun the benchmark right now, thanks.

redbar0n commented 3 months ago

@SaltyAom Would be awesome if you could update the README with the new bench results. It currently says Tested on 18 Mar 2024 19:30 (GMT+7)

mimiMonads commented 1 month ago

Setting the host ahead of time rejects all of the above implementation.

That was my point actually. When I ran the tests a couple of months ago, some of the tested frameworks assumed a certain host name (vixeny's hasName, stricjs's base etc.) which gave them an unfair advantage. Setting the host gives the same advantage to Hono. You can (and should) also go about the other way and disable those optimizations in those frameworks.

@redbar0n

Hello, I was looking at issues and I stumble upon this conversation, the reason why I added hasName (base.bind in the beta version) is for vixeny-create where I use it as a default point of reference, I'm removing it and I will talk to Reve to see if he can do the same.

It should be fixed by the next benchmark sorry for the trouble xd.

aquapi commented 1 month ago

@redbar0n Stric was abandoned for a while. I will remove Stric and add my new tools.

aquapi commented 1 month ago

71