date:20160504

Re: Часть запросов с анамольно большим $request time

2016-05-04 Пенетрантность Maxim Dounin

Hello!

On Wed, May 04, 2016 at 11:58:17AM -0400, malaf wrote:

> Добрый день.
> 
> Есть такая конфигурация:
> - фронтенд c nginx
> - бэкенды с php
> - для динамических запросов настроено php fastcgi между nginx и php-fpm
> через tcp порт с кешированием ответов
> - log_format выглядит примерно так- '$remote_addr # $upstream_addr #
> $request # $status # $uri # $upstream_response_time # $upstream_cache_status
> # $request_time
> - проект высоконагруженный
> 
> Столкнулся с такой проблемой, судя по логам, то часть запросов имеет
> существенно большее значение  $request_time чем $upstream_response_time,
> может быть больше как на 1 секунду так и 2, 5 и даже более 30.  Особенно это
> заметно на страницах из кеша, у которых upstream_cache_status = HIT,
> upstream_response_time = 0 и c большим request_time, хотя для подавляющего
> большинства этот параметр имеет значение 0-0.01s 
> 
> Влияние "медленных клиентов" на значение $request_time вроде отсёк, проверив
> лог после обращения к странице в кеше с помощью curl --limit-rate 20K
> example.com > /dev/null, время ответа было 4 секунды, в лог request_time
> записался со значение 0.

Использование "curl --limit-rate" для эмуляции медленных клиентов - 
более или менее работает только в том случае, если размер ответа 
превышает суммарный размер всех буферов в цепочке.  Если в 
$request_time записалось значение 0 - это хороший признак, что 
ответ полностью влез в буфера, и с точки зрения nginx'а клиент - 
быстрее не бывает.

-- 
Maxim Dounin
http://nginx.org/

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Часть запросов с анамольно большим $request time

2016-05-04 Пенетрантность malaf

Добрый день.

Есть такая конфигурация:
- фронтенд c nginx
- бэкенды с php
- для динамических запросов настроено php fastcgi между nginx и php-fpm
через tcp порт с кешированием ответов
- log_format выглядит примерно так- '$remote_addr # $upstream_addr #
$request # $status # $uri # $upstream_response_time # $upstream_cache_status
# $request_time
- проект высоконагруженный

Столкнулся с такой проблемой, судя по логам, то часть запросов имеет
существенно большее значение  $request_time чем $upstream_response_time,
может быть больше как на 1 секунду так и 2, 5 и даже более 30.  Особенно это
заметно на страницах из кеша, у которых upstream_cache_status = HIT,
upstream_response_time = 0 и c большим request_time, хотя для подавляющего
большинства этот параметр имеет значение 0-0.01s 

Влияние "медленных клиентов" на значение $request_time вроде отсёк, проверив
лог после обращения к странице в кеше с помощью curl --limit-rate 20K
example.com > /dev/null, время ответа было 4 секунды, в лог request_time
записался со значение 0.

Проблема тоже не fastcgi или кеш-менеджере, так как такое же наблюдается и
для запросов, которые обрабатываются с помощью  nginx+redis через
redis_pass.
 
Подскажите, в чём может быть проблема, на что ещё обратить внимание, что
проверить?

nginx -V

nginx version: nginx/1.8.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) 
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
--lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --with-http_ssl_module
--with-http_realip_module --with-http_addition_module --with-http_sub_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_random_index_module --with-http_secure_link_module
--without-http_memcached_module --without-http_uwsgi_module
--without-http_scgi_module --with-http_stub_status_module
--add-module=/root/rpmbuild/SOURCES/nginx_modules/ngx_cache_purge
--add-module=/root/rpmbuild/SOURCES/nginx_modules/ngx_http_redis
--add-module=/root/rpmbuild/SOURCES/nginx_modules/redis2-nginx-module
--add-module=/root/rpmbuild/SOURCES/nginx_modules/lua-nginx-module
--add-module=/root/rpmbuild/SOURCES/nginx_modules/ngx_devel_kit
--add-module=/root/rpmbuild/SOURCES/nginx_modules/set-misc-nginx-module
--with-file-aio --with-http_spdy_module --with-cc-opt='-O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic'

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266619,266619#msg-266619

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ревалидация кеша fastcgi

2016-05-04 Пенетрантность VovansystemS

> Вы изначально в ответе отдавали заголовки валидаторы (ETag и/ил
> Last-Modified)?
> Посмотрите на содержимое в папке кеша Nginx, есть ли там заголовки ETag и/ил
> Last-Modified, без них ревалидация кеша невозможно.
да, спасибо огромное дело оказалось именно в этом! заголовки-то мы
отдавали, и у разработчика на машине nginx 1.8.0 и php 5.6 они
ставятся нормально, а вот на конфигурации, которая дублирует продакшн
nginx 1.9.15 и php 5.4 (fpm, chroot) что-то в приложении эти заголовки
упорно снимало. приложение на основе wordpress и там какой-то ад и
израиль. пока нашли воркэраунд - заголовки начали ставится и
ревалидация заработала.

Максим, S.A.N спасибо большое за помощь
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ревалидация кеша fastcgi

2016-05-04 Пенетрантность S.A.N

VovansystemS Wrote:
---
> >> fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match
> if_not_empty;
> >> fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since
> if_not_empty;
> >
> > У вас в конфиге написано: установить заголовки If-None-Match и
> > If-Modified-Since в запросах к бекенду в полученные от клиента
> > значения.  Ревалидация кеша в таких условиях работать не может по
> > очевидным причинам.
> 
> убрал эти строки. удалил кеш. ристартанул nginx
> первая загрузка X-My-Cache: MISS (страницы нет в кеше)
> вторая загрузка X-My-Cache: HIT (есть в кеше, получаю закешированную
> версию)
> жду 10 секунд
> третья загрузка X-My-Cache: EXPIRED
> 
> (а я ожидаю X-My-Cache: REVALIDATED )
> 

Вы изначально в ответе отдавали заголовки валидаторы (ETag и/ил
Last-Modified)?
Посмотрите на содержимое в папке кеша Nginx, есть ли там заголовки ETag и/ил
Last-Modified, без них ревалидация кеша невозможно.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266607,266612#msg-266612

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ревалидация кеша fastcgi

2016-05-04 Пенетрантность VovansystemS

>> fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
>> fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since 
>> if_not_empty;
>
> У вас в конфиге написано: установить заголовки If-None-Match и
> If-Modified-Since в запросах к бекенду в полученные от клиента
> значения.  Ревалидация кеша в таких условиях работать не может по
> очевидным причинам.

убрал эти строки. удалил кеш. ристартанул nginx
первая загрузка X-My-Cache: MISS (страницы нет в кеше)
вторая загрузка X-My-Cache: HIT (есть в кеше, получаю закешированную версию)
жду 10 секунд
третья загрузка X-My-Cache: EXPIRED

(а я ожидаю X-My-Cache: REVALIDATED )

заголовки запроса браузера:
GET /product/name HTTP/1.1
Host: site.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112
Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4

на всякий случай сделал то же самое через curl:
curl -i "https://site.com/product/name;
и получил точно такой же результат:
первая загрузка X-My-Cache: MISS (страницы нет в кеше)
вторая загрузка X-My-Cache: HIT (есть в кеше, получаю закешированную версию)
жду 10 секунд
третья загрузка X-My-Cache: EXPIRED

> На бекенде в РНР, отвечайте http_response_code(304); вместо header('HTTP/1.0
304 Not Modified'); так быстрей и правильней.
поправил

> Судя по конфигу, у вас проблема с куками, если браузер присылает куки
сессии, кеш не работает, curl куки не присылает, ответ отдается из кеша.
вроде нет, см выше описание поведения curl при стандартном GET

бэкэнд сейчас, к слову, выглядит примерно так:

http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ревалидация кеша fastcgi

2016-05-04 Пенетрантность Maxim Dounin

Hello!

On Wed, May 04, 2016 at 02:58:19PM +0300, VovansystemS wrote:

> Добрый день,
> 
> пытаюсь настроить ревалидацию страниц сайта в кеше директивой
> fastcgi_cache_revalidate on;
> ожидаю, что если элемент кеша устарел, то nginx сам сделает запрос к
> бекэнду с заголовком If-Modified-Since (как это описано тут
> http://whitequark.org/blog/2014/04/05/page-caching-with-nginx/ ), но
> этого не происходит.
> 
> при устаревании элемента кеша $upstream_cache_status == EXPIRED и на
> бэкэнд уходит стандартный GET без заголовков на ревалидацию при
> включённом fastcgi_cache_revalidate on.
> 
> я попробовал задавать fastcgi_cache_revalidate на разных уровнях, на
> случай если есть особенности наследования, но всё равно безуспешно.
> 
> если же я делаю
> curl -i --header 'If-Modified-Since: Tue, 11 Dec 2015 10:10:24 GMT'
> https://site.com
> 
> то получаю X-My-Cache: REVALIDATED - потому что клиентский заголовок
> был корректно передан на бэкэнд, который ответил header('HTTP/1.0 304
> Not Modified');
> 
> вопрос: я не понимаю как должна работать директива и хочу странного
> или всё же задачу можно как-то решить? подскажите, пожалуйста.

[...]

> fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
> fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty;

У вас в конфиге написано: установить заголовки If-None-Match и 
If-Modified-Since в запросах к бекенду в полученные от клиента 
значения.  Ревалидация кеша в таких условиях работать не может по 
очевидным причинам.

-- 
Maxim Dounin
http://nginx.org/

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ревалидация кеша fastcgi

2016-05-04 Пенетрантность S.A.N

Судя по конфигу, у вас проблема с куками, если браузер присылает куки
сессии, кеш не работает, curl куки не присылает, ответ отдается из кеша.

Убери из конфига
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; 
fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; 
Они не нужны

На бекенде в РНР, отвечайте http_response_code(304); вместо header('HTTP/1.0
304 
Not Modified'); так быстрей и правильней.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266607,266608#msg-266608

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

ревалидация кеша fastcgi

2016-05-04 Пенетрантность VovansystemS

Добрый день,

пытаюсь настроить ревалидацию страниц сайта в кеше директивой
fastcgi_cache_revalidate on;
ожидаю, что если элемент кеша устарел, то nginx сам сделает запрос к
бекэнду с заголовком If-Modified-Since (как это описано тут
http://whitequark.org/blog/2014/04/05/page-caching-with-nginx/ ), но
этого не происходит.

при устаревании элемента кеша $upstream_cache_status == EXPIRED и на
бэкэнд уходит стандартный GET без заголовков на ревалидацию при
включённом fastcgi_cache_revalidate on.

я попробовал задавать fastcgi_cache_revalidate на разных уровнях, на
случай если есть особенности наследования, но всё равно безуспешно.

если же я делаю
curl -i --header 'If-Modified-Since: Tue, 11 Dec 2015 10:10:24 GMT'
https://site.com

то получаю X-My-Cache: REVALIDATED - потому что клиентский заголовок
был корректно передан на бэкэнд, который ответил header('HTTP/1.0 304
Not Modified');

вопрос: я не понимаю как должна работать директива и хочу странного
или всё же задачу можно как-то решить? подскажите, пожалуйста.

конфиг:

fastcgi_cache_path /tmp/MAIN levels=1:2 keys_zone=MAIN:64m
max_size=768m inactive=24h;

server {

listen  ***:443 ssl;
server_name site.com;

ssl on;

ssl_certificate  /etc/nginx/ssl/certs-mcg/site_co_uk.pem;
ssl_certificate_key  /etc/nginx/ssl/certs-mcg/site_co_uk.key;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

error_log /home/site/logs/site-ssl.error.log error;
access_log /home/site/logs/site-ssl.access.log wtimes;

root /www/site/domains/site.com/public_html/;
set $sock 127.0.0.1:9001;

include fastcgi_params;
fastcgi_index index.php;
fastcgi_intercept_errors on;
fastcgi_param DOCUMENT_ROOT /public_html;
fastcgi_param SCRIPT_FILENAME /public_html$fastcgi_script_name;

fastcgi_no_cache $cookie_login $cookie_authautologin $cookie_PHPSESSID;
fastcgi_cache_bypass $cookie_login $cookie_authautologin $cookie_PHPSESSID;
fastcgi_cache_revalidate on;
fastcgi_temp_path /tmp/fcgi 1 2;
fastcgi_cache MAIN;
fastcgi_cache_key "$scheme|$request_method|$host|$request_uri";
fastcgi_cache_lock on;
fastcgi_cache_methods GET HEAD;
fastcgi_ignore_headers  "Cache-Control" "Expires";
fastcgi_cache_valid 10s;
add_header X-My-Cache $upstream_cache_status;
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty;

index index.html index.php;

location / {
fastcgi_cache_revalidate on;
try_files $uri $uri/ /index.php$is_args$args;
}

location ~* "^/wp-admin(/.*$|/$|$)" {
  fastcgi_cache off;
  try_files $fastcgi_script_name =404;
  fastcgi_pass $sock;
  add_header X-My-Cache-admin $upstream_cache_status;
}

location ~* "^/cart(/.*$|/$|$)" {
  fastcgi_cache off;
  try_files $fastcgi_script_name =404;
  fastcgi_pass $sock;
  add_header X-My-Cache-cart $upstream_cache_status;
}


location ~* \.php$ {
fastcgi_cache_revalidate on;
try_files $fastcgi_script_name =404;
fastcgi_pass $sock;
}

# Static files location
location ~*
^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|docx)$
{
expires 60d;
access_log off;
}
}


версии софта:

nginx version: nginx/1.9.15 (из официального репозитория)
PHP 5.4.45-1~dotdeb+7.1
Debian GNU/Linux 7
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Часть запросов с анамольно большим $request time

Часть запросов с анамольно большим $request time

Re: ревалидация кеша fastcgi

Re: ревалидация кеша fastcgi

Re: ревалидация кеша fastcgi

Re: ревалидация кеша fastcgi

Re: ревалидация кеша fastcgi

ревалидация кеша fastcgi

8 matches

Site Navigation

Mail list logo

Footer information