> What worries you about the 100K number and what would a better number be? I can't imagine the point. The whole architecture just sounds ridiculous. > Alter

> What worries you about the 100K number and what would a better number be? I can't imagine the point. The whole architecture just sounds ridiculous. > Alternatively it's 100 servers with a connection pool of 1,000 each. 100 app servers isn't excessive and if you're doing less than 10K concurrent on each of them then there's other profiling opportunities to be had there. Even 100 app servers is stupid. 4 second response time is stupid. Just build two big ones. I can handle (low) tens of trillions of queries per day on a single box (low µs response time, pipelined) -- and the only reason I even need two is because one might die for uncontrollable hardware reasons. The only reason I ever buy more servers than two is because I want geographic diversity, and I can cover the world with ads with around 10 pops. I can't imagine having 100k pops sending MySQL queries to a single place. So yeah: I would really want to hear the use-case here. One time I met a company who insisted they were sending tens of TB of data per day and would need multi-PB per year storage compressed. Took one look at the data: All json, all GUIDS and bools. If we just pre-parse it, the entire dataset for a year fits in a few 100s GB uncompressed -- literally could fit on a macbook air for most of the year. Absolutely insane the kind of build-out people do to "win" at numbers that don't matter...