> On 29 Aug 2017, at 14:24, Mark Thomas <ma...@apache.org> wrote:
> On 29/08/17 13:09, Ing. Andrea Vettori wrote:
>>> On 29 Aug 2017, at 12:29, Suvendu Sekhar Mondal <suv3...@gmail.com> wrote:
>>> On Tue, Aug 29, 2017 at 2:54 PM, Ing. Andrea Vettori
>>> <a.vett...@b2bires.com> wrote:
>>>> - with a fresh started tomcat instance, the time it takes is around 0,8
>>>> seconds. Most of the time is spent on the two RMI calls the task does.
>>>> - with an instance that is running from some time, the time can reach 2/3
>>>> seconds; occasionally 5/6 seconds. Most time is still spent on RMI calls.
>>>> I.e. what slows down are the RMI calls.
>>> Sill question, do you mean RMI calls generating from Tomcat is getting
>>> slower with time? or, JBoss is taking time to return the response?
>> Thanks for your help.
>> What I see is that the http requests are slower. Looking at the details of
>> that specific request (putting a product in the cart) using System.nanotime
>> I can see that most of the time is spent during the RMI calls. I’m pretty
>> sure it’s not jboss that is slower because doing other calls at the same
>> time with fresh tomcats or with a java client they're not slow.
> I'd try profiling the problematic code. Given the magnitude of the
> times, sampling should be sufficient which means you could do this on
> production when the problem happens. You'll probably need to configure
> it to log JVM internal calls.
Profiling the code I have been able to find the cause of the big metaspace
Due to a bug, we were not caching remote interfaces when connecting to jboss
from the web sites. Other client kind was ok.
Fixed this problem today, it’s a few hours that the system is running fine.
It’s fast (faster than before even with a fresh tomcat); metaspace says low and
everything is fine.
This solves my problem. Thanks to everybody that helped with comments and
Still ’m very curios to know why big metaspace causes such increasing slowness…
looking at the GC logs it seems not a gc problem… maybe metaspace handling by
the jvm is not optimal when it’s big ?
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org