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 <eliezer@xxxxxxxxxxxx> 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
