Thanks for your suggestion. I couldn't believe it myself but it is true. "Basic" rust with standard sockets etc. seems to be that slow.
I have not tried tokio or something like that because I wanted it to be an equally unfair contrived comparison. Unfair because I am comparing basically the performance of an optimized C framework with super basic example servers. Contrived because I tested the timing of canned responses.
Have a look at them on GitHub, it's all there. I wanted to compare against a basic python SimpleHttpServer to get an idea for basic python performance. I compared against a standard basic Go implementation to see how zap compares to that. Just to get an idea if zap is 10x slower or if it can keep up.
Why I did it that way?
a) because it was simple
b) because I wanted to compare what you can do with the most simple zap server vs. the most simple python server vs the most simple Go server. If you don't know what to pick, this is maybe how you'd start evaluating. Then with rust, as I said, I literally went by the book. Made sure number of threads etc. is equal to the zap example. It just didn't want to perform that well.
So far, the question isn't answered why the rust example straight out of the book seems comparably slow - but I guess nobody uses such simple servers in the real world anyway when there's stuff like tokio out there.
I fully understand that there are faster python servers, probably faster Go servers, and certainly extremely fast rust servers out there. So for a fair "which is fastest" comparison, you'd have to check out some fastest server list, build them, build respective meaningful "apps" (as opposed to: contrived) and test against them. Then also build them in the ever evolving zap and see how it performs. I am happy with seeing responses in the us range on my dev PC when testing my frontends against a zap backend. That's the kind of performance I was looking for. I am sure there's faster stuff out there.
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for your suggestion. I couldn't believe it myself but it is true. "Basic" rust with standard sockets etc. seems to be that slow.
I have not tried tokio or something like that because I wanted it to be an equally unfair contrived comparison. Unfair because I am comparing basically the performance of an optimized C framework with super basic example servers. Contrived because I tested the timing of canned responses.
Have a look at them on GitHub, it's all there. I wanted to compare against a basic python SimpleHttpServer to get an idea for basic python performance. I compared against a standard basic Go implementation to see how zap compares to that. Just to get an idea if zap is 10x slower or if it can keep up.
Why I did it that way?
a) because it was simple
b) because I wanted to compare what you can do with the most simple zap server vs. the most simple python server vs the most simple Go server. If you don't know what to pick, this is maybe how you'd start evaluating. Then with rust, as I said, I literally went by the book. Made sure number of threads etc. is equal to the zap example. It just didn't want to perform that well.
You can find all the source code here.
So far, the question isn't answered why the rust example straight out of the book seems comparably slow - but I guess nobody uses such simple servers in the real world anyway when there's stuff like tokio out there.
I fully understand that there are faster python servers, probably faster Go servers, and certainly extremely fast rust servers out there. So for a fair "which is fastest" comparison, you'd have to check out some fastest server list, build them, build respective meaningful "apps" (as opposed to: contrived) and test against them. Then also build them in the ever evolving zap and see how it performs. I am happy with seeing responses in the us range on my dev PC when testing my frontends against a zap backend. That's the kind of performance I was looking for. I am sure there's faster stuff out there.