Hi all,
I am testing Hibernate against direct jdbc calls and based on the results we are to decide what to use (wether hibernate and direct jdbc calls are far away ; performance wise)
the problem that is that with direct calls on the tomcat side I get good TPS and response time but it hogs up the CPU like 10% idle or so, while with Hibernate I am getting bad TPS and response time and the cpu is mosly more that 50 % idle. both the test scenarios are exactly same (tomcat config and all).

how ever if I decrease the number of threads I get equivalent performance from both with comparable CPU usage.

any help would be highly appreciated
regards,
Vivek Agrawal

There is really not enough information in your post to really help you. There are several things that we would need in order to help you:

1.) how are you generating the load?
2.) is your application mostly read only, mostly edit, etc.?
3.) you indicate that there is similar behavior if you reduce the number of threads. What threads are you reducing?
4.) If your application is showing little CPU use, your are either
a.) IO bound, so the SQL from hibernate is not working well with your database. Are there SQL hints in the JDBC version?
b.) lock bound. Perhaps you have an unnecessary lock around your SessionFactory or you are re-creating session factories when you don't need to.
c.) GC bound (although this shows up are CPU bound on many machines) if your memory allocation is causing OS swaping of memory you might see this during GC scans (which might point back to 1 or 2).

Give us more, otherwise we are guessing.

That being said, in general, in real application I've seen Hibernate work better than straight JDBC unless you are doing batch updates.

i can save you some time and say that plain jdbc will always be faster .

it will always take less time to buy groceries than to buy groceries and cook dinner.

hungry ;) ?

okay here is the complete scenario
I have 2 servlet (served by tomcat 5.x) which talks to each other and to the client as well the servlets needs to handle 2 kinds of requests
1. read request:- servlet 2 makes a persistent object (using hibernate) the query is (as sent using HQL) "select table2.column2 from table2 where table2.column3=?" , servlet 2 takes an object as an argument wihich is created by servlet 1 (which is called by the client and the object returned is passed to servlet 2) which does a select query and if the result of select is negative (no such row exists) it does an insert .
2.write request:- servlet 2 does an update and if the result of update is negative (no such row) it does an insert and for this the servlet 2 gets an object from the servlet 1 which creates that object by a select query if the result of select is -ve then an insert is done.

now your questions:-
1. load is generated by creating say 1000 threads from client side which might send any of the above 2 requests to the servlet randomly
2. threads are the one that are there on client side here 1000.
3. the sql query I see in the hibernate log are almost same as I am using with JDBC.
4.I am not creating a session factory I am using spring IOC framework to get a hibernate template and do hibernate stuff from within the template. and spring docs says that I dont need to take care about session factory or transactions as springhibernatetemplate does that already.
5.Max memory for tomcat (I am using this servlet engine) is 1.5 gigs and I dont think that its touching swap. as the box that I am using has more than enough memory.

to elaborte more on the loadtest procedure:-
I have a tomcat AS instance running on machine01 from machine02 I am running a load tester which creates 1000 threads and sends any of the above 2 requests randomly each thread sleeps for 10 milisecs before doing so again for 20000 iterations. and there is a third machine with Mysql-4.x on it, which is contacted by tomcat servlets with tomcat I am using connection pooling (to the DB server that is) and on the client side I am using a HTTP connection pool to connect to tomcat.

and on a last note even if to buy groceries I require less time than to buy groceries and cook dinner if the cooking time is absurdly too much, I'd prefere fruits for dinner :)

bye
vivek

If you are trying to compare JDBC vs Hibernate, you must of course eliminate all extraneous third party products and ensure that tx management , connection pooling, prepared statement caching, etc, are being done in EXACTLY the same way on both sides.

The ONLY kinds of overhead that Hibernate can cause are CPU and memory overhead. (CPU overhead is usually low, memory varies.) If you are seeing lower CPU utilization in the Hibernate solution, then your problem in NOT Hibernate, but rather some other difference in the system.

It looks like there is a "large" synchronized block or method in hibernate test version. Try to find it.

So there are a few things that pop out at me from your more detailed description:

1.) Perhaps there is a configuration issue with your use of Spring. If you were creating a SessionFactory for each request, I would expect to see performance issues. While it's not a good long term solution, for performance benchmarks I would manually track the creatation of SessionFactories, Session and Transaction objects.

2.) I'm confused about the attempt to update and if it fails then insert way of doing things. Are you doing an saveOrUpdate() call for that? If not, you really are not using hibernate as intended.

3.) Finally, it sounds like every request does an insert or an update for every request. You are not going to see the performance improvements that hibernate can give you because all of the dirty checking etc. work that hibernate does to make your code easy is simply overhead for your benchmark.

I agree with the other people that you have some other overhead that is not expected. I would expect, based on your description, that hibernate is going to perform at some small constant performance hit. You really won't see better performance if your application ALWAYS loads a single object and updates or inserts that object EVERY time.