Re: Вопрос по производительности.
Валентин Бартенев Wrote: --- On Tuesday 23 June 2015 09:05:23 BieZax wrote: [..] После того, как кол-во ответов перестает упираться в сеть, то обьем забираемого файла практически невлияет на результат, но я на обоих машинах сделал одинаковый. Вот новые тесты, уменьшил кол-во запросов, что практически избавило от ошибок [..] Ошибок по прежнему очень много. Их быть не должно вообще, а max latency по несколько секунд говорят о том, что у вас соединения подолгу висят не по'accept'ченые, по видимому исчерпав лимиты. Какие значения на linux у: net.core.somaxconn net.core.netdev_max_backlog net.ipv4.tcp_max_syn_backlog net.ipv4.ip_local_port_range net.ipv4.tcp_fin_timeout net.ipv4.tcp_tw_reuse ? -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru net.core.somaxconn = 128 net.core.netdev_max_backlog = 1000 net.ipv4.tcp_max_syn_backlog = 131072 net.ipv4.ip_local_port_range = 3276861000 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_tw_reuse = 0 Но к линуксу у меня претензий нет, я его почти не тюнил: все, что в sysctl net.ipv4.tcp_max_tw_buckets = 65536 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 0 net.ipv4.tcp_max_syn_backlog = 131072 net.ipv4.tcp_syn_retries = 3 net.ipv4.tcp_synack_retries = 3 net.ipv4.tcp_retries1 = 3 net.ipv4.tcp_retries2 = 8 net.ipv4.tcp_rmem = 16384 174760 349520 net.ipv4.tcp_wmem = 16384 131072 262144 net.ipv4.tcp_mem = 262144 524288 1048576 net.ipv4.tcp_max_orphans = 65536 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_low_latency = 1 net.ipv4.tcp_syncookies = 0 Вопрос про про фряху, что с ней может быть не так? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259544,259813#msg-259813 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: проблема с rewrite
как решить проблему добавления слеша в конец? Офтоп - никогда не понимал, зачем бороться со слешами в конце uri, их можно использовать на бекенде в алгоритмах роутинга. Например в наших роутингах слеш в конце означает что uri адресуется к множеству сущностней (аля папка), отсутствия слеша в конце означает что в uri должен быть id который адресуется только к одной сущности, это очень удобно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259754,259803#msg-259803 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопрос по производительности.
On Tuesday 23 June 2015 09:05:23 BieZax wrote: [..] После того, как кол-во ответов перестает упираться в сеть, то обьем забираемого файла практически невлияет на результат, но я на обоих машинах сделал одинаковый. Вот новые тесты, уменьшил кол-во запросов, что практически избавило от ошибок [..] Ошибок по прежнему очень много. Их быть не должно вообще, а max latency по несколько секунд говорят о том, что у вас соединения подолгу висят не по'accept'ченые, по видимому исчерпав лимиты. Какие значения на linux у: net.core.somaxconn net.core.netdev_max_backlog net.ipv4.tcp_max_syn_backlog net.ipv4.ip_local_port_range net.ipv4.tcp_fin_timeout net.ipv4.tcp_tw_reuse ? -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопрос по производительности.
Валентин Бартенев Wrote: --- On Monday 22 June 2015 08:25:33 BieZax wrote: Валентин Бартенев Wrote: --- On Thursday 18 June 2015 12:05:45 BieZax wrote: Валентин Бартенев Wrote: --- On Thursday 18 June 2015 05:35:25 BieZax wrote: Валентин Бартенев Wrote: --- On Wednesday 17 June 2015 10:59:59 BieZax wrote: Поэксперементировал еще немного, но пока не получается понять, где затык. Конфиг nginx: [..] Сократил размер файла до 1 Кб LA ~5 при 16 ядрах IO в порядке, загрузка сети около 130 мегабит/c А на клиенте? Упираться вполне может клиент, таким образом вы будете тестировать не производительность nginx, а производительность клиента. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru Без внутреннего перенаправления пролетает 3rps, с перенаправлением ~13 тыс. Логично предположить ,что клиент тут не при делах. Из интересного:кол-во подключений всегда около 30к, может во фряхе(9.3) какой-то лимит по соединениям, о котором я не знаю? На линуксе проблема не повторяется. Из этого нельзя такого предположить. Это может просто говорить отом, что клиент находится в зависимости от задержек при обработке ответов и не пытается нагружать сервер максимальным количеством запросов. Так, для сравнения, у меня только 4 ядра и далеко не серверных, на 1кб файле: Running 5m test @ http://127.0.0.1:/1k.html 4 threads and 1 connections Thread Stats Avg Stdev Max +/- Stdev Latency 782.79ms1.07s4.95s81.36% Req/Sec86.61k19.39k 223.51k80.68% 103239033 requests in 5.00m, 121.34GB read Requests/sec: 344017.77 Transfer/sec:414.02MB Как видите, с вашими 3rps на 16 ядрах едва ли вы можете упираться в nginx. Это либо сеть, либо клиент, либо что-то еще в системе. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru То, что нжинкс не причем, это понятно, т.к. на линуксе с тем же конфигом все замечательно работает. Потестил еще wrk, вот результат :( Без перенаправления Running 5m test @ http://192.168.1.1/index.html 16 threads and 3 connections Thread Stats Avg Stdev Max +/- Stdev Latency 739.14ms 334.20ms 2.00s81.32% Req/Sec 1.79k 365.0716.54k79.40% 8476672 requests in 5.00m, 16.70GB read Socket errors: connect 1771, read 2975, write 636, timeout 423212 Requests/sec: 28246.05 Transfer/sec: 56.98MB С перенаправлением: Running 5m test @ http://192.168.1.1/index.html 16 threads and 3 connections Thread Stats Avg Stdev Max +/- Stdev Latency 146.66ms 238.77ms 2.00s90.72% Req/Sec 598.93169.07 3.39k71.40% 2845012 requests in 5.00m, 3.39GB read Socket errors: connect 1197, read 1546, write 6297, timeout 1435215 Non-2xx or 3xx responses: 2845012 Requests/sec: 9480.29 Transfer/sec: 11.56MB Обратите внимание на количество ошибок, о которых сообщает wrk в ваших результатах. Явно что-то не так с настройками. А во втором случае еще и Non-2xx or 3xx responses. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru Потестировал с линукса на фрю и с фри на линукс (железо идентичное), с еренаправлением внутри: Фря-линукс : wrk -d 1m -t 16 -c 3 http://192.168.1.2/index.html Running 1m test @ http://192.168.1.2/index.html 16 threads and 3 connections Thread Stats Avg Stdev Max +/- Stdev Latency 310.94ms 416.12ms 2.00s84.95% Req/Sec 1.80k 1.12k 10.38k67.54% 1713774 requests in 1.00m, 2.07GB read Socket errors: connect 0, read 755, write 30669, timeout 191934 Non-2xx or 3xx responses: 37920 Requests/sec: 28519.58 Transfer/sec: 35.28MB При этом нагрузка на сервер весьма ощутимая по процу. с линукса на фрю: ./wrk -d 1m -t 16 -c 3 http://192.168.1.1/index.html Running 1m test @ http://192.168.1.1/index.html 16 threads and 3
Наследование fastcgi_param
Здравствуйте.
# uname -a
FreeBSD test 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13
06:54:13 UTC 2015
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
amd64
# nginx -v
nginx version: nginx/1.8.0
# php -v
5.6.10
Имеется такая тестовая конфигураци.
server {
root /www;
index index.html index.php;
includefastcgi_params;
fastcgi_index index.php;
location /info {
fastcgi_param SCRIPT_FILENAME /www/info.php;
fastcgi_pass 127.0.0.1:9000;
}
.
..
}
Проблема в том, что в локейшене /info не наследуются fastcgi_param (все),
указанный в контексте server, если происходит переопределение одного
fastcgi_param параметра внутри локейшена. PHP-FPM возвращает код статуса
200 и пустой ответ. Экспериментальным путём выяснил, что минимальные
необходимые параметры передаваемые PHP-FPM следующие:
location /info {
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param SCRIPT_FILENAME /www/info.php;
fastcgi_pass 127.0.0.1:9000;
}
В этом случае PHP-FPM обрабатывает скрипт /www/info.php, но nginx не
передал все остальные fastcgi_param из файла fastcgi_params, которые должны
были быть унаследованы.
В документации описан момент
Директивы наследуются с предыдущего уровня при условии, что на данном
уровне не описаны свои директивы fastcgi_param.
выходит если я переопределяю (устанавливаю) какой-либо fastcgi_param параметр,
то наследования fastcgi_params вовсе отменяется? Для чего тогда это
наследование? Почему нельзя наследовать с верхнего уровня и иметь
возможность переопределить какой-либо параметр?
Спасибо.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Возможность собрать современную версию nginx и openssl с поддержкой ssl renegotiation
Всем привет. Возникла необходимость взаимодействия с сервером, использующего ssl renegotiation. А в качестве промежуточного звена отлично подошел бы nginx с его proxy_pass и proxy_ssl_certificate* + proxy_ssl_trusted_certificate. Но соответствующий функционал убран еще в 0.8.23. Можно ли как-то достучаться до такого сервера из nginx? Правка event/ngx_event_openssl.c не помогает - nginx перестает ругаться на SSL renegotiation disabled, но все-равно запрос не проходит. Да, я понимаю, что не просто так это было убрано, но внешний сервер работает только так. Вопрос безопасности оставляю вне данного вопроса. Запросы (с той же машины, где собирается и работает nginx) к этому серверу такого вида проходят успешно: openssl s_client -connect foohost:443 -CAfile mcert.crt -servername foohost -key my.key -cert my.crt Заранее спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259815,259815#msg-259815 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: проблема с rewrite
Может это фича nginx ?
2015-06-19 13:17 GMT+03:00 Иван Мишин simplebo...@gmail.com:
ДОбрый день!
Есть вот такой локейшн
location @delete_handler {
internal;
open_file_cache off;
if (-d $webdav_root/$uri) { # Add trailing slash to dirs.
rewrite ^(.*[^/])$ $1/;
}
root$webdav_root;
dav_methods DELETE;
}
По смыслу if должен дописывать слеш в конец запроса.
Логи:
2015/07/20 13:14:52 [notice] 12620#0: *10967 ^(.*[^/])$ matches
/Family/test, client: 192.168.200.94, server: 192.168.200.92, request:
DELETE /Family/test HTTP/1.1, host: 192.168.200.92
2015/07/20 13:14:52 [notice] 12620#0: *10967 rewritten data:
/Family/test/, args: , client: 192.168.200.94, server: 192.168.200.92,
request: DELETE /Family/test HTTP/1.1, host: 192.168.200.92
== /var/log/nginx/webdav2_access.log ==
192.168.200.92 192.168.200.94 - [20/Jul/2015:13:14:52 +0300] DELETE
/Family/test HTTP/1.1 598 - 0 - curl/7.19.7 (x86_64-redhat-linux-gnu)
libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18
libssh2/1.4.2 - 0.000 - NGINX-CACHE-- -
== /var/log/nginx/error.log ==
2015/07/20 13:14:52 [info] 12620#0: *10967 client 192.168.200.94 closed
keepalive connection
Соответственно в еррор логе видно что произошло совпадение ^(.*[^/])$
matches /Family/test и поэтому имел место рерайт rewritten data:
/Family/test/, но почему в access логах DELETE /Family/test HTTP/1.1
слеш в конец не добавился?
как решить проблему добавления слеша в конец?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
