[squid-users] Setting Squid to work with a remote DB?

[Alex Rousskov]

On 8/28/21 2:59 PM, roee klinger wrote:

> I have multiple Squid servers installed in different data centers across
> different cloud providers, and they all need to authenticate users using
> a single database (MySQL) on a separate server, which is also on a
> different cloud provider on a different data center.
> 
> I have already written an external authentication script that reads from
> MySQL and everything is working fine, however, I have some
> performance concerns, since the DB is located externally and in a
> different region of the world from the Squid server.
> 
> I made some speed tests to see how long it takes to query the DB as
> Squid would:
> 
> if the database is located on the same machine as Squid:
> 1.067-millisecond average query
> 
> if the database is located on the same datacenter as Squid:
> 2.67-millisecond average query
> 
> if the database is located on a different datacenter than Squid
> (different country as well): 38.9-millisecond average query
> 
> 
> Now I am wondering, is 36-millisecond average added query time a big
> deal when dealing with HTTP/S traffic? how significant is this added
> time to Squid and will performance get hurt drastically?

* When you look at a single HTTP transaction, adding 36ms is usually not
a big deal: Humans are incapable of discerning such delays and
automatons that need true real-time performance are unlikely to go
through your Squids.

* Additional 36ms added to mean transaction response time create
significant perceived delays for sites/services that load lots of
resources _sequentially,_ especially if such a site/service has lighting
fast response times without those extra delays. For example, without
authentication caching and similar optimizations, a cumulative extra
delay of 100 sequential transactions (that would normally take, say,
300ms total) would be 3.6 seconds -- something many humans will be
annoyed with!

* Additional 36ms added to mean transaction response time can kill
performance of a Squid instance that is operating at the limit of some
resource capacity.

For example, imagine that, without authentication delays, your Squid
transactions have 10ms mean response time, and your Squid instance is
dealing with 10'000 requests per second load. That combination results
in just 100 concurrent requests (10'000r/s * 0.01s = 100r). If you add
36ms to that 10ms response time, your Squid would have to deal with 460
concurrent requests (10'000r/s * 0.046s = 460r) -- a 360% increase in
concurrency levels and associated resource consumption. Such an increase
is likely to maim any Squid that was operating without significant spare
resources.

For an opposite example, imagine that, without authentication delays,
your Squid transactions have 1 second mean response time, and your Squid
instance is dealing with 10'000 requests per second load. That
combination results in 10'000 concurrent requests. If you add 36ms to
that 1s response time, your Squid would have to deal with 10'360
concurrent requests -- a mere 3.6% increase in concurrency levels and
associated resource consumption.

Keep in mind that as Squid approaches resource limits, things usually
get _exponentially_ worse.


The impact of additional authentication delays should be fairly easy to
model/test.


HTH,

Alex.


> I know there is some caching going on the Squid side, but I had to set
> the caching to really low values (around 15s), as per the requirement I
> was given.
> 
> If I will have no other choice, I will simply replicate the DB table
> from the DB server to the Squid server, but I prefer not to do that, as
> it will require installing MySQL on all the Squid servers (or some other
> DB, but then I have to do replication from different DBs).
> 
> Thanks.
> 
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>