Re: [squid-users] A very low level question regarding performance of helpers.
On 12/02/2014 8:12 p.m., Alan wrote:
Hi Eliezer,
I know you have been testing fake helpers in a variety of languages.
How about this one in C?
Save it to helper-trivial.c and then compile it like this:
gcc -O3 trivial.c -o trivial
strip trivial
#include unistd.h
int main(int argc, char *argv[]) {
char in[256];
char out[3] = OK\n;
while (1) {
read(0, in, 256);
write(1, out, 3);
fsync(1);
}
}
This one will eventually hang and not exit after Squid disconnects. You
need the loop to be:
do {
...
} while (!feof(1));
NP: and helpers have to receive input lines of anywhere between 1KB and
32KB.
Amos
Re: [squid-users] A very low level question regarding performance of helpers.
On 02/09/2014 06:48 AM, Eliezer Croitoru wrote: I have helpers in all sort of languages and it seems to me that there is a limit that do exist on the interface between squid and the helpers by the nature of the code as code. For sequential helpers, the throughput is a function of response time: requests per second = number of helpers / mean response time where the response time is the time from the creation of the helper request (by Squid) to the end of processing of the helper response (by Squid). Thus, it includes overheads of all components participating in helper transaction (Squid, helper, OS, etc). For the so called concurrent helpers, the throughput ought to be unlimited as long as you are willing to increase concurrency levels, provide RAM, tolerate the response delays, etc. However, the above formula works for concurrent helpers with a given concurrency level if you replace number of helpers with configured concurrency level multiplied by the number of helpers. There may also be some helper API implementation limitations that lower the above theoretical limits, but I personally do not know of any specific ones. HTH, Alex.
Re: [squid-users] A very low level question regarding performance of helpers.
On Thu, Feb 13, 2014 at 7:40 AM, Alex Rousskov
rouss...@measurement-factory.com wrote:
On 02/09/2014 06:48 AM, Eliezer Croitoru wrote:
I have helpers in all sort of languages and it seems to me that there is
a limit that do exist on the interface between squid and the helpers by
the nature of the code as code.
For sequential helpers, the throughput is a function of response time:
requests per second = number of helpers / mean response time
where the response time is the time from the creation of the helper
request (by Squid) to the end of processing of the helper response (by
Squid). Thus, it includes overheads of all components participating in
helper transaction (Squid, helper, OS, etc).
It would be interesting to compare the time it takes for Squid to
process the helper transaction vs the time it takes to the helper to
give back a result. Some helpers can be complicated, so this can also
help us decide good values for the helper's ttl and cache limit.
And Amos is right about the code, it doesn't exit on eof (I thought
Squid sent it a signal to end it). But feof only works on streams, so
here is another version in case anybody (Eliezer?) is interested in
measuring this:
#include unistd.h
int main(int argc, char *argv[]) {
char in[32768];
char out[3] = OK\n;
while (0 read(0, in, 256)) {
write(1, out, 3);
fsync(1);
}
}
Re: [squid-users] A very low level question regarding performance of helpers.
Hi Eliezer,
I know you have been testing fake helpers in a variety of languages.
How about this one in C?
Save it to helper-trivial.c and then compile it like this:
gcc -O3 trivial.c -o trivial
strip trivial
#include unistd.h
int main(int argc, char *argv[]) {
char in[256];
char out[3] = OK\n;
while (1) {
read(0, in, 256);
write(1, out, 3);
fsync(1);
}
}
It can't get much faster than this. If you don't see a significant
difference with interpreted languages, it probably means that the
bottleneck is not the helper, but Squid.
As you can see, I don't disable buffering for stdin / stdout, instead
I flush stdout explicitly. This prevents reading one byte at a time,
as most (all?) helpers currently do.
I don't have any numbers to quantify the difference, but it has to be
faster than completely disabling buffering.
I posted a message to the mailing list about this on July 31st 2013.
It had a patch for the negotiate-kerberos-auth helper.
Regards,
Alan Mizrahi
On Sun, Feb 9, 2014 at 10:48 PM, Eliezer Croitoru elie...@ngtech.co.il wrote:
I have tried for a very long time to understand what are the limits of the
interface between squid and the helpers.
I have tested it with perl, python, ruby, java and other codes.
I am not yet sure if the STDIN\OUT is the relevant culprit in couple issues.
I have helpers in all sort of languages and it seems to me that there is a
limit that do exist on the interface between squid and the helpers by the
nature of the code as code.
I have reached a limit of about 50 requests per second on a very slow Intel
Atom CPU per helper which is not slowing down the whole squid instance else
then the code startup.
If you do have couple statistics please feel free to share them.
* (I have managed to build a I686 squid on CentOS 6.5)
Eliezer
Re: [squid-users] A very low level question regarding performance of helpers.
Hi Eliezer, I am sorry but from your mail I don't really understand what the problem is. What are you trying to do, and in what way you are being prevented from doing that? On Sun, Feb 9, 2014 at 2:48 PM, Eliezer Croitoru elie...@ngtech.co.il wrote: I have tried for a very long time to understand what are the limits of the interface between squid and the helpers. I have tested it with perl, python, ruby, java and other codes. I am not yet sure if the STDIN\OUT is the relevant culprit in couple issues. I have helpers in all sort of languages and it seems to me that there is a limit that do exist on the interface between squid and the helpers by the nature of the code as code. I have reached a limit of about 50 requests per second on a very slow Intel Atom CPU per helper which is not slowing down the whole squid instance else then the code startup. If you do have couple statistics please feel free to share them. * (I have managed to build a I686 squid on CentOS 6.5) Eliezer -- Francesco
Re: [squid-users] A very low level question regarding performance of helpers.
Hey Kinkie, I have tried to test couple helpers on squid. The helpers I have been using are for url_rewrite and some others. I have tested the helper based on 0 cache to allow full software utilization. Which means that the helper software will need to handle all requests. While from the software the is no concurrency allowed even if the STDIN\OUT allows concurrency... Still there is a limit of about 50 requests per second that one helper process can handle. I will try to test later on what happens in a case of a fake concurrency which is not really async but from the user perspective is concurrency. I am concluding my logic based on the X:3128/squid-internal-mgr/redirector logs. The main issue is slow response when using a specific helper. Eliezer On 02/10/2014 10:47 AM, Kinkie wrote: Hi Eliezer, I am sorry but from your mail I don't really understand what the problem is. What are you trying to do, and in what way you are being prevented from doing that?
[squid-users] A very low level question regarding performance of helpers.
I have tried for a very long time to understand what are the limits of the interface between squid and the helpers. I have tested it with perl, python, ruby, java and other codes. I am not yet sure if the STDIN\OUT is the relevant culprit in couple issues. I have helpers in all sort of languages and it seems to me that there is a limit that do exist on the interface between squid and the helpers by the nature of the code as code. I have reached a limit of about 50 requests per second on a very slow Intel Atom CPU per helper which is not slowing down the whole squid instance else then the code startup. If you do have couple statistics please feel free to share them. * (I have managed to build a I686 squid on CentOS 6.5) Eliezer
