I am +0 for the release in the current state. H2 file system performance is know to be an issue in general, but I don't see how a single widget can take that long to pull from the database.
That being said, it is still a 0.xx release, and it seems to be fine in MySQL. Sent from a mobile device -----Original Message----- From: Ate Douma [[email protected]<mailto:[email protected]>] Sent: Wednesday, October 31, 2012 08:17 PM Eastern Standard Time To: [email protected] Subject: Re: [DISCUSS] performance issues and the 0.17 release target As already reported on RAVE-838, it seems H2 is the real culprit for the performance issue. Even while we can/should improve on our logic to reduce the number of times we (re)instantiate the same persistent object during a single request, using MySQL instead of H2 bring the performance back to acceptable level. Although H2 is our default embedded database, I don't think this problem should be a release blocker. Of course we must provide proper release notes informing the community about this issue with H2, but as I expect/hope nobody uses H2 for real, this shouldn't be a show stopper for anyone. So, I propose to proceed with the 0.17 release, meaning going for option a) below. Because it already is rather late here (Europe), I will start on this tomorrow morning my time, assuming lazy consensus. If anyone thinks different, please chime in. Regards, Ate On 10/31/2012 06:11 PM, Chris Geer wrote: > On Wed, Oct 31, 2012 at 10:02 AM, Ate Douma <[email protected]> wrote: > >> Hi all, >> >> As you all might have noticed, after the model-split branch merge, I've >> encountered a major performance degrading, at least in my standard Rave >> trunk build environment. More details about this in RAVE-838 where Chris >> and Matt also have chimed in on the discussion so far. >> >> The question I need to raise is: how should we deal with this while the >> 0.17 release target is or was planned for today? >> >> IMO we have about 4 options to choose from: >> >> a) The performance issues turn out to be either easily fixable or else not >> reproducible (enough) for this to be a show stopper: 0.17 release can >> continue as planned, maybe with only a slight (1 day max) delay to properly >> verify this. >> >> b) The performance issues are serious enough to warrant fixing first, but >> can be done on short notice, delaying the 0.17 release but no more than 2 >> days (e.g. Friday the latest) >> >> c) The performance issues are serious and cannot be fixed properly before >> end of the week. However it is important* to have the 0.17 release done >> anyway, in which case the community needs to be informed that this release >> isn't really usable other than for development purposes. For example, we >> could postfix the release version like 0.17-dev. >> * Why might a 0.17 release be desired, even with serious performance >> issues? >> - Because it allows completing and verifying *other* 0.17 features, even >> if only in a development environment >> - because it is desirable to have a new release ready before ApacheCon >> EU, for the community as well as for Rave specific presentations, e.g. for >> Matt's and/or my own presentation. However: I'm also considering >> temporarily downgrading the current Rave content services sandbox to use >> Rave 0.16 instead, so *for me* this might not be important, even if less >> ideal. >> >> d) The performance issues are serious and doing the 0.17 release *now* >> isn't that critical, so simply skip the release this month and re-schedule >> 0.17 release for next month (no need to 'drop' the 0.17 version IMO). >> > > e) Back out the model-split branch merge, fix any issues on the branch then > remerge in the future. > >> >> As I just commented on RAVE-838, I'll do some more testing (with MySQL >> instead of H2 database) later this evening. >> >> Besides that, I'd appreciate if others also can verify and report their >> own performance experience with the current trunk, and provide some >> feedback and opinion on the options I gave above. >> >> Thanks, Ate >> > > I would vote for a or b, but those depend on other input of impact from > other users. Based on input so far, c seems risky to me because there is no > way to know if the majority of people will have my performance or Ate's. > Under normal circumstances, d would be a decent choice but with ApacheCON > EU coming up I'm not sure it's good now. Choice e isn't my first choice but > it's technically a choice and can be done if people think it's the best > option. > > Chris >
