The performance catch-22s:

• #1: A server must perform well enough for it to get use, but as soon as it gets used too much the performance begins to degrade. For new systems, you may have an idea what the bottle necks are, but you won't know until the server exists (in some sense).
• #2: You can throw a server together quickly, but it probably won't perform well over time. If you write a server that will perform well over time, it will be larger, complicated and difficult to maintain. (And critics will say that it should have been written in a faster language that has more design constructs. Not my words, their words...)
• #3: It's very difficult to go from something that works (albeit with lower performace) and make incremental enhancements to improve performance dramatically. Sure you can optimize loops and such, but in my experience an order of magnitude performance improvement requires a design change.

I'm in a similar position as the OP, but I haven't written my server yet. But I know for a fact that it's going to process more than 6 transactions per second, each transaction involves 3-6 individual database executions and some of those database executions takes more than 2 seconds.

I friend of mine uses the "Field of Dreams" movie as an example. The last scene shows this wonderful baseball diamond in a corn field & lots of people arriving in cars to watch baseball. What you don't see is the scene after that where all those cars are parked willie nillie in the corn, small mobs of people are looking for something to eat (other than corn), and, of course, more than a few looking for quiet spot (in the corn) to go to the bathroom.

Sorry, no answers, just some observations.