users@glassfish.java.net

Re: glassfish startup performance problems

From: <glassfish_at_javadesktop.org>
Date: Mon, 10 May 2010 12:12:47 PDT

30s is a long time for an empty server.

What kind of hardware etc are you running on? Do you have enough memory to support a 512M instance?

Mine (GF v2.2) starts in 20s, and it has 10 minor WARs, and probably 2 dozen connection pools, among other detritus of a development app server. But I have a decent machine with ample memory.

Basically, at start up, Glassfish (2.x) doesn't really DO anything. Obviously, it's doing "something", but just not a whole lot. Specifically, it's not going out and opening up all of the connection pools, for example. Much of what GF does is "lazy'. It's not done until it needs to be done. Instead, it goes around and loads as little as possible.

Even when you application loads, it doesn't need to "do anything". For example, the JPA only loads and works its magic on the Entity classes when the EntityManager is actually accessed. Now, many large applications have startup logic (notably Servlets that are configured to load on startup, and then have their init() method called.)

But if you app is passive, it will just sit there until its first request.

Web Services are notoriously slow to start up if you have a lot of those.

GF also must start up its JMS server and embedded Derby DB, and fire up the JEE timer services.

But, really, beyond taking a generic "look around" and registering "stuff that could happen", GF opens up a couple of sockets and then sits and waits.

30s for an empty GF is a long time, IMHO. You're params indicate that you want the all of the 512MB heap, right away (and that's good, that can actually speed up startup if you load a lot of things initially), but I would make sure that you have the free resources on your machine to take that heap hit. Make sure you're not swapping, etc. That 512M of heap is going to need a lot more than 512M of real system memory and resources.

oh, I just noticed the "implemented on an embed device". It could well be that your hardware is simply "slow". Most of our perceptions are based on what we have in hand, and I don't deploy a lot to "underpowered" hardware. But, considering what kind of hardware folks are "embedding" today, it's hard to know what that really means :).
[Message sent by forum member 'whartung']

http://forums.java.net/jive/thread.jspa?messageID=469266