Spring/Hibernate Integration , slow response
[145 byte] By [ManyaCanceriana] at [2007-11-26 15:56:43] 
I m using HibernateDAOSupport provided in spring framework to access database.The response is very slow.Can anyone help me in this regard?
# 1
probably due to the way you're doing hibernate. network traffic, lack of database indexes, and chatty access are my guesses. but since you've provided almost no information, that's impossible to tell.
how much do you know about sql, hibernate, and spring? if you're new to them, i think the source of the slow performance is most likely to be you and your code.
%
duffymoa at 2007-7-8 22:17:31 >
# 2
> I m using HibernateDAOSupport provided in spring
> framework to access database.The response is very
> slow.Can anyone help me in this regard?
Any project of any size will experience the same issues. Remove Spring and Hibernate from your project and it will run at light speed. What you're seeing is normal to a degree. That said, yes, you might not have hibernate configured/tuned well.
CarrieHunta at 2007-7-8 22:17:31 >
# 3
> Any project of any size will experience the same
> issues. Remove Spring and Hibernate from your project
> and it will run at light speed.
Let's give you the benefit of the doubt and assume you're joking.
> What you're seeing is normal to a degree.
I disagree. Normal? No. Although it is possible to write bad code in any language, with any framework.
> That said, yes, you might not
> have hibernate configured/tuned well.
This is much more likely.
%
duffymoa at 2007-7-8 22:17:31 >
# 4
> Any project of any size will experience the same
> issues. Remove Spring and Hibernate from your project
> and it will run at light speed.
Pretty surprising comments, from someone who pretended to have 10+ years of experience in Java in some past thread...
Not so surprising, considering that that same "experienced" person (you) asserted that newbie SCJP-certified developers were better programmers than experienced ones in all cases, and started insulting people (me and others) when we objected.
That thread has had its abuse & useless portion (i.e. your "contribution") deleted since, but the memory of it still remains...
karma-9a at 2007-7-8 22:17:31 >
# 5
I think its fair to say JDBC SQL is faster than Hibernate. Significantly. Im sure you can tune that down.Anyway, hibernate takes a while to startup. So you have to pay attention to what you are doing with it. Don't keep starting and stopping it._dnoyeBa at 2007-7-8 22:17:31 >
# 6
> I think its fair to say JDBC SQL is faster than
> Hibernate.
I think it's highly misleading to say that. To the point of being untrue really - certainly not "fair".
Hibernate can be slow to start up. There are ways to ameliorate this if it's really an issue, but it's not that slow.
When running Hibernate is rarely detectably slower than reasonably comparable JDBC logic, and thanks to lazy loading and cacheing it's often a great deal faster.
As always, it depends what you're doing, but if your app is "really slow" with Hibernate, then it's almost certainly because you're doing something wrong, not because Hibernate is innately slow.
dcmintera at 2007-7-8 22:17:31 >
# 7
http://www.devx.com/Java/Article/33768/1954?pf=truemchan0a at 2007-7-8 22:17:31 >
# 8
All benchmarks are bogus. Regardless of what they show.
1. It doesn't provide the code used. Quite possibly any and all of the frameworks (including JDBC) are being used incorrectly.
2. This is for a "simple object". Most of the frameworks (including Hibernate) come into their own in terms of performance once you start to have large numbers of objects with associations.
Skimming that particular article, I don't find much in-depth discussion of their methodology, so I have to wonder if they took into account performance issues associated with database-side cacheing, network resource allocation, disk resource allocation, and so on and so forth.
All benchmarks are bogus.
dcmintera at 2007-7-8 22:17:31 >
# 9
Actually code etc. is in the article. I'll read it more carefully. But I stand by the "benchmarks are bogus" assertion.(edit) Having looked through the code, I'm unimpressed with the examples given for both JDBC and Hibernate.dcmintera at 2007-7-8 22:17:32 >
# 10
> I think its fair to say JDBC SQL is faster than
> Hibernate. Significantly.
I'd say it still depends on your application. Your statement would be always true if Hibernate was just a layer on top of JDBC that only added more convenience for coders. However it is more than that, since the framework provides a certain number of optimizations on straight JDBC, like caching, lazy loading, and updating only what has actually changed.
The article included in this thread exposes a benchmark of limited value (as all benchmarks). Still, you can see that Hibernate performs significantly better than straight JDBC when cascading SQL operations are involved.
The only benchmark that counts is the one of your own application. If you happen to have had to develop or maintain a fair number of applications (each in its own environment), you'd see that there are no hard conclusions you can come up with. Again, it all depends.
karma-9a at 2007-7-8 22:17:32 >
# 11
I find that there are many factors involved with web app performance: network traffic, database indexes, etc. Blanket statements don't apply, because expertise levels vary.
I've always figured that JDBC's performance would be the "speed of light" for Hibernate, since it ran on top. There are a lot of features built into Hibernate that can help make it perform even better than JDBC under certain circumstances (e.g., caching, lazy loading, etc.).
The idea is that Hibernate is a thin enough layer on top of JDBC that performance issues won't be a factor in choosing whether or not to use it. It's the development advantages and good plumbing code that will seal the deal. I think the ease with which you can do 1:m and m:n relationships properly in Hibernate is a big plus. I've seen JDBC code that naively did the JOIN on the server side, resulting in very chatty communication.
HIbernate generates SQL for you. If you find that the generated stuff isn't performant, and you have a SQL expert on hand to tune it for you, you're always free to switch to something like iBatis. But I do like Hibernate. The improved development productivity and good layering and abstraction make it worth the small performance penalty I might be paying. I don't find that it's a measurable bottleneck in my apps.
%
duffymoa at 2007-7-8 22:17:32 >
# 12
Hibernate startup time is significantly slower than just opening a JDBC connection. Its probably also tied to the number of persistent classes you are using. You can open and close JDBC connections must faster than you can create and destroy hibernate SessionFactorys.
I have an app that works with straight JDBC and one that works with hibernate. JDBC is always faster. I'm talking about tossing around data here. I am not talking about overall application performance. SQL does not relate to caching or lazy loading so the comparison does not make sense. Only thing SQL does is get/set data. So that is the only comparison you can make. And of course, hibernate's SQL is tuneable in many ways, so you can get it tuned so that its almost exactly as fast as straight JDBC.
But thats not the purpose of using hibernate anyway. It hibernate makes you faster. Have to use other tricks on the code.
_dnoyeBa at 2007-7-8 22:17:32 >
# 13
> Hibernate startup time is significantly slower than
> just opening a JDBC connection. Its probably also
> tied to the number of persistent classes you are
> using. You can open and close JDBC connections must
> faster than you can create and destroy hibernate
> SessionFactorys.
You're not comparing like with like - you're supposed to create one SessionFactory per application. Sessions and Connections are analagous, SessionFactories and Connections are not.
If you are worried by application start up time, then you can serialize the Configuration object, but I've never found it to be worth it on a server side app (and I don't do client side stuff much).
> I have an app that works with straight JDBC and one
> that works with hibernate. JDBC is always faster.
So what? Maybe the hibernate app is badly written. Maybe they do dramatically different things. Maybe one's talking to a very slow database. Maybe not, but there are enough variables in this kind of loose comparison to make it worthless.
And if you're creating SessionFactories on an ad hoc basis I'd be astonished if the rest of the hibernate code is any good. Trust me, I can show you JDBC applications that are abominations in the sight of God too, but it doesn't prove anything about JDBC performance.
> I'm talking about tossing around data here. I am
> not talking about overall application performance.
> SQL does not relate to caching or lazy loading so
> the comparison does not make sense.
That's nonsense. Hibernate DOES relate to caching and lazy loading. If you turn them on you get a performance advantage that's not available with JDBC. You're saying "JDBC is faster compared to Hibernate if you don't count Hibernate's performance advantages". Well yes. Hibernate runs on top of JDBC - nobody's claiming it uses clairvoyance to achieve this stuff. But caches and lazy loading are a significant advantage that you can't just dismiss out of hand.
> Only thing SQL
> does is get/set data. So that is the only
> comparison you can make. And of course, hibernate's
> SQL is tuneable in many ways, so you can get it
> tuned so that its almost exactly as fast as straight
> JDBC.
If you rig the requirements of your test, JDBC will always be faster. If you don't like Hibernate you don't have to use it. However in real world applications one of Hibernate's advantages over JDBC is that it's faster.
You can do things to improve the performance of JDBC (adding cacheing for example), but then you're comparing JDBC + Cacheing to Hibernate (which already includes cacheing) which is a different issue.
> But thats not the purpose of using hibernate anyway.
> It hibernate makes you faster. Have to use other
> tricks on the code.
I don't know what you're trying to say in this last para. Doesn't make sense to me. Still, I would add that performance is only one of several reasons to use Hibernate. And there are reasons why you might not want to.
But nonetheless if Hibernate is performing noticeably less well than JDBC it's almost certainly because you're making a mistake in how you're using it, not because of a performance problem with Hibernate.
dcmintera at 2007-7-8 22:17:32 >
# 14
> I have an app that works with straight JDBC and one
> that works with hibernate. JDBC is always faster.
As I was trying to point out, your conclusion is of limited value. I have three apps where the use of Hibernate yielded significant performance gains over straight JDBC, because of some of the features already (and repeatedly) mentioned in this thread. Again, you can't make generalizations here, because every app is different and there are many variables involved.
> I'm talking about tossing around data here. I am
> not talking about overall application performance.
> SQL does not relate to caching or lazy loading so
> the comparison does not make sense. Only thing SQL
> does is get/set data. So that is the only
> comparison you can make.
? Sorry, you lost me. Why doesn't the comparison make sense again?
karma-9a at 2007-7-8 22:17:32 >
# 15
> > Hibernate startup time is significantly slower
> than
> > just opening a JDBC connection. Its probably also
> > tied to the number of persistent classes you are
> > using. You can open and close JDBC connections
> must
> > faster than you can create and destroy hibernate
> > SessionFactorys.
>
> You're not comparing like with like - you're supposed
> to create one SessionFactory per application.
> Sessions and Connections are analagous,
> SessionFactories and Connections are not.
I know that. Thats why I said it. The OP says he was seeing significantly slower performance. That is a sure fire way to get significantly slower performance.
>
> If you are worried by application start up time, then
> you can serialize the Configuration object, but I've
> never found it to be worth it on a server side app
> (and I don't do client side stuff much).
No, Im not worried.
>
> > I have an app that works with straight JDBC and
> one
> > that works with hibernate. JDBC is always faster.
>
> So what? Maybe the hibernate app is badly written.
> Maybe they do dramatically different things. Maybe
> one's talking to a very slow database. Maybe not, but
> there are enough variables in this kind of loose
> comparison to make it worthless.
>
They are the same program and talk to the same database. One adds hibernate on, one uses straight jdbc so all other things are equal. No I don't write bad code. There are no variables and the statement was hardly loose.
Does it matter? No, I never suggested it mattered. Just a point that its not unusual. 'Out of the box' hibernate will need lots of tuning to get it optimized.
> > I'm talking about tossing around data here. I am
> > not talking about overall application performance.
> > SQL does not relate to caching or lazy loading so
> > the comparison does not make sense.
>
> That's nonsense. Hibernate DOES relate to caching and
> lazy loading. If you turn them on you get a
> performance advantage that's not available with JDBC.
> You're saying "JDBC is faster compared to Hibernate
> if you don't count Hibernate's performance
> advantages". Well yes. Hibernate runs on top of JDBC
> - nobody's claiming it uses clairvoyance to achieve
> this stuff. But caches and lazy loading are a
> significant advantage that you can't just
> dismiss out of hand.
I am comparing the SQL I wrote in my applicatin to the SQL hibernate generates without much tuning. I am not comparing hibernates caching and I still don't use any of it.
> > Only thing SQL
> > does is get/set data. So that is the only
> > comparison you can make. And of course,
> hibernate's
> > SQL is tuneable in many ways, so you can get it
> > tuned so that its almost exactly as fast as
> straight
> > JDBC.
>
> If you rig the requirements of your test, JDBC will
> always be faster. If you don't like Hibernate you
> don't have to use it. However in real world
> applications one of Hibernate's advantages
> over JDBC is that it's faster.
You are really over the top. Rig my test? I did not even write a test. Its my application. I am certainly not going to 'rig' my application to perform poorly!? Why would I have an application written in hibernate if I did not like hibernate? But its nice to know I have your permission not to use it...
In my real world, Hibernates caching and lazy loading adds nothing to the performance of my application. It only adds to the ease of which I can write my code. Yet you need to be careful because that lazy loading can easily load a whole set of object one SQL call at a time, as opposed to with a single SQL call. You need to optimize it.
_dnoyeBa at 2007-7-21 16:37:02 >
# 16
> > Sessions and Connections are analagous,
> > SessionFactories and Connections are not.
>
> I know that. Thats why I said it.
No, that's not what you said. You said that Connection creation is faster than SessionFactory creation. This creates the impression that they are analagous.
> (JDBC & Hibernate apps)
>
> They are the same program and talk to the same
> database. One adds hibernate on, one uses straight
> jdbc so all other things are equal. No I don't write
> bad code. There are no variables and the statement
> was hardly loose.
Nobody every thinks they write bad code.
> Does it matter?
You've stated pretty categorically that JDBC is inevitably faster than Hibernate, which is completely untrue in general use. You back this up with unseen code that's supposed to somehow "prove" this point.
To the extent that any of the technical discussions on this forum matter, yes, it matters.
> No, I never suggested it mattered.
> Just a point that its not unusual. 'Out of the box'
> hibernate will need lots of tuning to get it
> optimized.
That's not actually true. Out of the box Hibernate needs virtually no tuning to get it optimized. The exception to this is if you're running Hibernate 2, in which case all bets are off. Are you? It's the only explanation I can think of so far for the disconnect between my position and yours, given that I think you're not stupid (high praise from me, normally I think everyone's stupid).
> I am comparing the SQL I wrote in my applicatin to
> the SQL hibernate generates without much tuning. I
> am not comparing hibernates caching and I still don't
> use any of it.
You have to "tune" hibernate in order not to use cacheing and lazy loading. They're on by default.
> You are really over the top. Rig my test? I did not
> even write a test.
I didn't say you rigged the test, I said you rigged the requirements. And by test I meant the hypothetical one you appeared to be talking about - one in which cacheing and lazy-loading were turned off, because in your opinion they don't count when comparing Hibernate and straight JDBC.
> Its my application. I am
> certainly not going to 'rig' my application to
> perform poorly!?
That's not what I was suggesting (see above).
> In my real world, Hibernates caching and lazy
> loading adds nothing to the performance of my
> application.
Well, in my opinion we're either talking about different versions of Hibernate, in which case you may have a point albeit an out-dated one, or there's something really wrong with the way you're using Hibernate, or you're counting initial startup time against it, which I've acknowledged is an minor but genuine factor.
If it's not one of those then one of us is smoking crack.
dcmintera at 2007-7-21 16:37:02 >
Other Topics New Topic
Other Topics Hot Topic
Other Topics
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding