Re: Database market share 2004
Posted in 2005
Topics: Performance & Tuning, Java & JDBC Development
DA Morgan wrote: > There is another important reason too: Instrumentation. If they are > slow diagnosing why is a question of making guesses. That may be a > reasonable approach when supporting a small non-commercial web site. > It is a non-starter when talking terabytes and a requirement for 7x24. A rather depressing thought is that the reason many of these open source platforms are gaining popularity are a general and widespread lack of understanding of the essentials of performance engineering. That eyeballing utilization and ratios are enough. Part of my job is to firefight important projects that use my employer's technology (BEA). I find the "task forces" are formed with the various vendors and don't actually wind up finding the problem -- they just look under their own rock, and give the thumbs up, and point fingers to the other guy. It's hard to get a disciplined focus on the end-to-end service and wait times. Usually when I come in, I find the problem is "good J2EE 101" or "good Oracle 101"; stuff that Tom Kyte has pointed out for years: Java developers not using bind variables, developers building extremely chatty systems (18 small round trips instead of 1 larger one), lack of statement caches to avoid parsing, not collecting statistics regularly and properly, etc. And management, desperate to show some kind of action to their executives, just decide to add hardware. I can't blame them, though they usually are aghast when I'm brought in and suggest that this may even make the situation worse. I look at the MySQL's and JBoss' of the world, and I see a focus on a particular audience of developers whose itches are being scratched: the shiny, stylish, and inexpensive environment that requires "just enough" in-depth knowledge to keep the developer around to run the thing. But when problems creep up outside their domain, all hell breaks loose. Cheers Stu
Stu Charlton wrote: > DA Morgan wrote: > > >>There is another important reason too: Instrumentation. If they are >>slow diagnosing why is a question of making guesses. That may be a >>reasonable approach when supporting a small non-commercial web site. >>It is a non-starter when talking terabytes and a requirement for 7x24. > > > A rather depressing thought is that the reason many of these open > source platforms are gaining popularity are a general and widespread > lack of understanding of the essentials of performance engineering. > That eyeballing utilization and ratios are enough. > > Part of my job is to firefight important projects that use my > employer's technology (BEA). I find the "task forces" are formed with > the various vendors and don't actually wind up finding the problem -- > they just look under their own rock, and give the thumbs up, and point > fingers to the other guy. It's hard to get a disciplined focus on the > end-to-end service and wait times. > > Usually when I come in, I find the problem is "good J2EE 101" or "good > Oracle 101"; stuff that Tom Kyte has pointed out for years: Java > developers not using bind variables, developers building extremely > chatty systems (18 small round trips instead of 1 larger one), lack of > statement caches to avoid parsing, not collecting statistics regularly > and properly, etc. And management, desperate to show some kind of > action to their executives, just decide to add hardware. I can't blame > them, though they usually are aghast when I'm brought in and suggest > that this may even make the situation worse. > > I look at the MySQL's and JBoss' of the world, and I see a focus on a > particular audience of developers whose itches are being scratched: the > shiny, stylish, and inexpensive environment that requires "just enough" > in-depth knowledge to keep the developer around to run the thing. But > when problems creep up outside their domain, all hell breaks loose. > > Cheers > Stu Precisely duplicates my experiences. -- Daniel A. Morgan http://www.psoug.org damorgan@x.washington.edu (replace x with u to respond)