tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Carter-Brown <paul.carter-br...@smilecoms.com>
Subject Re: SQL insert taking too much time in TomEE-7.0.1
Date Thu, 02 Nov 2017 15:57:57 GMT
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 <rmannibucau@gmail.com>
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 <sgjava@gmail.com>:
> > 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>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message