[Patient0]

"Before we used it in production, I performance tested it - HTTP is really slow"

Slow compared to what? direct memory access?

If you're going to say "HTTP is really slow" I contend you really probably meant "communication over a network is slow"...

[jeremyjh]

Well, he didn't express this very well, but I don't think he is quite that naive. Bytes move across a network media at the speed of light regardless of whether the electrons and pulses encode HTTP headers or not. And the latency of network layer switches and routers is similarly enencumbered by the presence of slashes in resource names. However, it is typical that HTTP-based client/server applications have more layers of serialization and a heavier payload that you'd find with a typical binary database protocol. Plus of course your HTTP server probably turns right around and talks to a database adding a whole extra layer of serialization and network data transport.

You are correct that this is not the case per-se, and I think there is an implication here that a lot of people really do not think very much about the massive overhead of serialization in general - instead they use a heuristic like "HTTP is slow". And while that heuristic does not capture an accurate model of the problem, it does often point in a direction that will prove fruitful as they grasp about blindly in possible solution spaces.

[seguer]

In contrast to direct database access, the HTTP implementation of the abstraction layer performed significantly worse. This will have also been part of the abstraction library having to parse/run the logic as well (nginx + PHP).

From memory, after trying the entire abstraction layer, I boiled it down to as small a file as possible for testing purposes (ie. a single PHP file that took the call and stored it into the DB, no configuration, removing as many "variables" as possible).

EDIT: Direct database access over the network.