Hello!

On Fri, Feb 01, 2013 at 04:42:31PM +0100, António P. P. Almeida wrote:

[...]

> Looking at htop, the config parsing is taking a lot of time. I know
> that because I also do a nginx -t before. It's just that I ommited
> that from the mail. Here they are:
>
> HOSTS,DATE,COMMAND,CPU_PERCENTAGE,CPU_SYSTEM,CPU_USER,ELAPSED_TIME,IO_PG_FAULTS,ICONTEXT_SWITCHING,VCONTEXT_SWITCHING,MAX_MEMORY
> 5001,01.Feb.2013 00:18:31,/usr/sbin/nginx_ensite 03805-08805.test-ssl.local.conf,93%,0.59,1.85,0:02.61,0,3450,17,138532
> 10001,01.Feb.2013 00:19:24,/usr/sbin/nginx_ensite 08806-18806.test-ssl.local.conf,93%,1.81,5.63,0:07.95,0,10684,16,406804
> 20001,01.Feb.2013 00:20:04,/usr/sbin/nginx_ensite 18807-38807.test-ssl.local.conf,93%,4.02,13.92,0:19.17,0,27021,17,945164
> 50001,01.Feb.2013 00:21:13,/usr/sbin/nginx_ensite 38808-88808.test-ssl.local.conf,93%,10.05,35.70,0:49.07,0,67976,17,2288672
>
> nginx_ensite is a small shell script that creates a symlink and does a
> nginx -t.

The "nginx -t" does various ssl initializations as well, much like
normal configuration (re)load.

Parsing the configuration by itself isn't costly, it's various ssl
function calls which are done while parsing are costly. You may
try it yourself by commenting ssl_ceritificate/ssl_ceritifcate_key
directives in your config, and looking at load/test times.

> > I don't think that parsing of the config is a culprit. More
> > likely it's SSL certificate reading/checking/various random
> > initialization/generation. (And may be server names hash
> > generation if there are many collisions on server names.)
>
> It's not my experience. In fact, several times I mangled up the cert
> names and he generated the not found cert error only quite late in the process.
>
> > Some profiling would be helpful.
>
> I did a ltrace and, hands down, string operations are the main
> thing. For a single server block.
>
> awk 'BEGIN {s=0} /strcmp/ {s+=$1} END {print s}' single_ltrace_function_stats_libs.csv
> -> 4417
>
> awk 'BEGIN {s=0} /memcpy/ {s+=$1} END {print s}' single_ltrace_function_stats_libs.csv
> -> 245
>
> awk 'BEGIN {s=0} /SSL/ {s+=$1} END {print s}' single_ltrace_function_stats_libs.csv
> -> 49
>
> So there are 49 ops for SSL functions against 4417 string comparisons.
>
> Is my reasoning flawed?

No, as long as you are don't care about time. But if you do - you
probably want to compare time spent in the functions, not number
of calls.

Additionally, while I'm not familiar with ltrace, I suspect it
will log various libc calls from openssl as well as ones done
directly from nginx, thus making the above stats completely
useless.

--
Maxim Dounin
http://nginx.com/support.html

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel