HI Hugo,
In this respect i think the work is mostly likely spread out over the
initialization of Jersey (specifically in the WebApplicationImpl class).
2 seconds does seem rather a lot, are they running on a Motorola 68000?
Do you have any profile information you can share? perhaps it is the
loading/parsing of all the META-INF/services files that takes the most
time rather than the processing of the classes from those? or perhaps
utilizing Java reflection APIs with GAE is very slow?
Paul.
On Sep 25, 2010, at 9:41 AM, Hugo Visser wrote:
> Just a follow up: I've tried several things but none of it reduce the
> startup time in a significant way. It appears that the registration of
> the message body readers and writers in is the biggest bottleneck,
> that can take up to 2 secs in total, but it's hard to pinpoint the
> exact problem.
>
> On Thu, Sep 23, 2010 at 9:31 AM, Hugo Visser <hugo_at_botteaap.net>
> wrote:
>> Hi Paul,
>>
>> I already disabled WADL that saves a bunch of time at start up. It's
>> true that start up of app engine is a bit slower in general, if I
>> compare it to my local dev server. It's at least ~2 secs for the vm
>> to
>> spin up anyway, but in my case I'm seeing delays up to 15-20 secs
>> before the request gets served by Jersey at all. Not all of that
>> delay
>> is caused by Jersey though :)
>>
>> I also had jersey-json in my path while I don't require it so that
>> saves some little bit more time, but it would be nice if Jersey would
>> lazyload those to support the usecase of services that support
>> multiple representations for example. The first request would only
>> init what is needed for that request and if later a json request
>> comes
>> along it could "update" the already warm instance by then and init
>> the
>> json stuff. I guess this is pretty specific for appengine though (and
>> the appengine startup isn't a big deal if the app has enough load).
>>
>> I tried to monkey patch the ServiceFinder already and it seems that
>> it's not the classpath scanning perse that causes the slower init,
>> but
>> the amount of classes that are registered. It's hard to determine
>> from
>> the logs. I didn't notice the api you mention, I'll look in that one
>> and report back. I'd suspect that hardcoding helps somewhat.
>>
>> Thanks for the swift reply (despite JavaOne :))
>>
>> Hugo
>>
>> On Wed, Sep 22, 2010 at 11:51 PM, Paul Sandoz
>> <Paul.Sandoz_at_oracle.com> wrote:
>>> Hi Hugo,
>>>
>>> On Sep 21, 2010, at 9:04 AM, Hugo Visser wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm using Jersey (+Guice) in a few webapps on app engine and I
>>>> love it.
>>>> The only downside is the initialization time that Jersey needs,
>>>> around 2
>>>> seconds on my apps.
>>>
>>> Apart from jersey-core, jersey-server and jersey-guice are you
>>> using any
>>> other Jersey jars?
>>>
>>> I have heard of similar issues, with other non-Jersey app,s on
>>> initialization slowness when using GAE.
>>>
>>> One thing that might speed things up is disabling WADL generation:
>>>
>>> https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/core/ResourceConfig.html
>>> #FEATURE_DISABLE_WADL
>>>
>>> Otherwise it is currently not very easy to isolate or pick and
>>> choose the
>>> "system" components defined by Jersey. This is something i want to
>>> tackle in
>>> the next major release of Jersey.
>>>
>>> It is possible to register your own implementation of a service
>>> iterator
>>> provider:
>>>
>>> https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/service/ServiceFinder.html
>>> #setIteratorProvider
>>> %28com.sun.jersey.spi.service.ServiceFinder.ServiceIteratorProvider
>>> %29
>>>
>>> where you limit the set by hardcoding the set of provider classes
>>> (registered in META-INF/service) files.
>>>
>>> Paul.
>>>
>>>> Unlike a normal container app engine instances are spun down once
>>>> in a
>>>> while so start up time matters a lot.
>>>>
>>>> I noticed that Jersey is doing a lot of discovering and
>>>> registering of
>>>> providers, some of which I most likely never use. Is there any
>>>> way to hook
>>>> in to this mechanism to reduce the number of components that get
>>>> registered?
>>>>
>>>> What would be the best approach for doing lazy initialization of
>>>> resources
>>>> and providers and is this is feasible?
>>>>
>>>> Thanks,
>>>>
>>>> Hugo
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>