CPU 100% with njs on simple base64 decode (2.3.1)

[131@…]

I'm using a simple js_set to base64 decode (via String.bytesFrom)
as proxy_pass destination, and CPU goes too high (100%) under heavy load.

I can reproduce this using ab -c 200 -n 10000

ab -c 200 -n 10000 "​http://127.0.0.1/ping"
=> 0% CPU, all good

ab -c 200 -n 10000 "​http://127.0.0.1/proxy/string
=> 35% CPU, all good

ab -c 200 -n 10000 "​http://127.0.0.1/proxy/js_set
=> 100%CPU, no good.

I'm guessing the resolver also use CPU cycle, but i'm unhappy with current performances, is there something i can tweak ?

(switching to worker_processes auto helped a bit, but 'im still looking for something faster)

Thank you for your kind help

js_include "./conf.d/njs/x_proxypass.js";
js_set $x_proxypass x_proxypass;


server {
    listen       80 default_server;

    gzip off;

    location /ping {
      return 200 "pong";
    }

    location /proxy/string {
      aio threads;
      proxy_buffering off;
      proxy_pass 'https://131.github.io/ping';

    }

    location /proxy/js_set {
      aio threads;
      proxy_buffering off;
      proxy_pass $x_proxypass;
    }
   access_log  /dev/null;
}

function x_proxypass(r) {
  var src = 'aHR0cHM6Ly8xMzEuZ2l0aHViLmlvL3Bpbmc=';
  return String.bytesFrom(src, 'base64');
}

[131@…]

root@rproxy2:~# apt-cache policy nginx-module-njs
nginx-module-njs:
  Installed: 1.14.0.0.2.3-1~jessie

[Maxim Dounin]

You are using variables in the proxy_pass directive, and this means that:

• nginx will use dynamic resolution of the name provided (and this will require resolver to be defined or appropriate upstream block);
• as long as there is no corresponding upstream block defined, nginx will not be able to cache SSL sessions.

Since you are using https, this implies high CPU usage on uncached SSL handshakes compared to the variant with without variables. Adding a dummy upstream block should resolve this, try something like this:

upstream 131.github.io {
    server 131.github.io:443;
}

Alternatively, you can test njs base64() speed without using proxy_pass:

location /js_set {
    return 200 $x_proxypass;                                                                                             
} 

This should clearly show that it's not njs base64 decode which is the problem in your test.

[131@…]

Switching to a non https url is a full win, ab -n 10000 -c 200 stays under 10% CPU.

Thanks you a lot for your guidance.
And thanks again for njs, a perfect tool that came to me at the right time.