30. HTTPS and pooling¶
ShimmerCat QS
can also provide support for HTTPS and pooling!
30.1. HTTPS¶
Just add an encryption-level: tls
to the consultant definition.
As in:
---
shimmercat-devlove:
domains:
elec www.proba.com:
root-dir: /srv/www.mounted.files/
views-dir: files
consultant:
connect-to: "4047"
encryption-level: tls
application-protocol: http
Notice that at the moment, if you enable TLS, you also need to specify an application protocol, with both fastcgi
and http
supported as application protocols.
Note that HTTPS
is just HTTP/1.1 + TLS.
30.2. Pooling¶
HTTPS connection pooling works by having several channels open simultaneously, and using them on demand for the needs of ShimmerCat:
Fetching dynamic HTML
Fetching static assets
Whenever a connection is idle for a set period of time, the connection is closed to save resources. Here is an example of how it’s configured, the whole shebang:
---
shimmercat-devlove:
domains:
elec www.supershoes.com:
root-dir: /srv/www.supershoes.com
changelist-settings:
tNew: 20
tOld: 72000
consultant:
connect-to: "8098"
application-protocol: http
encryption-level: tls
pooling:
max-size: 4
max-idle: 5.0
The above snippet configures the default consultant “default” to use a pool of HTTPS connections with maximium 4 connections, each of which can idle up to five seconds before being closed. Notice that the configuration above will still try to fetch from the local filesystem (which in turn can be a network mount).
The connection pool size is for each ShimmerCat worker process.
By default, ShimmerCat creates a pool of 3 workers, but that can be changed with the --worker-count
option of ShimmerCat
.
In any case a max-size
of 4 is kind of small for a high traffic website.
Changing both things, we can get a better configuration this way:
---
shimmercat-devlove:
domains:
elec www.supershoes.com:
root-dir:
use-consultant: default
changelist-settings:
tNew: 20
tOld: 72000
consultant:
connect-to: "8098"
application-protocol: http
encryption-level: tls
pooling:
max-size: 256
max-idle: 5.0
IMPORTANT: the max-idle
time should be chosen in such a way that it doesn’t cause problems
with the remote side closing connections too eagerly.
For example, if the consultant on the other end is an Nginx instance with default configuration,
Nginx will time-out connections after two seconds.
In that case, our max-idle
should be lower than two seconds.
At the moment, our pooling implementation doesn’t handle these cases very gracefully, and the “gracefull handling”
logic looks convoluted and brittle… it’s far better to set a low max-idle
.
Of course we can always test what works and what doesn’t.