I’m mostly an infrastructure guy. I mostly fix C or identify bugs, and write integrations in Go or Python.
But I spend probably 50% of my time dealing with production problems due to this in Java business applications.
Nearly every client library in the Spring ecosystem has the worst of all possible defaults, and all internet code examples are “look at how easy X is” without anything around making it real.
Devs chuck code out without HTTP connection pooling or pipelining requests, let alone reasonable timeouts. Hikari has an awful default DB pooling config, and on and on. Inevitably it gets reported as “latency” when a quick look at [APM tool] shows all the time is spent waiting on a connection, or a stack trace shows which library chucked the timeout.
And often devs just bump connection pools higher when they see a bottleneck and there’ll be 1000 idle connections wasting DB resources and not helping the problem (inefficient query, missing index, etc).
I complain because the defaults here are masochistic. But there does need to be a cultural change where using a client or server library assumes a tuning exercise. And yeah, good testing would be great too.
There are no 1-size-fits-all values. You have to look at the use case and the SLOs of the app and it’s up and downstream dependencies. You don’t want optimizing a config in isolation to break a larger system either.
Software development is hard. It requires understanding. No language or library can solve that for this stuff. I just wish all of these libraries’ docs called that out up front vs projecting plug and play. It’s all there, but buried in the godoc for you to have to know what you’re looking for. Others are worse.
This is especially the case with http libraries, since it’s usually building a client or server object/whatever correctly and not just a config tweak you can slap in at 2am.
And back to the original point, when there are 12 implementations that can mean having to relearn this activity for each one. That said, if I’m using Go, that usually means building something with net/http and handing it to the library to use instead of the default. Other languages without that base layer baked in don’t get that advantage.
Back to Java/Spring: usually Catalina vs netty/Reactor Core are 2 totally different worlds and often dev teams don’t know which they picked or that they switched when they generated a new project and pulled their code in from Spring Boot 1.5 to 2.x.
But I spend probably 50% of my time dealing with production problems due to this in Java business applications.
Nearly every client library in the Spring ecosystem has the worst of all possible defaults, and all internet code examples are “look at how easy X is” without anything around making it real.
Devs chuck code out without HTTP connection pooling or pipelining requests, let alone reasonable timeouts. Hikari has an awful default DB pooling config, and on and on. Inevitably it gets reported as “latency” when a quick look at [APM tool] shows all the time is spent waiting on a connection, or a stack trace shows which library chucked the timeout.
And often devs just bump connection pools higher when they see a bottleneck and there’ll be 1000 idle connections wasting DB resources and not helping the problem (inefficient query, missing index, etc).
I complain because the defaults here are masochistic. But there does need to be a cultural change where using a client or server library assumes a tuning exercise. And yeah, good testing would be great too.
There are no 1-size-fits-all values. You have to look at the use case and the SLOs of the app and it’s up and downstream dependencies. You don’t want optimizing a config in isolation to break a larger system either.
Software development is hard. It requires understanding. No language or library can solve that for this stuff. I just wish all of these libraries’ docs called that out up front vs projecting plug and play. It’s all there, but buried in the godoc for you to have to know what you’re looking for. Others are worse.
This is especially the case with http libraries, since it’s usually building a client or server object/whatever correctly and not just a config tweak you can slap in at 2am.
And back to the original point, when there are 12 implementations that can mean having to relearn this activity for each one. That said, if I’m using Go, that usually means building something with net/http and handing it to the library to use instead of the default. Other languages without that base layer baked in don’t get that advantage.
Back to Java/Spring: usually Catalina vs netty/Reactor Core are 2 totally different worlds and often dev teams don’t know which they picked or that they switched when they generated a new project and pulled their code in from Spring Boot 1.5 to 2.x.