|
Too much is when page generation time gets sluggish, like Joder said, or when you're gathering information you don't need.
If optimal performance is your goal, then there isn't a limit to the number of queries you perform. There's a limit, but it's how long your users will wait; more users at the same time gives you much less leeway. But the # of sql executions contributes to slowness less than other things you're able to control. You could put all of your information together in one huge table, and then write a single query, select * from mytable, and bring the system to its knees. You could run 25 finely tuned queries that pull back as few columns and rows as possible, that exploit indexes, and leave the formatting to the web server, and be fine. Two things come to mind:
If you query some info about the current user each time they request a page, for your navigation, this is a great candidate for caching. Put the information you need for your page in a session variable, ideally after formatting it. Update the cache when the user makes a change in their control panel.
If you're worried that moving out of beta into production will break the system, you should load test it.
|
