On 11/11/2022 5:38 am, Andralojc, Wojciech wrote:
Hi,
I’m running squid v4.13 in TLS bump mode.
Trying to configure it to get highest (single core) CPS (new TLS
sessions/connections per second) numbers.
I run multiple s_time tests on client side and “plain” nginx on server
side.
Example s_time command line:
openssl s_time -connect server:443 -new -cipher AES128-GCM-SHA256
-time 30 -CAfile /opt/proxy_rootCA.pem -tls1_2
Could you please review config below and suggest changes to improve
performance?
FYI; If this config you have shown is intended to go into production,
then I would suggest not using Squid at all.
Without logging, decryption, nor policy rules there is no benefit to
using Squid.
You would have better efficiency using NAT to redirect the traffic.
Assumptions:
* SSL bump/transparent SSL proxy;
Which definition of "transparent" do you mean exactly?
* The HTTP definition where it means a proxy does not alter the traffic?
* or the colloquial use where it means intercepting and filtering traffic?
Your provided config looks like it is trying to do both.
*
* single core performance;
* caching disabled;
* persistent connections disabled;
* no logs;
The last three of those assumptions are debatable.
* the use of a proxy naturally adds some amount of latency to traffic.
Caching is one of the major mechanisms used in HTTP to counter this cost
and when possible exceed it for extra performance. Whether it is useful
depends on how much (if any) of your traffic is cacheable.
* persistence connections are how HTTP (and HTTPS) avoid TCP connection
setup latency costs. Disabling is generally a loss of performance, but
some specific situations can benefit from it.
One of the things you should absolutely do is test is what impact
persistence has on your proxy performance, on each of the client/server
connection types independently.
* logging is a very minor impact. Processing the HTTP messages is by far
the largest part of Squid performance costs.
That said;
- store.log is almost always useless so that is OFF by default nowdays.
- access.log is minor work, it can be disabled for a trivial
reduction in CPU cycles at cost of not being able to see what clients
are doing with the proxy.
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet
http_access allow localhost
http_access allow all
You now have an open-proxy.
# Squid normally listens to port 3128
http_port 3128
http_port 3129 intercept
ssl_bump server-first all
"server-first" is deprecated.
Instead please use the new syntax:
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump splice all
https_port 3130 intercept ssl-bump cert=/etc/ssl/certs//rootCA.pem
generate-host-certificates=on
visible_hostname "proxy"
This should be an externally resolvable FQDN and not quoted.
tls_outgoing_options cafile=/etc/ssl/certs//nginx.pem
access_log none
cache_store_log none
Not needed, cache_store_log default is disabled anyway.
cache_log /dev/null
cache_log is not optional. If Squid has problems serving traffic that is
your only source of information about what happened.
To minimize what gets logged use this instead:
debug_options ALL,0
workers 1
If you have a multi-core machine this is not enough. You may also need
CPU affinity to lock the Squid processes to one core.
see <http://www.squid-cache.org/Doc/config/cpu_affinity_map/>
cache deny all
cache_mem 0
Okay, but if you have any plain-text or decrypted messages handled by
Squid at least some memory cache can have performance benefits.
This is something you should definitely test, measure, tune to see what
works best on your specific traffic.
server_persistent_connections off
client_persistent_connections off
See above.
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
