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
>>
>>
>