Hi ,
Steve, I think what Andy is saying is that your results are mainly looking
at the overhead of the library itself (you are persisting to an in-memory
DB). In real world apps the overhead of the persistence library layer
compared to end-to-end latency of network, DB, logic etc etc would make
this difference much much smaller. As an example take this program and the
conclusion one could draw from it:
public static void main(String[] args) {
long start, end, noslflatency, withslflatency;
start = System.currentTimeMillis();
for (long i = 0; i < 10000000000L; i++) {
}
end = System.currentTimeMillis();
noslflatency = end - start;
start = System.currentTimeMillis();
for (long i = 0; i < 10000000000L; i++) {
log.debug("Here is a log line with a single parameter {}", i);
}
end = System.currentTimeMillis();
withslflatency = end - start;
long fasterPercent = (withslflatency -
noslflatency)*100/noslflatency;
System.out.println("Using SLF4J is " + fasterPercent + "% slower
than not using it even when no logging happens");
}
*My Result: Using SLF4J is 51% slower than not using it even when no
logging happens*
I'm sure you would agree that in a real world program, adding logging that
does not log does not make it 51% slower...
As for me: I use JPA where it adds value/speed to the development cycle and
where performance is paramount I use native queries. Between them, we are
doing over 100M transactions a day on TomEE with response times on SOAP
services of about 15ms avg. TomEE and JPA can perform no problem.
But back to the original question - the issue must surely be a config issue
and if the poster could provide more details then I'm sure we can help.
Paul
On 2 November 2017 at 17:18, Romain Manni-Bucau <[email protected]>
wrote:
> @Steve: question is not why JPA is slow but why a server is slower
> than another one (which leads to a misconfiguration).
> DBUnit/Hibernate-stateless etc can be good elsewhere but not sure it
> helps here :(
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn
>
>
> 2017-11-02 16:16 GMT+01:00 Steve Goldsmith <[email protected]>:
> > The issues is performance and if this is a one off batch insert then I'm
> > offering a solution. Alternatives are good and yes as I described before
> I
> > survived fine without all the JPA "features" with a production
> application
> > handling millions of transactions a day. This isn't theoretical and it
> > works in the real world.
> >
> > I'm not sure why you think there's no transactions. Caching is simple
> using
> > JCache (my app did this as well) which is agnostic to the persistence
> > layer. If you think DbUtils adds 256% over pure JDBC then you really have
> > not used it before or done any testing with it. Most JDBC wrappers add
> very
> > little latency as most of that is happening in the database. In essence
> you
> > are writing about the same lines of code as well.
> >
> > Maybe you didn't take a close look at the tests, but it throws out the
> > first run to account for any initialization/lazy optimizations in JPA.
> > Again, you may not find it useful, but DbUtils been proven to be much
> > faster in production systems than JPA and that's what really matters to
> me
> > at least. If you can provision 3x more VMs for the same task then knock
> > yourself out.
> >
> > Sorry to annoy you and hopefully you will find a JPA solution for
> Prasenjit.
>
--
This email is subject to the disclaimer of Smile Communications at
http://www.smilecoms.com/home/email-disclaimer/
<http://www.smilecoms.com/disclaimer>
