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: Wed, 04 Nov 2015 09:28:51 +0100 Organization: Decebal Computing Lines: 54 Message-ID: <87mvuui2ws.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="528adfd6ad074c92fdc6a7f8fb9e23d8"; logging-data="25727"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/blDTIF7pMzIdRe9BfxrIvefn1msy3190=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Homepage: http://www.decebal.nl/ Cancel-Lock: sha1:oy+C0LlHl1pZ1jlLaRwInHZsNH4= sha1:ehXMbbuDIGU79tA/p0GFghnOT3c= Xref: csiph.com comp.lang.java.programmer:32995 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 would hope the latter is the case because performance comparisons > are invalid unless the data volumes are the same for both old and > new code but it would be quite unwise to be running code under > system test against the main database. If the data has been copied, > then you need to be sure that the DB stats on the DB copy are up to > date, which is what I was on about. > > You also need to be certain that the schemas are identical: it only > needs tweaks to have been applied to the old database during a late > night emergency fix, i.e. indices added to tables or the physical > placement and/ or partitioning of database components changed, and > for the fixer to forget to or not be given time to record the > changes in the development schema and documentation for this sort of > error to creep into the system. > > The worst part is that nobody will know this happened until the > organisation needs to build a new integration test system after a > major upgrade because its only then, when a clean instance has been > set up and loaded with data from the old system that unexpected > performance differences or outputs show up. Finding and fixing this > sort of change can be a real headache. In a way I am glad this happened. It proves the importance of really good tests. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof