Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Cecil Westerhof Newsgroups: comp.lang.java.programmer Subject: Re: Performance JPA Date: Tue, 10 Nov 2015 08:07:37 +0100 Organization: Decebal Computing Lines: 53 Message-ID: <87si4e49ja.fsf@Equus.decebal.nl> References: <87lhagkcsh.fsf@Equus.decebal.nl> <563763d9$0$23727$e4fe514c@news.xs4all.nl> <87d1vrk20x.fsf@Equus.decebal.nl> <87ziyvhs0r.fsf@Equus.decebal.nl> <87mvuui2ws.fsf@Equus.decebal.nl> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="528adfd6ad074c92fdc6a7f8fb9e23d8"; logging-data="431"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19PBAOFiygOYV+azdUNt2Ui6auoP9C56rA=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Homepage: http://www.decebal.nl/ Cancel-Lock: sha1:p5iNiTezUKS6s1JdapXdPgHA+PY= sha1:9aemgzxR9UbgEHXjWJGO7yddkMI= Xref: csiph.com comp.lang.java.programmer:33070 On Wednesday 4 Nov 2015 09:28 CET, Cecil Westerhof wrote: > On Tuesday 3 Nov 2015 20:15 CET, Martin Gregorie wrote: > >> On Tue, 03 Nov 2015 19:11:48 +0100, Cecil Westerhof wrote: >> >>>> Bad performance can also be the result of poor DB management: >>>> most DBMS use DB statistics (row counts, etc) as input to the >>>> query optimiser. If these stats aren't automatically updated by >>>> the DBMS and the DBA doesn't update them regularly, or turned >>>> auto-stats update off then the optimiser can do a spectacularly >>>> poor job, e.g. if stats say a 100,000 table has only 10 rows then >>>> most optimisers would scan it sequentially because a sequential >>>> scan on a table that fits in one disk block will always be >>>> quicker than indexed access. >>> >>> But that should go wrong with JDBC and JPA I would think. >>> >> True, but are you running JPA against the original database >> instance that JDBC used to use, or has the data been copied into a >> clean development instance? > > No. Until now it where two completely different environments. I at > last managed to get them to test on the same test database. I should > soon get more trustworthy measurements. I got some progress. Last week the old and new version where run in the same environment/database. The performance problem still stood. So there is certainly a problem with the new program. Because several things have changed I am not sure what would be the problem, but the rest is convinced it is a JPA problem. In principal database logging is going to be enabled, but I am waiting already a week for this. Yesterday I was told that the queries themselves do not take a lot of time. In my opinion it could then be one of the other changes. But I am told that JPA does a lot of things beside retrieving things out of the database and that those other things JPA is doing are the problem. Sounds far-fetched to me, but this is the first time I am working with JPA. Could they be right? If so: how do we pinpoint this? I think it is time for profiling. As long as we are not sure what the problem is, it is impossible to solve it. Until now I never had to profile in Java. We work with Eclipse Kepler and IBM WebSpere Application Server v8.0. What are good resources to learn to profile the code? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof