3 ms·

Eeesh. You can't say the Internet won't tell you when you're wrong. My ignorance of SQL really shows. While I still think that post has some valid points and I

Eeesh. You can't say the Internet won't tell you when you're wrong. My ignorance of SQL really shows. While I still think that post has some valid points and I stand by the idea of benchmarking DBs around hitting a webserver that's actually doing something, the numbers for PostgreSQL are completely wrong. With connection pooling I see > 1500 req/s. I couldn't find out how to setup connection pooling for MySQL so I'm still looking into that (there is an advantage to being concurrent by default but I suppose that's the bias of the older dbs). Also it's seems my CouchDB example might be flawed in that the connections (single HttpClient doing all the work, not a multithreaded one) are the bottleneck there as well. I'm curious to see how that plays out. Anyways I admit my mistake. Thanks HN for the schooling :D

jchrisa 16y ago
Connection pooling only helps if you have a limited # of clients running on machines you control. In a maximum-scaled-out situation, you're gonna have eg hundreds of physical app servers so connection pooling is gonna make a difference, but only in individual client latency. In the CouchDB case your clients might even be remote web-browsers and while some of them might use keep-alive, with real traffic most clients will be requesting just a couple of resources anyway, so again, connection-pooling / keep-alive is only going to make a small difference. Not saying that you shouldn't try another benchmark with more efficient resource utilization, but at some point (hopefully) these databases all become disk-bound.