I don't know if anyone has seen a slowing in startup time in recent
months. I recall about a year ago we had startup down to about 25s.
These days my startup time is looking abysmal again. Approx 1 minute
between setting dhis2 home and beginning to execute the startup
routines. Is anyone else seeing this or just me?
I have certainly noticed the veeery sluggish startup of recent builds.
It makes DHIS2 Live much less attractive, unfortunately.
Knut
···
On Thu, Sep 16, 2010 at 6:51 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
I don't know if anyone has seen a slowing in startup time in recent
months. I recall about a year ago we had startup down to about 25s.
These days my startup time is looking abysmal again. Approx 1 minute
between setting dhis2 home and beginning to execute the startup
routines. Is anyone else seeing this or just me?
Also getting very irritating hibernate trace dump ">
orderByFragment(order-by) etc ". Seems to be related to this: Open Source at Atlassian
Yes, Bob. You are right in this issue. The reason of this one is that DHIS2 is during on development. Thus, when we could not avoid some of mistakes or fixing or changing the data model in it. Thought that, this problem can be resolve if and only if all of instances of DHIS2 (I meant the locale where is using this program) CAN BE USED the final version of it as a perspective synchronous.
In my opinion, Assuming that, ALL of end-users of DHIS2 who ALWAYS upgrade their DHIS2 installer whenever new version of DHIS2 is release. And then, we can remove all stuffs that are no longer available in DHIS2 anymore. With this way, think that the start-up can be improve for next release to be more faster than.
Thanks.
···
On Fri, Sep 17, 2010 at 12:11 AM, Knut Staring knutst@gmail.com wrote:
I have certainly noticed the veeery sluggish startup of recent builds.
It makes DHIS2 Live much less attractive, unfortunately.
My startup time on Tomcat is 29 seconds. The added 4 seconds is due to the change to using Spring annotations and classpath scanning (didn’t think of that but not such a big deal). For me it also takes more than a minute to start with Live. This was not the case previously. It would be good if we could sort this out.
It seems this happens on Linux only.
My startup time on Tomcat is 29 seconds. The added 4 seconds is due to the
change to using Spring annotations and classpath scanning (didn't think of
that but not such a big deal).
OK. I think that is good news ie. it can be made to start in approx 29s
For me it also takes more than a minute to
start with Live. This was not the case previously. It would be good if we
could sort this out.
Is this live on linux or also live on windows? Or was your reference
to Linux above a typo?
···
2010/9/16 Lars Helge Øverland <larshelge@gmail.com>:
Seems we can check the Live package out of the case…
I checked out revision 1412 and built both Live and WAR. Started in 29 sec. I then ran the latest Live with the old (r1412) WAR and it started in 29 sec too. The latest Live and latest WAR starts in 1 min 45 sec. So there’s got to be something with the WAR file…
the main difference is that the live version runs with exploded war.
this was to improve startup time on old machines - which it really
did.. It might well be this is now working against us. not sure how
but its the main factor i can think of.
···
2010/9/16 Lars Helge Øverland <larshelge@gmail.com>:
Seems we can check the Live package out of the case....
I checked out revision 1412 and built both Live and WAR. Started in 29 sec.
I then ran the latest Live with the old (r1412) WAR and it started in 29 sec
too. The latest Live and latest WAR starts in 1 min 45 sec. So there's got
to be something with the WAR file...
I have tracked the problem of slow starting of Live on linux to somewhere between revision 1818 and 1823. Here we upgraded Spring from 2 to 3 and Struts from 1.6 to 1.8.1. Also, Abyot merged in work on sections from his branch.
I have disabled Spring classpath scanning for components. (We still have autowiring of dependencies/components enabled, but the components must be defined in the xml config). This cut the startup time with 10 seconds but didn’t really solve the underlying problem, and the startup is still too slow, around 1 min 25 sec.
wow… that is loongggg.
I have been doing all the stuff on Live using my 2.0.4 indian modules and it starts in ~25 seconds and switching or blank database happens in 16secs… and was super happy with the speed
I have tracked the problem of slow starting of Live on linux to somewhere between revision 1818 and 1823. Here we upgraded Spring from 2 to 3 and Struts from 1.6 to 1.8.1. Also, Abyot merged in work on sections from his branch.
I have disabled Spring classpath scanning for components. (We still have autowiring of dependencies/components enabled, but the components must be defined in the xml config). This cut the startup time with 10 seconds but didn’t really solve the underlying problem, and the startup is still too slow, around 1 min 25 sec.
wow… that is loongggg.
I have been doing all the stuff on Live using my 2.0.4 indian modules and it starts in ~25 seconds and switching or blank database happens in 16secs… and was super happy with the speed
wow… that is loongggg.
I have been doing all the stuff on Live using my 2.0.4 indian modules and it starts in ~25 seconds and switching or blank database happens in 16secs… and was super happy with the speed
Can’t really believe it but it seems Spring auto-wiring was the problem. Disabled it and went back to normal XML based wiring and Live now starts in 26 seconds at my Ubuntu laptop.
Have committed the change to 2.0.5 branch, will merge into trunk when I have time.
Can’t really believe it but it seems Spring auto-wiring was the problem. Disabled it and went back to normal XML based wiring and Live now starts in 26 seconds at my Ubuntu laptop.
It seems the bean factory doesn’t cache anything by type [1], so I guess by type-autowiring might be expensive on our (apparently) large context. It’s been a long time since I looked at the details of spring contexts, but I suspect there are no easy solutions to this.
I guess xml is fine (and name-based auto wiring should also be quick?).
Have committed the change to 2.0.5 branch, will merge into trunk when I have time.
I think India testing is done in trunk, so please merge it in there
Can’t really believe it but it seems Spring auto-wiring was the problem. Disabled it and went back to normal XML based wiring and Live now starts in 26 seconds at my Ubuntu laptop.
It seems the bean factory doesn’t cache anything by type [1], so I guess by type-autowiring might be expensive on our (apparently) large context. It’s been a long time since I looked at the details of spring contexts, but I suspect there are no easy solutions to this.
I guess xml is fine (and name-based auto wiring should also be quick?).
Yes we can live very well with plain XML wiring.
Have committed the change to 2.0.5 branch, will merge into trunk when I have time.
I think India testing is done in trunk, so please merge it in there
Will do.
···
On Mon, Sep 20, 2010 at 7:26 AM, Jo Størset storset@gmail.com wrote:
