tags:

views:

156

answers:

7

I am using Spring with Hibernate to create an Enterprise application.

Now, due to the abstractions given by the framework to the underlying J2EE architecture, there is obviously going to be a runtime performance hit on my app.

What I need to know is a set of factors that I need to consider to make a decision about the minimum specs(Proc speed + RAM etc) that I need for a single host server of the application running RedHat Linux 3+ and devoted to running this application only, that would produce an efficiency score of say 8 out of 10 given a simultaneous-access-userbase increase of 100 per month.

No clustering is to be used.

+1  A: 

I seriously doubt that using Spring will significantly affect your performance.

What particular aspects of Spring are you expecting to cause performance issues?

toolkit
+1  A: 

There are so many variables here that the only answer is to "suck it and see", but, in a scientific manner.

You need to build a server than benchmark this. Start of with some "commodity" setup say 4 core cpu and 2 gig ram, then run a benchmark script to see if it meets your needs. (which most likely it will!).

If it doesnt you should be able to calculate the required server size from the nulbers you get out of the benchmark -- or -- fix the performance problem so it runs on hte hardware youve got.

The important thing is to identiffy what is limmiting your performance. Is you server using all the cores or are your processes stuck on a single core, is your JVM getting enough memory, are you IO bound or database bound.

Once you know the limiting factors its pretty easy to work out the solution -- either improve the efficiency of your programs or buy more of the right hardware.

Two thing to watch out for with J2EE -- most JVMs have default heap sizes from the last decade, make sure your JVM has enough Heap and Stack (at least 1G each!), -- it takes time for all the JIT compiling, object cacheing, module loading etc to settle down -- exercise your system for at least an hour before you start benchmarking.

James Anderson
A: 

As toolkit, I don't see Spring itself affecting the performance after initialization, but I think Hibernate will. How big this effect is, depends on a lot of details like the DB-Schema and how much relational layout differs from the OO layer and of course how DB-access is organized and how often DB-access happens etc. So I doubt, there is a rule of thumb to this. Just try out by developing significant prototypes using alternative applications servers or try a own small no-ORM-use-JDBC-version.

Kai
I imagine that the overhead of Hibernate (I don't know the internals, but there is could be a lot of reflection, string generation and map lookups; alternatively it could incorporate a code generator and compiler) is probably dwarfed on a decent CPU by the database request round trip.
JeeBee
A: 

Which performance setback? In relation to what? Did you measure the performance before using the framework?

If the Spring framework causes inacceptable performance issues the obvious solution is not to use it.

+1  A: 

I've never heard that Spring creates any type of runtime performance hit. Since it uses mainly POJOs I'd be surprised if there was something wrong with it. Other than parsing a lot of XML on startup maybe, but that's solved by using annotations.

Just write your app first and then tune accordingly.

bpapa
+6  A: 

No offense, but I'd bet that performance issues are more likely to be due to your application code than Spring.

If you look at the way they've written their source code, you'll see that they pay a great deal of attention to quality.

The only way to know is to profile your app, see where the time is being spent, analyze to determine root cause, correct it, rinse, repeat. That's science. Anything else is guessing.

I've used Spring in a production app that's run without a hitch for three years and counting. No memory leaks, no lost connections, no server bounces, no performance issues. It just runs like butter.

duffymo
+1  A: 

Spring is typically used to create long-lived objects shortly after the application starts. There is virtually no performance cost over the life of the process.

landon9720