Transparent vs Tproxy: performance ?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Transparent vs Tproxy: performance ?

David Touzeau-3

Hi

 

We have 2 ways to make the squid in « transparent mode. »

 

The standard Transparent method and (with modern kernels)  the use of « Tproxy » method

 

I would like to know which is the best according to the performance ?

 

Or is it the same ?

 

Best regards.


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent vs Tproxy: performance ?

Amos Jeffries
Administrator
On 1/09/18 9:33 PM, David Touzeau wrote:
> Hi
>
> We have 2 ways to make the squid in « transparent mode. »
>
> The standard Transparent method and (with modern kernels)  the use of
> « Tproxy » method
>

Please clarify what this "standard transparent" thing is you referring to?

I suspect that you actually mean "NAT" which is completely separate from
Squid and thus has no bearing on proxy performance.



> I would like to know which is the best according to the performance ?
>

This is a meaningless question. "comparing apples to oranges", etc.

You might as well ask if NAT is faster or slower than packet flow?


Both NAT and TPROXY involve kernel managing tables of active connections
and syscalls by Squid to search those tables on every accept(). Only the
timing of those syscalls and the state listed in the tables differ. The
limitations each imposes are more relevant than performance differences.

Specifically;

* TPROXY restricts the TCP ports available to clients to 31K, where
normally they are 63K.

* NAT systems restrict ports to (63*M)/N where N is number of clients on
the network, and M the number of IPs available to Squid outbound
(usually 1).

As you can see those will impose a cap on both performance and
capability of your network. How much is determined by your network size
and traffic peak flows. Not by anything related to Squid.


Squid performance should be essentially the same for all traffic
"modes". It is driven by the HTTP features used in the messages
happening, combined with what types of processing your config requires
to be done on those messages.
So by crafting the very extreme types of message one can flood a Gbps
network with a single HTTP request, or pass thousands of transactions
quickly over a 56Kbps modem link.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent vs Tproxy: performance ?

David Touzeau-3
Thanks Amos,

Yes my question was " if NAT is faster or slower than packet flow" and yes you are right.

"Squid is not impacted to this question, this make sense."


I had a "feeling" (human sensation) - with 3.000 users that NAT was faster than Tproxy...

But you confirm that this is not relevant...

Best regards,


-----Message d'origine-----
De : squid-users <[hidden email]> De la part de Amos Jeffries
Envoyé : samedi 1 septembre 2018 17:07
À : [hidden email]
Objet : Re: [squid-users] Transparent vs Tproxy: performance ?

On 1/09/18 9:33 PM, David Touzeau wrote:
> Hi
>
> We have 2 ways to make the squid in « transparent mode. »
>
> The standard Transparent method and (with modern kernels)  the use of
> « Tproxy » method
>

Please clarify what this "standard transparent" thing is you referring to?

I suspect that you actually mean "NAT" which is completely separate from Squid and thus has no bearing on proxy performance.



> I would like to know which is the best according to the performance ?
>

This is a meaningless question. "comparing apples to oranges", etc.

You might as well ask if NAT is faster or slower than packet flow?


Both NAT and TPROXY involve kernel managing tables of active connections and syscalls by Squid to search those tables on every accept(). Only the timing of those syscalls and the state listed in the tables differ. The limitations each imposes are more relevant than performance differences.

Specifically;

* TPROXY restricts the TCP ports available to clients to 31K, where normally they are 63K.

* NAT systems restrict ports to (63*M)/N where N is number of clients on the network, and M the number of IPs available to Squid outbound (usually 1).

As you can see those will impose a cap on both performance and capability of your network. How much is determined by your network size and traffic peak flows. Not by anything related to Squid.


Squid performance should be essentially the same for all traffic "modes". It is driven by the HTTP features used in the messages happening, combined with what types of processing your config requires to be done on those messages.
So by crafting the very extreme types of message one can flood a Gbps network with a single HTTP request, or pass thousands of transactions quickly over a 56Kbps modem link.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent vs Tproxy: performance ?

Amos Jeffries
Administrator
On 2/09/18 10:13 PM, David Touzeau wrote:

> Thanks Amos,
>
> Yes my question was " if NAT is faster or slower than packet flow" and yes you are right.
>
> "Squid is not impacted to this question, this make sense."
>
>
> I had a "feeling" (human sensation) - with 3.000 users that NAT was faster than Tproxy...
>
> But you confirm that this is not relevant...
>

It may be for you. That user count vs your bandwidth is more relevant
than the features performance.

For any given bandwidth total;
 NAT should cope better with higher user count,
 TPROXY should cope better with higher per-user consumption.

So "best" is a matter of how those stack up on your specific network.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users