-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
On 7/7/20 18:32, Jerry Malcolm wrote:
> 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 mean... if you want to do more work and worry abot more resources,
free free to leave it in there. IMO the only reason to use httpd is if
you need something more complicated than what e.g. ELB can provide for
you. For example, classic ELB can't separate between two (or more)
applications running on each node under the same (external) hostname
and port. (Maybe Application Load Balancers can, but I haven't used them
.)
So if you have /foo and /bar applications then you need a reverse
proxy in addition to the ELB.
Another reason might be some kind of authentication system which is
plugged-into httpd but is not possible (or inconvenient) to configure
in Tomcat.
> 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.
ELB can handle TLS termination. If you want to use TLS between ELB and
your Tomcat instances, there's no particular reason to use httpd for
that: just use NIO+OpenSSL and you'll have comparable performance.
> But that's primarily because it worked, and I hadn't yet learned
> how to set up SSL in TC.
It's "easy" in the sense that is't not much more complicated than
doing it anywhere else. If you are familiar with all the pieces and
parts, you just need to know how to configure them in Tomcat. The
complexity of the process is in the whole x509/CA relationship, etc.
and not configuring the server itself.
> 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.
If you remove httpd, you should be cutting your connection count in
half, which I assume is a win for you.
> At least we can focus on one thing only. Thanks for the info and
> the link. I'll probably be back with more questions... :-)
Maybe start with configuring Tomcat for TLS. Modern Tomcats basically
just take this from httpd:
SSLProtocol [protocols]
SSLCertificateFile /path/to/key/and/cert/chain
SSLHonorCipherOrder On
SSLCipherSuite [cipher-suite-spec]
And turn it into this in Tomcat:
<Host ...>
...
<SSLHostConfig ciphers="[sipher-suite-spec]"
honorCipherOrder="true" protocols="[protocols]">
<Certificate certificateFile="/path/to/key/and/cert/chain" />
</SSLHostConfig>
</Host>
I'm not sure why both httpd and Tomcat's documentation say that having
a single file containing both the server's key and certificate is
"(NOT RECOMMENDED)". I see no security issues with that setup. You are
free to have separate files if you'd like. You can also use a keystore
to store your stuff but I find keystores to be cumbersome and like
PEM-encoded DER files better.
Leave httpd installed and configured, but just turn off the service
and maybe change the port number ELB is using to contact your server
(point it at :8080 instead of :80) and get Tomcat working. Once it's
working, you can start looking at monitoring.
Do you want to know how to monitor the instance so you can tell the
ELB when to auto-scale (up or down), or do you just want to "keep an
eye" on things so you can check to see if auto-scaling is "doing its job
"?
Thanks,
- -chris
> On 7/7/2020 5:23 PM, Christopher Schultz wrote: 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
>>
>> ---------------------------------------------------------------------
>>
>>
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
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F0U8ACgkQHPApP6U8
pFhdhQ//YUmNjJzTLHt577cLE3b8Tgf1xlL+UnVWSyLeW2Aom0w3L61eDAH3BW6t
67sdTZF1uSeyAhbtjAeW39bGg8Uu6QGLEe8JunS1zfylQf5wvsTOg2meFtX+vZvg
ef/NA6blbAFJfx+73JuoDoZoUmvZXyoYEqB9Ny203B/E35WEB+vHXZh4uiKvaws7
QDj58hCbXDuXKeIXcec3rk2+Syd7XSGRYnzD/nqsg9Zhj1Bc36dNlHJYE+31qT5N
q8xkq5ypJDY3+mT7eoUrjgUWV4BH2fBGCNwEn38Fe5RE59VhwWBoV3UmmQPsAOfn
KQnNom2aGJl8dkDGUvz+z0g66ULBSDzX8EqHRJc9p3wWxFJsmJyY/kdkxzbH38G4
+2+WWKBW9J/NBp6hbUv78XikiwPzs82YagGlQGQQzOOSgD+9hJe+oQYcjnbNZDXd
3eUMNw0tLY8+2LGk1jcpSzNkyKkTNgP4BNiRMExiEiC6W5kT12jJV8yfEaI+7jhp
wNKVvM+jBIlTKIiCv1tb5alqZ4YcwbO+HpG9F6/ttY/opwOTeHmUXW+FQeVTBWMw
OjsNRA7L3C6nFQQa9QaHICQl9Xnww1/ZrMWZTE3RxVt7lsKoCO6gFIzlcXxKyaRT
OO1Sj2XKehxBnlvGeTW4ujw/qp8ffspNtQWlduBUfEBgmcTTy0U=
=wX3c
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
