On 3/14/11 11:02 AM, Mike Matrigali wrote:
Given the limited feedback so far I don't think we should consider
the soft upgrade option. I would prefer first release with istat
defaulted off, but would not vote -1 if community thinks it is better
with it defaulted on.
Based on the amount of hesitation expressed about running istat by
default, I turned it off by default as of revision 1081416 (see DERBY-5131).
I also wanted to say that I do think the istat feature is a good one,
and what I am most concerned about is not bugs in istat.
My impression is that the code is pretty solid.
I am worried
about application impact of istat doing what it is designed to do, run
work in background. I just don't have a good feel whether defaulting
it on will cause problems in existing applications.
I think that it will unquestionably cause problems for some
applications. I do not see how it couldn't. When you turn on this
feature, a read-intensive thread is going to crop up from time to time.
In certain environments, it is bound to have performance impacts.
Moreover, the behavior will be event-driven and therefore hard to
predict. An existing application may regard this performance drag as a
regression, particularly if the application has already coded its own
workaround to the problem of Derby statistics skew.
On the other hand, statistics skew is a real problem for even modestly
sized, shrink wrapped, embedded Derby apps. I don't see a lot of
workarounds:
a) Code your own version of istat to periodically measure the freshness
of your statistics and regenerate them if necessary. If you are lucky
and your application enjoys regular offline periods, then your customers
may never experience the istat drag.
b) Add a button to your app with this mouseover: "Push me if you
experience sluggish performance. This might help."
c) Hire a DBA for your 0-admin app.
Also once we
release with it defaulted on, I think it is harder to change this
in the future.
Possibly so.
If apache supported betas, it would be great to release
this defaulted on.
Right. We don't have much luck when we appeal to our user community for
this kind of feedback. If you are worried about your own high profile
customers, you may be able to devise an in-house beta program.
I feel more comfortable about istat=on as the default for new
applications than as the default for old ones. Unfortunately, we have no
way of knowing whether an application is new or old--even old
applications create new databases and old databases can be re-used by
new apps.
My sense is that istat=on is the correct out-of-the-box experience,
while istat=off is a nice advanced feature for apps which enjoy low
intensity periods. But maybe my sense is merely idiosyncratic, based on
anecdotal evidence.
Thanks for pushing the discussion forward,
-Rick
