tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis Monteiro <jlmonte...@tomitribe.com>
Subject Re: [Newsletter] Re: [Newsletter] Re: TomEE Performance
Date Tue, 04 Sep 2018 12:26:17 GMT
You are welcome.

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Tue, Sep 4, 2018 at 2:17 PM, <fabian-a.richter@rohde-schwarz.com> wrote:

> Hi Romain,
>
> thank you so much for your detailed feedback. After I created the second
> threaddump I had a look into it myself and came to the same conclusions. We
> will investigate further, and if there are any more TomEE related
> performance issues, I will get back in contact.
>
> Thanks all for the replies!
>
> Best
> Fabian
>
> -----Original Message-----
> From: Romain Manni-Bucau <rmannibucau@gmail.com>
> Sent: Tuesday, September 04, 2018 2:08 PM
> To: users@tomee.apache.org
> Subject: *EXT* [Newsletter] Re: [Newsletter] Re: TomEE Performance
>
> Hi Fabian,
>
> a few pointers and directions to check:
>
> 1. Ensure to test with securerandom.source=/dev/./urandom since you use a
> lot of crypto 2. You use hsqldb which is known to not scale very well with
> the concurrency, maybe switch to another database with a correctly
> configured connection pool 3. You use DataBaseRealm which does a lookup of
> the connection for each authentication which is synchronized and has no
> cache on the password hashes so it can be slow at runtime
>
> Personally i would start by using a fast realm (even if it always says
> "ok") to validate this hypothesis before investigating other cases.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog <
> https://rmannibucau.metawerx.net/> | Old Blog <
> http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <
> https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
>
>
> Le mar. 4 sept. 2018 à 12:15, <fabian-a.richter@rohde-schwarz.com> a
> écrit :
>
> > You were right, my student did something wrong with the first thread
> > dump, I uploaded a correct one:
> > https://gist.github.com/TrustedGate/83781f05950f245a3bfd2388c5bfd7ab
> >
> > Also at the bottom there is a vmstat result, its definitely
> > multithreaded
> > :)
> >
> > -----Original Message-----
> > From: Jean-Louis Monteiro <jlmonteiro@tomitribe.com>
> > Sent: Tuesday, September 04, 2018 11:59 AM
> > To: users@tomee.apache.org
> > Subject: *EXT* [Newsletter] Re: TomEE Performance
> >
> > I would need to check on this one and probably investigate a bit more
> > what you are doing.
> >
> > That being said, I can confirm only one thread is currently working.
> > So either jmeter is only sending monothreaded requests or there is
> > something else.
> > But you aren't doing multiple requests in parallel
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Tue, Sep 4, 2018 at 11:53 AM, <fabian-a.richter@rohde-schwarz.com>
> > wrote:
> >
> > > We have
> > >
> > > @Resource
> > > WebServiceContext webserviceContext;
> > >
> > > in our SOAP api class, that should not work with @Singleton, or am I
> > > mistaken?
> > >
> > >
> > > -----Original Message-----
> > > From: Jean-Louis Monteiro <jlmonteiro@tomitribe.com>
> > > Sent: Tuesday, September 04, 2018 11:41 AM
> > > To: users@tomee.apache.org
> > > Subject: *EXT* [Newsletter] Re: [Newsletter] Re: [Newsletter] Re:
> > > TomEE Performance
> > >
> > > Ah ok. Well I was asking if you were injecting when you took the
> > > thread dump because from a server point of view I saw only one
> > > thread working.
> > > If you were using jmeter with multiple virtual users, I was
> > > expecting to see more than one thread working.
> > >
> > > I'll double check.
> > >
> > > @Singleton is by default using Lock WRITE which prevents multiple
> > > threads to access the singleton.
> > > If you don't need synchronization or if your code is thread safe (no
> > > instance variables, etc). You can safely use @Singleton with Lock
> > > READ which will be faster than @Stateless because there is no pool
> > > involved. And again, there is no tuning to do
> > >
> > >
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > > On Tue, Sep 4, 2018 at 11:37 AM,
> > > <fabian-a.richter@rohde-schwarz.com>
> > > wrote:
> > >
> > > > Injecting? The jmeter was running during the threaddump. What do
> > > > you mean with injecting?
> > > >
> > > > Is Singleton (Lock.READ) not even more of a bottleneck when it
> > > > comes to multiple concurrent requests? IIRC we tried Singleton
> > > > before, but not sure what the reason was why we went with
> @Stateless...
> > > >
> > > > -----Original Message-----
> > > > From: Jean-Louis Monteiro <jlmonteiro@tomitribe.com>
> > > > Sent: Tuesday, September 04, 2018 11:30 AM
> > > > To: users@tomee.apache.org
> > > > Subject: *EXT* [Newsletter] Re: [Newsletter] Re: TomEE Performance
> > > >
> > > > Yes exactly.
> > > >
> > > > Were you injecting anything when you took the jstack?
> > > > It seems that only one thread is working.
> > > >
> > > > We would need you to do it when you are injecting.
> > > > If you could also give us the CPU usage when you take the jstack
> > > > that'd be great.
> > > > You can run `vmstat 5` on another terminal so you can see what's
> > > > going
> > > on.
> > > >
> > > > You are using Stateless Session beans. Any reason you aren't using
> > > > a plain singleton?
> > > > With Singleton (Lock.READ) there is no pooling involved, so you
> > > > don't have anything to configure or tune.
> > > >
> > > >
> > > >
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > > >
> > > > On Tue, Sep 4, 2018 at 10:53 AM,
> > > > <fabian-a.richter@rohde-schwarz.com>
> > > > wrote:
> > > >
> > > > > Like this:
> > > > > https://gist.github.com/TrustedGate/f670c079088404f42d69aabd409d
> > > > > e7c4
> > ?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jean-Louis Monteiro <jlmonteiro@tomitribe.com>
> > > > > Sent: Tuesday, September 04, 2018 8:38 AM
> > > > > To: users@tomee.apache.org
> > > > > Subject: *EXT* [Newsletter] Re: TomEE Performance
> > > > >
> > > > > Hi,
> > > > >
> > > > > Around SOAP, there are a couple of possible optimizations.
> > > > > What would be helpful is to get into the docker container when
> > > > > you are over the linear zone and get a jstack of the tomee process.
> > > > > Post it here or in gist and put the link here.
> > > > >
> > > > > Jean-Louis
> > > > >
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro http://www.tomitribe.com
> > > > >
> > > > > On Tue, Sep 4, 2018 at 8:27 AM,
> > > > > <fabian-a.richter@rohde-schwarz.com>
> > > > > wrote:
> > > > >
> > > > > > Hey,
> > > > > >
> > > > > >
> > > > > >
> > > > > > we have been running some performance tests with our
> > > > > > application (TomEE
> > > > > > 7.0.5 based) and are stuck:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Until 4 core VMs (or docker containers) we see a linear
> > > > > > increase in performance, which is great and was anticipated.
> > > > > >
> > > > > >
> > > > > >
> > > > > > But after 4 cores, we barely get 10% (with 8 cores) more
> > > > > > performance of the system.
> > > > > >
> > > > > >
> > > > > >
> > > > > > We used jmeter based load tests (SOAP calls) with 10/20/30/40
> > > > > > and
> > > > > > 100 threads, VM to VM via 1gbit, and 4 GB of RAM.
> > > > > >
> > > > > >
> > > > > > We played around with session bean pool sizes (min set to
> > > > > > thread count, max to 1000) and stateful bean pool settings and
> > > > > > also with jvm heap size and GC parameters, to no avail.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Are there any more performance parameters we can toy around
> > > > > > with in TomEE or Tomcat that you can recommend?
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thank you and best
> > > > > >
> > > > > > Fabian
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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