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.
Regards,
Edson
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: 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
