Then on Monday I got an email from the person who controls production, and he said, "I see that increasing threads really helped the overall user performance. Is that it? Can we just do that again?"
That's a complicated question. Performance, you see, is almost always a multifactor problem. Changing one thing rarely helps as much as changing several things to work together better. There's also the fun question of whether you should be working on improving performance.
Can I improve performance? Almost always, yes.
Should I improve performance? Maybe.
Performance improvements on an application is a matter of balancing the benefit versus the cost.
- happier customers!
- more efficient use of resources
- potential scalability improvements
- Adding resources - a common and valid performance improvement technique - costs real dollars
- You don't get as many features (since engineering is making it faster, not do more stuff)
- Highly optimized code and systems may be less flexible and harder to use (translation: slower development time)
That's the dirty little secret of performance: you can almost always be faster if you're willing to pay more. At some point, you need to decide to stop, that more performance isn't worth the cost. So have fun with performance. Make it faster. Make it better. Look in several places and get some more speed (or scalability or load) out of your app. But watch your costs, and when you're paying more than the benefit you're getting, stop.