There is no way to get around the fact that the HTTP protocol adds overhead (serialization and parsing of additional data) at the application layer. Binary RPC protocols are faster, and that is why Redis uses one of those instead of HTTP. There is no debate about that, it is simply a set of trade-offs that balances out differently for different use cases.
Your confused too, resp is a text protocol. So is http. This isn't binary vs text protocol expermint. None of the http parsing should take seconds like this suggests.a simple protocol might be faster to handle but another post down below makes a similar point where something implented well can respond is micro seconds. Really all this shows is that handling text off a socket is faster then this http framework in eleixr
RESP can transfer raw binaries, the only overhead is a message length. In the TFA they are talking about using MessagePack for the payloads, so it is a binary protocol.
http transfers binary, what does that even mean? the only thing the message pack thing is used for is encoding the value in the requests. but all of that is irrelevant because thats not what i was talking about in the first place. the test is poorly done.
An average latency of 17ms to handle a simple request with the resp protocol is a red flag it self that something is wrong. Seconds to have an http response returned is a problem. All this article is showing is elixir and the libraries used are incredibly slow. Calling HTTP slow, based off the tests done in this article is just wrong, because the whole test is slow and not testing the right thing.
Micro bench marking of the parsing functions would be the right thing to do here.
really someone should profile the server and see what is taking seconds to respond. it wont be the parsing related functions
parsing http really isnt that big of a deal. its a simple protocol, the action on line one, headers split by : and the body. resp has a simmilar amount of work too, uses multiple lines
