I have a question about JPA/Hibernate performance.
We are building web application, one of the goals is to store questions and their answers. For both of these things we have class hierarchy, and #Inheritance(strategy = InheritanceType.TABLE_PER_CLASS).
The questions have references to their answers, every question is stored in some list.
I observed using firebug that when I am adding new question to the list and use entityManager.merge I need to wait about one second for response. I think that it is pretty long time to wait for a response for simple add request.
Is it because of the Inheritance strategy, or maybe I shouldn't use entityManager.merge and try to write my own query.
Maybe the performance is low because I am using sql lite database (sql lite is used just for testing, on production postgre will be used)?
Or this kind of performance is pretty standard for ORM solutions.
I use sqlite a lot (sometimes even for production) and the performance is sometimes even better than for traditional client server connections.
Maybe you should debug you application and enable logging of the JPA provider you are using to see if in fact the inheritance model is to blame.
But, if you have done the inheritance correctly then I don't think that would be te issue. It would help if you paste the code for how you declare the classes.
I would also look at a profiler if this persists.
Related
I am trying to use dapper-dot-net to speed up some area of my asp.net mvc application. I am using EF5 Code first also.
Since dapper-dot-net is just some extensions for IDbConnection, can i just use
DbContext.Database.Connection
to use dapper-dot-net? I test it is working. However, i am not sure this is the right way to use it? Especially, when I use that way, will Entity Framework still has some impact that could hurt the performance?
Using Dapper could be a significant performance improvement in certain scenarios.
You can share the EF connection with Dapper. However (although unlikely to be a problem) you should be mindful of concurrency issues (e.g. due to attempts to associate multiple data readers with the same connection).
If you do run into such issues, you have the option of giving a new connection to Dapper using the connection string (DbContext.Database.Connection.ConnectionString), instead of sharing the connection.
Yes, you can use it that way. Since Dapper is just working on extension methods, you can use it for the performance-sensitive areas of your code. And you can continue to use EF for other areas of your code. The queries that you have that are still using EF will not be as fast - but at least the queries using Dapper will be faster.
I think you have to rethink about the question. Increasing performance via changing the ORM is not a good technique. It is correct that dapper is faster and lighter than EF but this does not mean that to increase the speed of your application its better to use the dapper. EF is powerful enough to handle the whole data layer if you suffer from performance you have to introduce new feature like caching or no sql db.
you have to see that changing from EF to dapper how much will save time for you ? and how much speed can caching bring to your application.
and adding dapper has other expenses: how would you manage the transaction while you have to point of save and update how you are going to solve the roll back situation, what about the Unit of Work and Repository pattern.
These are the factor that you have to examine before deciding to go for Dapper.
MVC sets up clear distinction between Model, View and Controller.
For the model, now adays, web frameworks provides ability to map the model directly to database entities (ORM), which, IMHO, end up causing performance issues at runtime due to direct database I/O.
The thing is, if that's really the case, why model ORM is so pupular and every web frameworks want to support it either organically or not.
To a web site has huge amount of traffic, it definitely won't work. But what's the work around? Connect directly to database is definitely not a wise solution here.
What's your question?
Is it a good idea to use direct db access from webpages?
A: No.
Is it a good idea to use ORM's?
A: Debatable : See How can I design a Java web application without an ORM and without embedded SQL
Is it a good idea to use MVC model?
A: Yes - it has nothing to do with "Direct" database access - it's about separating your application logic from your model and your display. (Put simply).
And the rationale for not putting database logic inside webpages has nothing to do with performance - it's about security/maintainability etc etc. Calling a usp from a webpage is likely to be MORE performant than using an ORM, but it's bad because the performance gain is negligible, and the cons are significant.
As to workaround: if you mean how do you hook up a database to a web application...?
The simplest way is to use something like Entity Frameworks or Linq-Sql with your Model - there are plenty of examples of this in tutorials on the web.
A better method IMO, is to have a separate Services layer (which may be WCF based), and have all the database access inside that, with DTO's transferring the data to your Web Application which has it's own ViewModel.
Mvc is not about orm but about separation of display logics and business logics. There is no reason your exposed model needs to be identical to you database model and many reasons to ensure that the exposed model closely matches what is to be displayed.
The other part of the solution to scale well would be to implement caching in the control and be able to distribute load on sevaral instances.
I think #BonyT has given a good answer, (and I've voted for it :) ), I'd just add that:
"web frameworks provide the ability to map the model directly to database entities (ORM), which, IMHO, ends up causing performance issues at runtime due to direct database I/O"
Even if this is true, using an ORM can solve a lot of problems with a model being easy to update and translate back and forth between a database. Solving a performance hit by buying extra web servers or cloud instances is much cheaper than having to buy extra developers or extra hours in development to solve things other people have already written ORMs to do for you.
A question of ColdFusion ORM
We are using ColdFusion 9 for the past 6 months and while we've used some of the new features, ORM is something we've avoided because we usually work on the same very large website. Over the years we've used Apache OBJ but then we moved back to CF and used our own DAO objects generated from tables to handle basic CRUD. These objects are basic and need to be regenerated manually for schema changes and do not model table relationships at all. To supplement these we have a set of gateway classes for multi-table queries. While all this is very bespoke, these DAOs and gateways do, however, give us great control over the SQL we execute, for example using locking hints and optimiser hints. Our site is busy but our database is very efficient.
So much for the history lesson: the point of this is that we have a new site upcoming soon that will be written from scratch to handle financial transactions. We would normally use our aforementioned DAO objects to handle CRUD and then the usual set of gateway objects for multi-table joins but I thought we might investigate using baked-in CF ORM...
So with that in mind, I'd love to hear of the lessons, tips and tricks others might have to share in regard to using ORM on a busy financial site. For example:
What's the best way to flush your SQL ? What tips do you have for transactional ORM? How do you setup development and live sites for ORM? What about HQL? When should we just do the SQL ourselves by hand?!
Thanks in advance!
Short answer, YES! go for ORM!!!
What's the best way to flush your SQL ?
ormflush()
What tips do you have for transactional ORM?
<cftransaction> or transaction {} in CFScript works fine, and even work across DSN's, much improved in 9.0.1! watch http://tv.adobe.com/watch/max-2010-develop/coldfusion-undocumented/
How do you setup development and live sites for ORM?
same as without ORM, but you may look into this.ormSettings.dbCreate if u mean the DB creation part
What about HQL?
What about it? :) Use it when u want an array of objects, but nothing stopping you from using the good old <cfquery>
When should we just do the SQL ourselves by hand?!
When you feel like HQL doesn't do what you want.
Check out: Things to watch out for in ColdFusion 9 with CF-ORM however keep in mind that some points are no longer true for 9.0.1
Currently we have a project to implement an Internet Banking site, and we are evaluating using Nhibernate on it. ¿Is NHibernate suitable for this kind of application, where performance is important and there will be a large quantity of users doing operations simultaneously?
¿Do you know any successfull stories of using NHibernate in this kind of environment?
I think NHibernate is slow only when is used incorrectly, and I think we can use it with a lot of tweaking, best practices and common sense.
UPDATE: We were contacted for the project not too long ago, and we are still collecting requirements to define the specs. The application its for a small to medium bank in our country, so they expect around a 200 - 300 users as a top simultaneously.
Im pretty sure the DB will be in SQL Server 2005, and will be a n-tier application using webservices to access the data layer.
My team has been using NHibernate in a system requiring high throughput for years without a problem. NH is fairly efficient to begin with, and provides fine-grained control over when and how objects are reconstituted.
With that said, we don't know the specifics of your problem, so we can't make certain predictions. Perform scaling tests before you commit yourself.
NHibernate can be suitable if used correctly.
But, don't pin you down on this answer, since we do not know the correct specs.
I'm getting a little tired of all the UI demos of auto completion in ASP.Net. I believe the UI portion of autocompletion has been solved multiple times over again.
My question is how do you best handle the queries hitting your webservices? I'm currently implementing an autocompletion service for a musician database. The database is fairly small with only 20,000 rows, but autocompletion is extremely speed sensitive. It needs to be fairly instant to be of any use.
I'm currently using NHibernate for my DAL, but I'm wondering if this is a place where I may want to bypass NHibernate. Perhaps projections on named queries would be the best strategy? Where do I cache? NHibernate's 2nd level cache? Let the web service cache?
I've already thought of a lot of naive methods to develop this, but I would like to soak in any tips that people already have in the wild. Also, what if you have many different types of entities you want autocompletion on? Do you spread those implementations around in their different repositories or do you design/implement a completely separate autocompletion service?
This depends on how large your sites traffic is. I generally suggest using a product such as MemCached or MemCached Win32 depending on your environment availability (MemCached for cheap linux boxes if you can is best...all that is needed is a ton of memory!). You might also look to something like Velocity (MS's new cache cloud offering). This would then allow you to cache a key (what ever the query is) with the results efficiently! Keep your cache times down based on however frequently you are updating your dataset. If you don't update often then the cache time can be longer. If you find that your cache cloud is growing like crazy you might want to only cache what is most frequently asked for (though your cache implementation should handle this by removing what is not accessed frequently!).