[squid-users] I would like to know performance sizing aspects.
vacheslav
m_zouhairy at skno.by
Thu Aug 6 05:31:59 UTC 2020
having 3GB memory with a ufdb improves performace
6.08.20 08:28, m k пишет:
> Eliezer,
>
> Squid's default setting is 1 core CPU, 16GB mem.
> How many URLs(Blacklist) will degrade Squid's performance?
>
> Also, SSL-Bump.
>
> Thank you,
> kitamura
>
>
> 2020年8月6日(木) 13:38 Eliezer Croitor <ngtech1ltd at gmail.com
> <mailto:ngtech1ltd at gmail.com>>:
>
> Kitamura,
>
> About the tens of thousands of URLs, Have you considered using a
> Blacklisting utility, it might lower the memory footprint.
>
> Eliezer
>
> ----
>
> Eliezer Croitoru
>
> Tech Support
>
> Mobile: +972-5-28704261
>
> Email: ngtech1ltd at gmail.com <mailto:ngtech1ltd at gmail.com>
>
> *From:* squid-users <squid-users-bounces at lists.squid-cache.org
> <mailto:squid-users-bounces at lists.squid-cache.org>> *On Behalf Of *m k
> *Sent:* Thursday, August 6, 2020 7:25 AM
> *To:* Amos Jeffries <squid3 at treenet.co.nz
> <mailto:squid3 at treenet.co.nz>>
> *Cc:* squid-users at lists.squid-cache.org
> <mailto:squid-users at lists.squid-cache.org>
> *Subject:* Re: [squid-users] I would like to know performance
> sizing aspects.
>
> Amos,
>
> Thank you for your reply.
>
> It was very helpful.
>
> > That number was gained before HTTPS became so popular. So YMMV
> depending
> > on how many CONNECT tunnels you have to deal with. That HTTPS
> traffic can possibly be decrypted
>
> > and cached but performance trade-offs are quite large.
>
> Squid uses SSL-Bump.
>
> I'm very worried about the internet slowing down due to https
> decording. and I'm also worried about the internet slowing down
> due to using Blacklist.
>
> I load tens of thousands of URL(black list file) every time I set
> up ACL.
>
> How many requests does SSL-Bump in one second?
>
> Thank you,
>
> kitamura
>
> 2020年8月5日(水) 10:32 Amos Jeffries <squid3 at treenet.co.nz
> <mailto:squid3 at treenet.co.nz>>:
>
> On 5/08/20 11:28 am, m k wrote:
> >> We are considering to use Squid for our proxy, and would
> like to know
> >> performance sizing aspects.
> >>
> >> Current web access request averages per 1 hour are as
> followings
> >> Clients：30,000、
> >> Page Views:141,741/hour
> >> *Requests:4,893,106
> >>
>
> Okay. Requests and client count are the important numbers there.
>
> The ~1359 req/sec is well within a default Squid capabilities,
> which can
> extend up to around 10k req/sec before needing careful tuning.
>
> That number was gained before HTTPS became so popular. So YMMV
> depending
> on how many CONNECT tunnels you have to deal with. That HTTPS
> traffic
> can possibly be decrypted and cached but performance
> trade-offs are
> quite large.
>
>
> >> We will install Squid on CentOS 8.1. Please kindly share your
> >> thoughts / advices
>
> Whatever OS you are most comfortable with administering. Be
> aware that
> CentOS official Squid packages are very slow to update -
> Apparently they
> still have only v4.4 (8 months old) despite a 8.2 point
> release only a
> few weeks ago.
>
> So you may need to be building your own from sources and/or
> using other
> semi-official packagers such as the ones from Eliezer at
> NGTech when he
> gets around to CentOS 8 packages.
> <https://wiki.squid-cache.org/KnowledgeBase/CentOS>
>
>
> FYI; If you find yourself having to use SSL-Bump, then we highly
> recommended to follow the latest Squid releases with fairly
> frequent
> updates (at minimum a few times per year - worst case
> monthly). If you
> like CentOS you may find Fedora more suitable to track the
> security
> environment volatility and update churn.
>
>
> >> Is there sizing methodology and tools?
>
> There are a couple of methodologies, depending on what aspect
> you are
> tuning towards - and one for identifying the limitation points
> to begin
> a tuning process tuning.
>
> The info you gave above is the beginning. Checking to see if your
> traffic rate is reasonably within capability of a single Squid
> instance.
>
> Yours is reasonable, so next step is to get Squid running and
> see where
> the trouble points (if any) are.
>
> For more see <https://wiki.squid-cache.org/SquidFaq/>
>
>
>
> >> How much resources are generally recommended for our
> environment?
> >> CPU: Memory: Disk space : Other factors to be considered
> if any:
> >> Do you have a generally recommended performance testing
> tools? Any
> >> suggested guidelines?
> >>
>
>
> CPU - squid is still mostly single-process. So prioritize
> faster GHz
> rates over core number. Multi-core can help of course, but not
> as much
> as cycle speeds do. Hyper-threading is useless for Squid.
>
> Memory - Squid will use as much as you can give it. Let your
> budget
> govern this.
>
> Disk - Squid will happily run with no disk - or lots of large
> ones.
>
> - Avoid RAID. Squid *will* shorten disk lifetimes with its
> unusually
> high write I/O pattern. How much shorter varies by disk type
> (HDD vs
> SSD). So you may find it better to plan budget towards
> maintenance costs
> of replacing disks in future rather than buying multiple
> up-front for
> RAID use.
> see <https://wiki.squid-cache.org/SquidFaq/RAID> for details.
>
> - Up to a few hundred GB per cache_dir can be good for
> large caches.
> Going up to TB is not (yet) worth the disk cost as Squid has a
> per-cache
> limit on stored objects.
>
> - Disk caches can be re-tuned, added, moved, removed,
> and/or extended
> at any time and will depend on the profile of object sizes
> your proxy
> handles - which itself likely changes over time. So general
> let your
> budget decide the initial disks and work from there.
>
>
>
> Load Testing - the tools us dev use to review performance are
> listed at
> the bottom of the profiling FAQ page. These are best for
> testing the
> theoretical limits of a particular installation - real traffic
> tends to
> be somewhat lower. So I personally prefer taking stats from
> the running
> proxy on real traffic and seeing what I can observe from those.
>
>
> HTH
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> <mailto:squid-users at lists.squid-cache.org>
> http://lists.squid-cache.org/listinfo/squid-users
>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20200806/ab9962aa/attachment-0001.htm>
More information about the squid-users
mailing list