tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edson Richter <>
Subject Re: Help in diagnosing server unresponsiveness
Date Fri, 01 Feb 2013 23:37:30 GMT
Em 01/02/2013 21:27, Howard W. Smith, Jr. escreveu:
>>> If you want to improve performance even more, ditch EJB altogether.
>>> Moving from APR to NIO may be a good move, but it really depends upon
>>> your requirements. For instance, APR provides superior SSL performance
>>> but if you don't need it, NIO will probably give you better results.
> Understood, thanks Chris. For now, only office personnel is accessing
> the web app behind a firewall, and others (including myself) access
> via laptop and mobile devices outside of the office via HTTP, so NIO
> is sufficient for now, until I'm ready to go HTTPS/SSL via APR.
>>> That depends upon what you want to accomplish. You can get messages
>>> about JDBC resource management problems without writing any
>>> interceptors at all.
> Okay, well,  I'm using JPA to access JTA managed datasource (Apache
> Derby), and I really don't think I have any JDBC resource management
> issues.

Have you look into your JPA graph and check if you are not loading 
millions of objects in memory?
While JPA is loading data from database, you will experience 
"unresponsiveness" as you said.
I do use PostgresSQL (that has superb performance, IMHO), and to 
discover the bloated references, I just had to set log to record all 
queries sent by the application.



>>> That depends upon what you mean by "clustering". If you want to serve
>>> more clients (or have fault-tolerance), then "clustering" is a good
>>> idea. "Clustering" means different things to different people. If you
>>> just want to scale horizontally (more app servers) and use simple
>>> load-balancing, that can be considered a cluster.
> For now, I want a cluster of at least 2 or 3 tomcat servers for
> fault-tolerance and load balancing.
>> When I mention thread programming, I mean WebApps that start (Java) threads
>> to do background work, like import data, send automatica notifications, and
>> so on. I know it is a (almost) bad practice to have web apps creating
>> threads, but this is so common in real world enterprise apps!
> Yes, I read that it is not good for web apps to start (Java) threads
> to do background work, and per that advise, I have avoided that for
> now. so far, I have used @Asynchronous and @Schedule, very minimally.
>>> In the Java world, most people would only call it a consider it a
>>> "cluster" if the app servers actually know about each other -- for
>>> instance, if you are using session replication. IMO session
>>> replication is a dog, and there are better ways to achieve similar
>>> goals that yield much higher performance.
> Chris, I'm glad you mentioned, "IMO session replication is a dog",
> because honestly, I would love to avoid some of the pre-work required
> to prepare my app for session replication. I'm definitely interested
> in the 'better ways to achieve similar goals. I would love to have 2
> or 3 instances of my web app accessing one database (Derby, at the
> present), and all 2 or 3 instances actually knowing about each other.
> :)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message