You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Neale Rudd <ne...@metawerx.net> on 2012/04/14 07:43:04 UTC
TomEE startup performance
Hi Guys,
Could someone explain in some more detail what exactly causes the slower startup time in TomEE compared to Tomcat?
I imagine it's parsing classes, annotations etc.. but haven't looked at that area of the code too much yet.
One thing I've noticed in our testing, is that it seems to be mostly single-threaded, sitting at 100% on one core for most of the startup, which of course is painful on multi-core low-Ghz CPUs. Perhaps there could be a -D flag to specify the number of threads to use for doing whatever it's doing, like Java with it's ParallelGC threads.
The startup time should be reduced at the cost of higher initial CPU load. Ideas?
Best Regards,
Neale Rudd
Re: TomEE startup performance
Posted by Romain Manni-Bucau <rm...@gmail.com>.
typically xbean scan all "configured" classpath (the archive passed as
parameter to the constructor)
we have a custom annotation finder where the find method returns when it
matches an item (it doesnt finish the scan). It is used to detect a module
type (webapp, jar, ...) for instance. We use it to answer to the question
"does it contains this annotation?". At this moment we don't care about the
full scan.
- Romain
2012/4/15 Neale Rudd <ne...@metawerx.net>
> Yes, I'm seeing the xbean call waiting in most of the stack traces during
> the long startup.
>
> What do you mean by yours is a fail-fast one? Does is it revert to the
> xbean one if something goes wrong? What kind of things can cause that to
> happen? Or is it an option to use your one instead of the xbeans one?
>
> Most of the stack traces show calls in progress to jar verification so
> that's what I'm looking at.
>
>
> Best Regards,
> Neale
>
>
> ----- Original Message ----- From: "Romain Manni-Bucau" <
> rmannibucau@gmail.com>
> To: <us...@openejb.apache.org>
> Sent: Monday, April 16, 2012 2:20 AM
>
> Subject: Re: TomEE startup performance
>
>
> yep, the scanning on big apps is the place to optimize. that's why we
>> created the scan.xml file.
>>
>> that part is in xbean (subproject of geronimo) and it should be optimized
>> there, not in openejb (even if some bridge can let us do it in openejb if
>> we dont want to wait).
>>
>> the parallel scanning is dangerous and can lead to a lot of LinkageError
>> in
>> particular when we'll be ready to run on java 7 (still some work to do).
>>
>> what could maybe be done is to parallelize the scanning by jar (1
>> thread/jar max is a good rule i think). If you want to have a try maybe
>> look the AnnotationFinder class (ours and the xbean one, the difference is
>> our one is a fail fast one).
>>
>> - Romain
>>
>>
>> 2012/4/15 Neale Rudd <ne...@metawerx.net>
>>
>
>
Re: TomEE startup performance
Posted by Neale Rudd <ne...@metawerx.net>.
Yes, I'm seeing the xbean call waiting in most of the stack traces during
the long startup.
What do you mean by yours is a fail-fast one? Does is it revert to the
xbean one if something goes wrong? What kind of things can cause that to
happen? Or is it an option to use your one instead of the xbeans one?
Most of the stack traces show calls in progress to jar verification so
that's what I'm looking at.
Best Regards,
Neale
----- Original Message -----
From: "Romain Manni-Bucau" <rm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Monday, April 16, 2012 2:20 AM
Subject: Re: TomEE startup performance
> yep, the scanning on big apps is the place to optimize. that's why we
> created the scan.xml file.
>
> that part is in xbean (subproject of geronimo) and it should be optimized
> there, not in openejb (even if some bridge can let us do it in openejb if
> we dont want to wait).
>
> the parallel scanning is dangerous and can lead to a lot of LinkageError
> in
> particular when we'll be ready to run on java 7 (still some work to do).
>
> what could maybe be done is to parallelize the scanning by jar (1
> thread/jar max is a good rule i think). If you want to have a try maybe
> look the AnnotationFinder class (ours and the xbean one, the difference is
> our one is a fail fast one).
>
> - Romain
>
>
> 2012/4/15 Neale Rudd <ne...@metawerx.net>
Re: TomEE startup performance
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yep, the scanning on big apps is the place to optimize. that's why we
created the scan.xml file.
that part is in xbean (subproject of geronimo) and it should be optimized
there, not in openejb (even if some bridge can let us do it in openejb if
we dont want to wait).
the parallel scanning is dangerous and can lead to a lot of LinkageError in
particular when we'll be ready to run on java 7 (still some work to do).
what could maybe be done is to parallelize the scanning by jar (1
thread/jar max is a good rule i think). If you want to have a try maybe
look the AnnotationFinder class (ours and the xbean one, the difference is
our one is a fail fast one).
- Romain
2012/4/15 Neale Rudd <ne...@metawerx.net>
> Thanks Romain,
>
> I've been doing some simple profiling and investigating the single-thread
> issue further.
>
> The findAnnotations method seems to be the slowest area on the hardware
> we're testing, and with a large app it accounts for over 85% of the startup
> time.
>
> Could that be multithreaded without synchro issues?
>
> I'm doing some work with Yourkit next to dig a bit deeper.
>
> Best Regards,
> Neale
>
>
> ----- Original Message ----- From: "Romain Manni-Bucau" <
> rmannibucau@gmail.com>
> To: <us...@openejb.apache.org>
> Sent: Monday, April 16, 2012 1:51 AM
> Subject: Re: TomEE startup performance
>
>
>
> Hi Neale,
>>
>> well you find a big part of the overhead: the scanning, you can add all
>> which is not done by tomcat (JPA, EJB init, CDI...). Well maybe tomcat +
>> webapp startup should be compared to a tomee + webapp startup.
>>
>> you spoke about multithreading which seems to be a good idea but it can
>> lead to a lot of issues and maybe too much synchro = slower startup
>>
>> to have a good idea of these use a profiler, you'll find very interesting
>> info.
>>
>> - Romain
>>
>>
>> 2012/4/14 Neale Rudd <ne...@metawerx.net>
>>
>> Hi Guys,
>>>
>>> Could someone explain in some more detail what exactly causes the slower
>>> startup time in TomEE compared to Tomcat?
>>>
>>> I imagine it's parsing classes, annotations etc.. but haven't looked at
>>> that area of the code too much yet.
>>>
>>> One thing I've noticed in our testing, is that it seems to be mostly
>>> single-threaded, sitting at 100% on one core for most of the startup,
>>> which
>>> of course is painful on multi-core low-Ghz CPUs. Perhaps there could be
>>> a
>>> -D flag to specify the number of threads to use for doing whatever it's
>>> doing, like Java with it's ParallelGC threads.
>>>
>>> The startup time should be reduced at the cost of higher initial CPU
>>> load.
>>> Ideas?
>>>
>>> Best Regards,
>>> Neale Rudd
>>>
>>>
>>
>
Re: TomEE startup performance
Posted by Neale Rudd <ne...@metawerx.net>.
Thanks Romain,
I've been doing some simple profiling and investigating the single-thread
issue further.
The findAnnotations method seems to be the slowest area on the hardware
we're testing, and with a large app it accounts for over 85% of the startup
time.
Could that be multithreaded without synchro issues?
I'm doing some work with Yourkit next to dig a bit deeper.
Best Regards,
Neale
----- Original Message -----
From: "Romain Manni-Bucau" <rm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Monday, April 16, 2012 1:51 AM
Subject: Re: TomEE startup performance
> Hi Neale,
>
> well you find a big part of the overhead: the scanning, you can add all
> which is not done by tomcat (JPA, EJB init, CDI...). Well maybe tomcat +
> webapp startup should be compared to a tomee + webapp startup.
>
> you spoke about multithreading which seems to be a good idea but it can
> lead to a lot of issues and maybe too much synchro = slower startup
>
> to have a good idea of these use a profiler, you'll find very interesting
> info.
>
> - Romain
>
>
> 2012/4/14 Neale Rudd <ne...@metawerx.net>
>
>> Hi Guys,
>>
>> Could someone explain in some more detail what exactly causes the slower
>> startup time in TomEE compared to Tomcat?
>>
>> I imagine it's parsing classes, annotations etc.. but haven't looked at
>> that area of the code too much yet.
>>
>> One thing I've noticed in our testing, is that it seems to be mostly
>> single-threaded, sitting at 100% on one core for most of the startup,
>> which
>> of course is painful on multi-core low-Ghz CPUs. Perhaps there could be
>> a
>> -D flag to specify the number of threads to use for doing whatever it's
>> doing, like Java with it's ParallelGC threads.
>>
>> The startup time should be reduced at the cost of higher initial CPU
>> load.
>> Ideas?
>>
>> Best Regards,
>> Neale Rudd
>>
>
Re: TomEE startup performance
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Neale,
well you find a big part of the overhead: the scanning, you can add all
which is not done by tomcat (JPA, EJB init, CDI...). Well maybe tomcat +
webapp startup should be compared to a tomee + webapp startup.
you spoke about multithreading which seems to be a good idea but it can
lead to a lot of issues and maybe too much synchro = slower startup
to have a good idea of these use a profiler, you'll find very interesting
info.
- Romain
2012/4/14 Neale Rudd <ne...@metawerx.net>
> Hi Guys,
>
> Could someone explain in some more detail what exactly causes the slower
> startup time in TomEE compared to Tomcat?
>
> I imagine it's parsing classes, annotations etc.. but haven't looked at
> that area of the code too much yet.
>
> One thing I've noticed in our testing, is that it seems to be mostly
> single-threaded, sitting at 100% on one core for most of the startup, which
> of course is painful on multi-core low-Ghz CPUs. Perhaps there could be a
> -D flag to specify the number of threads to use for doing whatever it's
> doing, like Java with it's ParallelGC threads.
>
> The startup time should be reduced at the cost of higher initial CPU load.
> Ideas?
>
> Best Regards,
> Neale Rudd
>