Tomcat Executor MBean

[Vicky]

Hi,

I am using an embedded version of Tomcat 7.0.42. Using java executor with
either of the connectors i.e. BIO/NIO.

However while monitoring the server via JMX, I see the mbean attributes,

currentThreadCount

currentThreadsBusy

always showing the value "-1".

The only one that shows the appropriate dynamic value is connection count,
which seems to match the count of the client threads that I initiate.

Any idea how to get currentThreadCount and currentThreadsBusy to show the
right values?

Thanks

Re: troughput difference

[Rafael Oliveira de Mattos]

Christopher,


We are using only the http connector. Here is the configuration:



The server has 8 cores.


-Rafael

- Mensagem original -
De: "Christopher Schultz" 
Para: "Tomcat Users List" 
Enviadas: Segunda-feira, 21 de dezembro de 2015 14:33:31
Assunto: Re: troughput difference

Rafael,

On 12/17/15 3:09 PM, Rafael Oliveira de Mattos wrote:
> I'm having different results in Tomcat performance using version 6.0.37 and 
> 8.0.23. 
> 
> Using tomcat 6 we usually have 
> 5000 ~ rpm with a response time of 80ms 
> 
> Using tomcat 8 the max that we can get is 
> 2000 ~ rpm with a response time of 200ms 
> 
> We are using the same jdk version 1.7.0.80, a nd the same applications on 
> both version, they are installed in the same machine and using APR, but not 
> running at the same time. 
> We tried to use the same configuration whenever possible. 
> 
> SO: Linux ubuntu 12.04 
> JDK: 1.7.0.80 
> Anything I should take look at it? 

How are your s defined in server.xml in each setup?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: troughput difference

[Christopher Schultz]

Rafael,

On 12/17/15 3:09 PM, Rafael Oliveira de Mattos wrote:
> I'm having different results in Tomcat performance using version 6.0.37 and 
> 8.0.23. 
> 
> Using tomcat 6 we usually have 
> 5000 ~ rpm with a response time of 80ms 
> 
> Using tomcat 8 the max that we can get is 
> 2000 ~ rpm with a response time of 200ms 
> 
> We are using the same jdk version 1.7.0.80, a nd the same applications on 
> both version, they are installed in the same machine and using APR, but not 
> running at the same time. 
> We tried to use the same configuration whenever possible. 
> 
> SO: Linux ubuntu 12.04 
> JDK: 1.7.0.80 
> Anything I should take look at it? 

How are your s defined in server.xml in each setup?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Zero downtime deployments

[Jason Britton]

Following back up after perusing Chris' very helpful presentation (
http://people.apache.org/~schultz/ApacheCon%20NA%202015/Load-balancing%20Tomcat%20with%20mod_jk.pdf)
on
load balancing tomcats with mod_jk.

One part not mentioned was session fail over.  Which my current plan is to
use JDBCStore for persisting to a database table shared by all tomcats
powering apps.  But this has brought up a couple concerns...  If while a
tomcat node is being shut down and triggered by this shut down tomcat is in
the middle of writing out session data to the JDBCStore, a request from a
client that was using that node comes in, mod_jk tries to route the request
to the node that is shutting down but mod_jk's configured connect_timeout
times out waiting and mod_jk then routes to another node (hopefully that's
how this works).  A different active tomcat node now receives the request
and tries to reconstitute the user's session from the same shared
JDBCStore, but what if the first tomcat node is not finished shutting down
and has not finished writing out this particular user's session data yet?
How can we ensure that session data will be there?

>From looking at the config of the Manager, there is a maxIdleBackup
parameter that I imagine could be set to 0 but I'm a little wary of the
possible performance implications.  Its description: The time interval (in
seconds) since the last access to a session before it is eligible for being
persisted to the session store, or -1 to disable this feature. By default,
this feature is disabled.  Even if this was ok from a performance
perspective, once a session was initially persisted, would its session data
be updated in the session store on subsequent changes/requests?

I've read about some folks configuring valves for shared in-memory caches
(redis), I'm not sure I want to go that route at this point.

Any thoughts would be much appreciated,

Jason


On Tue, Dec 8, 2015 at 10:43 AM, Kevin Hale Boyes  wrote:

> On 4 December 2015 at 11:19, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Kevin,
> >
> > On 12/3/15 2:21 PM, Kevin Hale Boyes wrote:
> > > Thanks for this link to the presentation.
> > > How do you all deal with some of the other dependencies that the web
> > > application has?
> > >
> > > For example, if v2 of my application needs new database columns or
> > worse, a
> > > change to an existing column how can I have v1 and v2 running at the
> same
> > > time?  We use Oracle as our database though the problem exists for many
> > > database servers.
> >
> > That's not a deployment problem. That's a design problem.
> >
> > In short, you need to make sure that your web application is both
> > forward-compatible and backward-compatible at the same time.
> >
> > That's rubbish, or course. Here's a more concrete suggestion, and it
> > requires a LOT of work, but it's worth it.
> >
> > First of all, you can't think of a release as a single event any more.
> > Instead, there are 4 events.
> >
>
>
> We already do this sort of development when needed.  In particular, when we
> have database changes that will take a long time like back populating new
> columns or creating new indexes on large tables, we run then in a
> pre-release phase against live production.  We time the activities to
> finish just before our release window.  Sometimes we also have post-release
> database activities as well that follow shortly after our release outage.
>
> I guess I hadn't extended my thoughts far enough and seen the full
> potential of the idea so thanks.
> One drawback for us when we use this mechanism is related to our release
> schedule.  We release on a quarterly basis so having a process that spans
> four releases pushes it out for an entire year.  But that's our problem and
> we're making headway there too.
>
> Thanks Christopher
> Kevin.
>