I going to assume that the reason I have apache httpd in there is
'because I always have had it there' is not going to go over well as a
good reason, huh? I used to use it to serve static files. But that is
pretty much taken over by S3 now. I still use it for the SSL stuff.
But that's primarily because it worked, and I hadn't yet learned how to
set up SSL in TC. It would definitely simplify things to get httpd out
of the picture and go straight to Tomcat. I'll start looking into
trying that in a sandbox and see if we can't simplify things. I still
have to worry about maxing out connections. But an 'only-Tomcat'
solution might ease a bit of the worries. At least we can focus on one
thing only. Thanks for the info and the link. I'll probably be back
with more questions... :-)
Jerry
On 7/7/2020 5:23 PM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
On 7/7/20 16:50, Jerry Malcolm wrote:
I'm setting up an environment that has the potential for a large
number of simultaneous requests coming in. I have a basic Apache
HTTPD with mod_jk talking to Tomcat, all on the same Amazon EC2
instance. From my understanding, I have the potential of maxing
out connections at httpd, at mod_jk, and also at Tomcat.
Yes, and you'll also need enough file handles and ports available for
all that. If one client-connection requires a connection to the web
server (1 file handle, 1 port) and a connection from httpd->Tomcat (2
file handles, 2 ports), it may add up quickly.
Are you sure you need httpd at all? I assume since you are AWS that
you are using a load-balancer. What purpose does httpd serve in your
setup?
We are looking at setting up monitors to track all of this. But I
don't want to reinvent the wheel if there are others who have
created solutions for this. Is there documentation on guidelines
for configuring connections on all three so that they work together
smoothly?
The golden rule applies, here, but that mostly affects you when you
have a multi-node cross-linked network like this:
httpd 1 -\ /- Tomcat 1
httpd 2 ------ Tomcat 2
httpd 3 -/ \- Tomcat 3
You have to make sure that if for some reason ALL conecctions from ALL
THREE web servers come-down on a SINGLE Tomcat node that it can handle
that number of connections. Those numbers are sometimes surprising to
people. If you have max-connections on each web server set to 200 then
each Tomcat needs to have a max-connections limit of 600, not 200.
We are setting up load-balancing on Amazon that will launch another
EC2 instance if one EC2 get overwhelmed. But that is obviously
dependent upon accurately tracking and recognizing that the EC2 is
indeed becoming overwhelmed. Any advice on where to start with
this?
First, I would find ways to get httpd out of the picture. That will
significantly reduce the complexity of the situation. If httpd is
providing significant value, then it's fine to leave it there: I'm not
in a crusade to remove httpd from the world; I'm just trying to remove
unnecessary components if they aren't providing value.
It used to be that Tomcat had to be fronted by a reverse-proxy for a
number of reasons (like mod_proxy not existing, for instance. Or that
TLS performance was awful. Or that httpd could significantly improve
response-times for static-content. None of that has been true for a
long time, now.
In terms of monitoring, feel free to have a look at my Monitoring
presentation[1] which may help get you started. It talks about
monitoring Tomcat connections only, but you could use similar
techniques to monitor httpd and also EC2.
The only knowledge I have about Amazon's auto-scaling is that it
exists. I'm really hoping someone will step-up and do an ApacheCon
presentation about cloud-native deployments of Tomcat in EC2 to take
advantage of things like auto-scaling, etc. Maybe you could be the one
to do it (seriously)!
- -chris
[1] http://tomcat.apache.org/presentations.html#latest-monitoring-with-j
mx
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8E9cgACgkQHPApP6U8
pFj8dhAAyShiMv2XtdlKQyaMzqpYhl0MCnrGGwtO9244P/eMPVgDJoHKw837H4iD
cPPr9BL7nYT4O5v0F6honS33ykzhddXhefIw8nAFQcZEkRkoJl/XlP4mGLQyf78E
JUvnSW+/7xuL+oJ3FGdpo5nQMnkTj4odnXwN3aHRPSz2yxpGZhlRKXxV3e6z4ama
Js5L9Ztc3T896oaDzzrA459M8/xm5eyUv5OaJIrPkGRE5kXB7i6IqpKDWRWZ56bU
FZlbAeKB3aoZx9Orj2tLp8YuOEcNVkSEPNLcpVnL+l/SMlkQUbxlHspejOBHE1sk
f2lyFTZ593Gqm3yzAk1HBT4A3QfPVPz5JKAEYm0RLpmq0zzkTKvSWZARYnGGQQZd
hZKGYaj1aafPIvSpsUlb4VJt22GxtkQk0PZ2d025KcZsX8TfFoV0mmbm3a/BDITT
/cP4h23OyReUgESrXQlHA2j8QDF4bmQnRxilPTXZXqkOIFXw/EdtAjLBoJ/U0wdT
S4jStnqqu3HkofshSNcGGLJ0K2LvopCnPk3449qcYSWcZN8xZ9OXfC8RYr17zqc3
FNlfPEreoEMqxxca39QDGcN2uSWeswZ9gZXsaz5tbYGs4wJLwRU4uSAfrvMB9eGd
9RFVIendlLa1hf3Rb3nevSxuXlSp6KyhuweU6R5pLQyubMM7ahM=
=FjkO
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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
