<div dir="ltr">Hey Alex,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If there are a lot more requests than your users/TTLs should generate,<br>then you may be able to decrease db load by figuring out where the extra<br>requests are coming from.</blockquote><div><br></div><div>actually, I don't think it matters much now that I think about it again, since as per my requirements,</div><div>I need to reload the cache every 60 seconds, which means that even if it is perfect, MariaDB will still </div><div>get a high load. I think the second approach will be better suited.</div><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and/or adding database<br>power (e.g., by introducing additional databases running on previously<br>unused hardware -- just like your MariaDB idea).</blockquote><div><br></div><div>That is an excellent point,  I think I will work on a central connection aggregator as you suggested,</div><div>and also put in more DB power via Redis on K8S. This way it will best fast and scale automatically.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">aggregating helper-db connections (helpers can be written to<br>talk through a central connection aggregator)</blockquote><div><br></div><div> That sounds like exactly what I am looking for, how would one go about doing this?</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 8, 2022 at 4:41 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/8/22 09:13, roee klinger wrote:<br>
<br>
> I am running multiple instances of Squid in a K8S environment, each <br>
> Squid instance has a helper that authenticates users based on their <br>
> username and password, the scripts are written in Python.<br>
> <br>
> I have been facing an issue, that when under load, the helpers (even <br>
> with 3600 sec TTL) swamp the MariaDB instance, causing it to reach 100% <br>
> CPU, basically I believe because each helper opens up its own connection <br>
> to MariaDB, which ends up as a lot of connections.<br>
> <br>
> My initial idea was to create a Redis DB next to each Squid instance and <br>
> connect each Squid to its own dedicated Redis. I will sync Redis with <br>
> MariaDB every minute, thus decreasing the connections count from a few <br>
> 100s to just 1 every minute. This will also improve speeds since Redis <br>
> is much faster than MariaDB.<br>
> <br>
> The problem is, however, that there will still be many connections from <br>
> Squid to Redis, and I probably that will consume a lot of DB resources <br>
> as well, which I don't actually know how to optimize, since it seems <br>
> that Squid opens many processes, and there is no way to get them to talk <br>
> to each other (expect TTL values, which seems not to help in my case, <br>
> which I also don't understand why that is).<br>
> <br>
> What is the best practice to handle this? considering I have the <br>
> following requirements:<br>
> <br>
>     1. Fast<br>
>     2. Refresh data every minute<br>
>     3. Consume as least amount of DB resources as possible<br>
<br>
I would start from the beginning: Does the aggregate number of database <br>
requests match your expectations? In other words, do you see lots of <br>
database requests that should not be there given your user access <br>
patterns and authentication TTLs? In yet other words, are there many <br>
repeated authentication accesses that should have been authentication <br>
cache hits?<br>
<br>
If there are a lot more requests than your users/TTLs should generate, <br>
then you may be able to decrease db load by figuring out where the extra <br>
requests are coming from. For example, it is possible that your <br>
authentication cache key includes some noise that renders caching <br>
ineffective (e.g., see comments about key_extras in <br>
squid.conf.documented). Or maybe you need a bigger authentication cache.<br>
<br>
If the total stream of authentication requests during peak hours is <br>
reasonable, with few unwarranted cache misses, then you can start <br>
working on aggregating helper-db connections (helpers can be written to <br>
talk through a central connection aggregator) and/or adding database <br>
power (e.g., by introducing additional databases running on previously <br>
unused hardware -- just like your MariaDB idea).<br>
<br>
<br>
Cheers,<br>
<br>
Alex.<br>
</blockquote></div>