db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: opinions on a less aggressive release of the istats feature?
Date Mon, 14 Mar 2011 19:41:56 GMT
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
>
>


Mime
View raw message