Performance Problem mit Prepared Statement

Status
Nicht offen für weitere Antworten.

DreamArtist

Bekanntes Mitglied
Hallo,

ich habe massive Performance Probleme wenn ich mit Hibernate auf die DB Querys absetze.

Ich verwende Hibernate3
Die Datenbank hat ca. 22 Millionen Datensätze.

Setze ich die Querys als Nativ SQL ab brauchen 100 Abfragen ca.: 5 Sekunden.
Setze ich die selben mit Hql ab, brauchen Sie 155 Sekunden.

Folgendes habe ich konfiguriert:

persistence.xml

Code:
<persistence-unit name="testOnDb2Test" transaction-type="RESOURCE_LOCAL">
		<provider>org.hibernate.ejb.HibernatePersistence</provider>
		<properties>
			<property name="hibernate.dialect" value="org.hibernate.dialect.DB2Dialect" />

			<property name="connection.provider_class" value="org.hibernate.connection.C3P0ConnectionProvider"/>
			<property name="hibernate.connection.url" value="jdbc:db2://localhost:50000/ODB" />
			<property name="hibernate.connection.username" value="xxx" />
			<property name="hibernate.connection.password" value="xxx" />
			<property name="hibernate.default_schema" value="xxx" />
			<property name="hibernate.cache.use_query_cache" value="true" />

			<property name="hibernate.show_sql" value="false" />
			<property name="hibernate.format_sql" value="false" />
            <property name="hibernate.c3p0.min_size" value="5"/>
            <property name="hibernate.c3p0.max_size" value="20"/>
            <property name="hibernate.c3p0.timeout" value="300"/>
            <property name="hibernate.c3p0.max_statements" value="50"/>
            <property name="hibernate.c3p0.maxStatementsPerConnection" value="50"/>
            <property name="hibernate.c3p0.idle_test_period" value="300000"/>
            
             
            <!-- 
       		-->
		      <property name="hibernate.cache.use_second_level_cache" value="true"/> 
		      <property name="hibernate.cache.provider_class" value="org.hibernate.cache.EhCacheProvider"/> 
      
			<property name="hibernate.generate_statistics" value="false" />


		</properties>
	</persistence-unit>

Der Code:


Code:
StringBuffer queryString2 = new StringBuffer();
		queryString2
		.append("select model.id.mid from Table model where model.id.id = ?");
		queryString2.append(" and model.creatstamp < ? ");
		queryString2
		.append(" and  (model.businesstype=? or model.businesstype=? or model.businesstype=? or model.businesstype=?) ");
		queryString2.append(" and (model.state = ? or model.state = ?) ");
		
		for(int c = 0; c < 100; c++){
			
			Query query = this.entityManager.createQuery(queryString2.toString());		
			org.hibernate.ejb.QueryImpl q = (org.hibernate.ejb.QueryImpl)query;
			q.getHibernateQuery().setCacheable(true);
		    query.setParameter(1, new Long(116));
			query.setParameter(2, new Timestamp(new Date().getTime()));
			query.setParameter(3, "O");
			query.setParameter(4, "T");
			query.setParameter(5, "I");
			query.setParameter(6, "C");
			query.setParameter(7, "S");
			query.setParameter(8, "E");
			System.out.println("Before Execute the Query");
			List<Disposition> dispositionList =  query.getResultList();
			System.out.println("After Execute");
			int x = 1;
			for (Disposition disposition : dispositionList) {
				System.out.print("Nr:" + (x++));
				System.out.println(disposition.getId());
			}
		}

Hat wer einen Tipp?

Danke
 
S

SlaterB

Gast
warum erzeugst du auch ständig Query-Objekte?

einmal vor der Schleife und gut, wie ein PreparedStatement
 

DreamArtist

Bekanntes Mitglied
Hallo, danke für die Antwort.

Selbst wenn ich die Query vor der Schleife erzeuge dauert es ewig.

Der Code sieht nun so aus:


Code:
 Query query = this.entityManager.createQuery(queryString2.toString());       
org.hibernate.ejb.QueryImpl q = (org.hibernate.ejb.QueryImpl)query; 
q.getHibernateQuery().setCacheable(true); 
for(int c = 0; c < 100; c++){ 
         query.setParameter(1, new Long(116)); 
         query.setParameter(2, new Timestamp(new Date().getTime())); 
         query.setParameter(3, "O"); 
         query.setParameter(4, "T"); 
         query.setParameter(5, "I"); 
         query.setParameter(6, "C"); 
         query.setParameter(7, "S"); 
         query.setParameter(8, "E"); 
         System.out.println("Before Execute the Query"); 
         List<Disposition> dispositionList =  query.getResultList(); 
         System.out.println("After Execute"); 
         int x = 1; 
         for (Disposition disposition : dispositionList) { 
            System.out.print("Nr:" + (x++)); 
            System.out.println(disposition.getId()); 
         } 
      }

Seltsam ist das immer wieder das Prepared Statement geschlossen wird.
Hier die Ausgabe der Konsole:


Code:
Before Execute the Query
08:00:45,791 DEBUG [GooGooStatementCache] checkinAll(): com.mchange.v2.c3p0.stmt.DoubleMaxStatementCache stats -- total size: 2; checked out: 0; num connections: 2; num keys: 2
08:00:45,791 DEBUG [QueryPlanCache] located HQL query plan in cache (select model.id.merchanttrnsid from Disposition model where model.id.merchantid = ?  and model.creatstamp < ?  and  (model.businesstype=? or model.businesstype=? or model.businesstype=? or model.businesstype=?)  and (model.state = ? or model.state = ?) )
08:00:45,791 DEBUG [HQLQueryPlan] find: select model.id.merchanttrnsid from Disposition model where model.id.merchantid = ?  and model.creatstamp < ?  and  (model.businesstype=? or model.businesstype=? or model.businesstype=? or model.businesstype=?)  and (model.state = ? or model.state = ?) 
08:00:45,791 DEBUG [QueryParameters] parameters: [116, 2009-01-07 08:00:45, O, T, I, C, S, E]
08:00:45,791 DEBUG [QueryParameters] named parameters: {}
08:00:45,791 DEBUG [StandardQueryCache] checking cached query results in region: org.hibernate.cache.StandardQueryCache
08:00:45,791 DEBUG [EhCache] key: sql: select dispositio0_.MERCHANTTRNSID as col_0_0_ from PSCAPPL.DISPOSITION dispositio0_ where dispositio0_.MERCHANTID=? and dispositio0_.CREATSTAMP<? and (dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=?) and (dispositio0_.STATE=? or dispositio0_.STATE=?); parameters: 116, 2009-01-07 08:00:45.791, O, T, I, C, S, E, ; named parameters: {}
08:00:45,791 DEBUG [MemoryStore] org.hibernate.cache.StandardQueryCacheCache: org.hibernate.cache.StandardQueryCacheMemoryStore miss for sql: select dispositio0_.MERCHANTTRNSID as col_0_0_ from PSCAPPL.DISPOSITION dispositio0_ where dispositio0_.MERCHANTID=? and dispositio0_.CREATSTAMP<? and (dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=?) and (dispositio0_.STATE=? or dispositio0_.STATE=?); parameters: 116, 2009-01-07 08:00:45.791, O, T, I, C, S, E, ; named parameters: {}
08:00:45,791 DEBUG [Cache] org.hibernate.cache.StandardQueryCache cache - Miss
08:00:45,791 DEBUG [EhCache] Element for sql: select dispositio0_.MERCHANTTRNSID as col_0_0_ from PSCAPPL.DISPOSITION dispositio0_ where dispositio0_.MERCHANTID=? and dispositio0_.CREATSTAMP<? and (dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=?) and (dispositio0_.STATE=? or dispositio0_.STATE=?); parameters: 116, 2009-01-07 08:00:45.791, O, T, I, C, S, E, ; named parameters: {} is null
08:00:45,791 DEBUG [StandardQueryCache] query results were not found in cache
08:00:45,791 DEBUG [AbstractBatcher] about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
[b]08:00:45,791 DEBUG [ConnectionManager] opening JDBC connection[/b]
08:00:45,791 DEBUG [BasicResourcePool] trace com.mchange.v2.resourcepool.BasicResourcePool@1079ff [managed: 5, unused: 4, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@9f3e95)
08:00:45,791 DEBUG [code=sql] select dispositio0_.MERCHANTTRNSID as col_0_0_ from PSCAPPL.DISPOSITION dispositio0_ where dispositio0_.MERCHANTID=? and dispositio0_.CREATSTAMP<? and (dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=? or dispositio0_.BUSINESSTYPE=?) and (dispositio0_.STATE=? or dispositio0_.STATE=?)


08:00:45,791 DEBUG [AbstractBatcher] preparing statement


08:00:45,791 DEBUG [GooGooStatementCache] com.mchange.v2.c3p0.stmt.DoubleMaxStatementCache ----> CACHE HIT
08:00:45,791 DEBUG [GooGooStatementCache] checkoutStatement: com.mchange.v2.c3p0.stmt.DoubleMaxStatementCache stats -- total size: 2; checked out: 1; num connections: 2; num keys: 2
08:00:45,791 DEBUG [LongType] binding '116' to parameter: 1
08:00:45,791 DEBUG [TimestampType] binding '2009-01-07 08:00:45' to parameter: 2
08:00:45,791 DEBUG [StringType] binding 'O' to parameter: 3
08:00:45,791 DEBUG [StringType] binding 'T' to parameter: 4
08:00:45,791 DEBUG [StringType] binding 'I' to parameter: 5
08:00:45,791 DEBUG [StringType] binding 'C' to parameter: 6
08:00:45,791 DEBUG [StringType] binding 'S' to parameter: 7
08:00:45,791 DEBUG [StringType] binding 'E' to parameter: 8
08:00:47,275 DEBUG [AbstractBatcher] about to open ResultSet (open ResultSets: 0, globally: 0)
08:00:47,275 DEBUG [Loader] processing result set
08:00:47,275 DEBUG [Loader] done processing result set (0 rows)
08:00:47,275 DEBUG [AbstractBatcher] about to close ResultSet (open ResultSets: 1, globally: 1)


08:00:47,275 DEBUG [AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1)


08:00:47,275 DEBUG [AbstractBatcher] closing statement
08:00:47,275 DEBUG [GooGooStatementCache] checkinStatement(): com.mchange.v2.c3p0.stmt.DoubleMaxStatementCache stats -- total size: 2; checked out: 0; num connections: 2; num keys: 2
08:00:47,275 DEBUG [ConnectionManager] aggressively releasing JDBC connection
08:00:47,275 DEBUG [ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
08:00:47,275 DEBUG [GooGooStatementCache] checkinAll(): com.mchange.v2.c3p0.stmt.DoubleMaxStatementCache stats -- total size: 2; checked out: 0; num connections: 2; num keys: 2
08:00:47,275 DEBUG [BasicResourcePool] trace com.mchange.v2.resourcepool.BasicResourcePool@1079ff [managed: 5, unused: 4, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@9f3e95)
08:00:47,275 DEBUG [StatefulPersistenceContext] initializing non-lazy collections
08:00:47,275 DEBUG [StandardQueryCache] caching query results in region: org.hibernate.cache.StandardQueryCache; timestamp=5043451737088000
08:00:47,275 DEBUG [JDBCContext] after autocommit
08:00:47,275 DEBUG [ConnectionManager] aggressively releasing JDBC connection
08:00:47,275 DEBUG [SessionImpl] after transaction completion
After Execute

Keine Ahnung warum Hibernate immer das Statement schließt, andererseits wird das
"normale" Statement ja auch immer geschlossen und ist viel schneller als das Prepared Statement.

Verwendet wird im übrigen eine DB2.
 

DreamArtist

Bekanntes Mitglied
Habe das Problem mittlerweile lösen können.
Die DB2 kann das Prepared Statement nicht wieder verwenden wenn mann es als Parameter übergibt.
Alle Anderen Werte können Dynamisch sein, nur der Timestamp darf es nicht.

Was ich mich noch frage: "Warum schafft die DB2 das nicht?".

Weiß vielleicht jemand warum?
 

GilbertGrape

Bekanntes Mitglied
Es ist vielleicht nicht so sinnvoll, den Thread als erledigt zu markieren, wenn du noch eine Frage hast... (man kanns auch wieder rückgängig machen)

Gruß, GG
 

DreamArtist

Bekanntes Mitglied
Sorry das die Antwort fast 2 Jahre später folgt.

Ich bin das Problem nur umgangen.
Weiß jedoch noch immer nicht warum gerade ein Timestamp das Prepared Statement in die Knie zwingt.
Wäre cool wenn wer eine Antowrt wüsste....
 

madboy

Top Contributor
Ich vermute mal, dass der Timestamp jedes Mal identisch ist wenn du die Query manuell absetzt?
Falls ja, wird vermutlich ein Statement/Resultcache auf der DB zuschlagen und dir die Ergebnisse sehr schnell liefern, ohne wirklich erneut nach Daten zu suchen. Ändert sich der Timestamp nun gelegentlich kann kein Cache greifen, da die Query anders aussieht. Ergebnis: längere Abfragezeit.
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
J Performance JPA Data Tier 14
J Zufallsauswahl aus ResultList bei JPA(Hibernate) / Performance Data Tier 3
F Performance CouchDB (NoSQL) vs. MySQL Data Tier 13
T Performance von .list() Methode Data Tier 4
B Hibernate: Joins und Performance Data Tier 10
N Problem beim initialisieren des Caches Data Tier 0
S JPA Problem mit Cascading Data Tier 1
M Eclipse 4 RCP Hibernate Problem Data Tier 3
C JPA FetchType.LAZY, Relation @OneToMany und Problem mit dem update Data Tier 1
K Problem mit EJBs und Transaktionen Data Tier 0
G JPA: Entity Klasse @JoinColumns Problem Data Tier 2
M JPA Problem: java.sql.SQLSyntaxErrorException: Data Tier 7
H Hibernate Problem mit Lazy Loading bei @OneToMany Collections Data Tier 5
M MySql und JPA-Timestamp Problem Data Tier 8
J Hibernate Problem bei Master-Detail-Tabellen Data Tier 5
A JPA - ManyToMany Problem - keine Unique Mehrfachzuweisungen Data Tier 4
M Problem beim Laden von Objekten, die von anderen Applikationen in eine DB eingefügt wurden Data Tier 5
M Problem mit @Temporal Mapping und SQL Server Data Tier 3
P JPA - HashMap mit Many-to-Many Relation Problem Data Tier 4
B Problem mit @ManyToMany und CascadeType.ALL Data Tier 3
Blackskyliner [JPA][Anfänger] Problem mit Wertzuweisung aus Verbundtabelle Data Tier 2
B Problem mit org.hibernate.LazyInitializationException Data Tier 11
B DatenquellenUpdater extends Thread - Problem mit PermGenSpace Data Tier 5
S Problem beim Insert mit Hibernate Data Tier 9
Y [openJPA] Problem mit Transaktion? Data Tier 2
A @SecondaryTable Problem Data Tier 9
N Problem beim session.flush(); Data Tier 17
Y Postgres und JPA - Primärschlüssel Problem Data Tier 3
P SQL PRoblem Hibernate? Data Tier 8
Y EJB Problem mit Transaktionen Data Tier 7
M Transaction / Session Problem Data Tier 4
G JPA 2.0 Query Problem Data Tier 3
P CORBA Problem bei EJB 3.0 Anwendung in Glassfish v3 Data Tier 7
F Problem mit Hibernate Schema Update Data Tier 2
S Lazy loading Problem Data Tier 2
M Insert-Problem mit JPA/Hibernate Data Tier 4
megachucky JPA - Problem mit Persistence Unit / Context Data Tier 1
H Hibernate Problem Data Tier 4
T Problem mit openJPA Data Tier 7
P Problem mit Data Tier 9
GilbertGrape Cascade Problem (Hibernate) Data Tier 3
C JPA Problem mit attributeOverride und mehrspaltigem PK Data Tier 2
B select "neu" statement Problem (jpql) Data Tier 8
boxi Hibernate Lazy Loading Problem Data Tier 2
M Problem mit Hibernate und SLF4J - NoSuchMethodException Data Tier 3
G Connection Problem - WAS 6.1, Hibernate, OS Authentication Data Tier 1
K Hibernate update-Problem Data Tier 36
J hibernate problem Data Tier 14
N Hibernate - Problem mit Update/Insert Data Tier 4
B Problem mit @PersistenceContext Data Tier 4
G Problem with mapped of the tables at one to one relationship Data Tier 8

Ähnliche Java Themen


Oben