Using Ebean.io slow startup time (using on AWS Lambda)

[mei...@cloudone.mobi]

Hi 

I'm porting a project from Play framework for execution on AWS Lambda, and I've noticed that creating an Ebean server & connection pool takes about ~14s.  

Is it normal for Ebean to take this long to start up & establish connections?   I cannot find anything in the documentation about startup options that can be tweaked.

I'm using Ebean (11.10.5) on Java8 

This is the connection code:

DriverManager.registerDriver(new com.mysql.jdbc.Driver());

ServerConfig defaultConfig = new ServerConfig();

defaultConfig.setDefaultServer(true);

defaultConfig.loadFromProperties(PropertyMap.defaultProperties());

DBConfig config = getDbConfig("CONFIG");

defaultConfig.setName("default");

defaultConfig.getDataSourceConfig().setDriver(config.driver);                                      // com.mysql.jdbc.Driver

defaultConfig.getDataSourceConfig().setUsername(config.username);

defaultConfig.getDataSourceConfig().setPassword(config.password);

defaultConfig.getDataSourceConfig().setUrl(config.url);                                            // jdbc:mysql://<host>:3306/<database>?zeroDateTimeBehavior=convertToNull

defaultConfig.getDataSourceConfig().setMaxConnections(Integer.parseInt(config.maxConnections));    // 2

Ebean.register(EbeanServerFactory.create(defaultConfig), true);

Regards,

[Roland Praml]

Ebean scans the classpath for interesting classes like entities. You may specify the packages in serverconfig where to search.

[Rob Bygrave]

Firstly, startup time is important to me but I haven't yet had the opportunity to profile Ebean specific startup time yet (but I have measured entire service startup times instead using docker with cpu limiting).

For me, I look to avoid scanning altogether and explicitly register the entity bean types via serverConfig.addClass(beanType); ...  that is what I would recommend (I would not specify packages to scan). 

----------------

I have been working on projects with docker/kubernetes deployments and for me in the future I believe we (JVM devs) will avoid all classpath scanning.  We will increasingly desire good startup times and lower resource consumption and work towards approaches that are more compatible with Java 9+ Modules. This has implications for ALL JVM frameworks/libraries that use classpath scanning techniques or other "automatic configuration features" that impact startup time.

I believe it is too early to tell how GraalVM will impact Ebean but it could have a significant impact.

Cheers, Rob.   

On Tue, 5 Jun 2018 at 07:04, Roland Praml <rpra...@gmail.com> wrote:

Ebean scans the classpath for interesting classes like entities. You may specify the packages in serverconfig where to search.

--

---
You received this message because you are subscribed to the Google Groups "Ebean ORM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ebean+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tobias Olsson]

Hi Rob,

have you considered doing something like auto-generating a properties file in the enhancer step and use that instead of scanning? Since all classes have to be enhanced to work at all,

they have to be processed by something that can generate said properties file.

There's a "framework" for discovery in the JVM with META-INF/services and java.util.ServiceLoader. I say "framework", because it's

very rudimentary, but functional. Both HK2 and WebApplications use it, but neither have the option to generate them compile time afaik.


Best Regards

/Tobias

[Rob Bygrave]

> There's a "framework" for discovery in the JVM with META-INF/services and java.util.ServiceLoader.

We use it a lot in Ebean for internal plugins and ... we just added in 11.17.4 the feature below:

Refer to https://github.com/ebean-orm/ebean/issues/1420
ENH: Add a ServiceLoader mechanism to configure ServerConfig - io.ebean.config.ServerConfigProvider

I "sort of" profiled this on CPU=0.5 ... and yes this ServiceLoader mechanism provides a nice fast and explicit way to do this.  So this is released in 11.17.4 and you can try it out.

> have you considered doing something like auto-generating a properties file in the enhancer step ...

Yes I have, it is still under consideration and maybe worth doing.  At this stage I'll be using ServerConfigProvider first though and looking for feedback on using it because it is simple and fast and provides for the opportunity to adjust other ServerConfig things other than just addClass().

Cheers, Rob.

[Rob Bygrave]

Oh, and ServiceLoader will work nicely in Java 10 modules (and as far as I know classpath scanning will not).

So this mechanism we added with #1420 should be good for use with Java 10 modules.

Cheers, Rob.

[Rob Bygrave]

> AWS Lambda, and I've noticed that creating an Ebean server & connection pool takes about ~14s. 

To me that looks like classpath scanning so I think you would see improvement with using serverConfig.addClass(). It would also be good to check/confirm you have a ebean.mf manifest file which controls enhancement but it also read and checked in classpath scanning for entities (but serverConfig.addClass() would be better) ... and confirm you are using build time enhancement and not agent/runtime enhancement.

Are you still seeing ~14s?

Running Jetty + Jersey + Jackson at 0.5 CPU is showing me that Ebean startup is good and that using io.ebean.config.ServerConfigProvider helps.  If anyone is seeing slow startup times they should ask about it.

Also note that I have observed that Java 10 does make some pretty impressive improvements in the Docker/CGroup low resource area (0.5 CPU 100m total memory) in terms of startup times.  For example, for my small but not tiny test application (Jetty/Jersey/Jackson/Ebean) I see 12secs total startup time for Java8 with the CGroup awareness JVM options ... and this goes to 6secs for Java 10 (so a surprisingly significant improvement there running the exact same app on Java 10 at these low resource levels).  Ultimately I want to compare this to spring boot at these low resource levels (cost the extra scanning and automatic configuration that is done with Spring boot).

Another thought for the future:

Should / could we remove our dependency on xml / jaxb for migrations and extra-dll.xml and instead add the ability to use Jackson for those instead?  The thought here is that in with using JLink with a cut down JVM ... we could turn this on such that we use Jackson/JSON for those, remove the dependency on jaxb, use a smaller JVM with no jaxb via JLink, improve our ability to go smaller/faster.

I haven't had time to try that out yet to see if it is worth it.