Cannot totally switch off caching

Greeting!

For some testing I need to switch off a nginx caching (nginx + php-fpm).
Now
I have a trouble - when I request a server (PHP app) first time,
response
generated about 10 sec (its ok), but when a request a server another
time
(during approx 1-2 mins from first request) response is returned within
50-100 msec, as I understand from some cache.

I trying to get pages via wget and httperf.

My configurations:

I create a 2 config templates named default and php:

default:
index index.html index.php;

location /status {
stub_status on;
}

location / {
try_files $uri $uri/ /index.php?q=$uri&$args;
}

Закрываем доступ к файлами .htaccess и .htpassword

location ~ /.ht {
deny all;
}

location = /favicon.ico {
log_not_found off;
access_log off;
}

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

php (initial variant):

location ~ .php$ {
try_files $uri =404;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

host settings in sites-enabled:

server{
listen 80;
access_log /var/log/nginx/site.access_log;
error_log /var/log/nginx/site.error_log;

root /var/www/site;

include /etc/nginx/templates/default;
include /etc/nginx/templates/php;
}

Tests running:
httperf --server site.local --num-conns 1 --verbose >perf.log

First request - approx 10 sec
Second request approx 100 msec.

I trying to disable caching with:

location ~ .php$ {
try_files $uri =404;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

fastcgi_cache off;
fastcgi_no_cache 1;
fastcgi_cache_bypass 1;
expires off;
}

+restarting nginx и php-fpm, but this has no effect.

Please help.

Best regards,
Ilya

Posted at Nginx Forum:

Hello!

On Mon, Jul 01, 2013 at 04:33:55AM -0400, imanenkov wrote:

Greeting!

For some testing I need to switch off a nginx caching (nginx + php-fpm). Now
I have a trouble - when I request a server (PHP app) first time, response
generated about 10 sec (its ok), but when a request a server another time
(during approx 1-2 mins from first request) response is returned within
50-100 msec, as I understand from some cache.

By default nginx doesn’t cache anything. You may want to look
into your php code to find out what is cached / causes reduced
response time in subsequent requests.


Maxim D.
http://nginx.org/en/donation.html

Hi,

and don’t forget system’s page cache. From my experience:

The files needed to process the first request aren’t yet read, so
Linux has to read them from disk (slow).

Then, for the second and further requests, the files are in the page
cache (aka system buffer), so that Linux don’t have to read them again
from disk. Access is now super fast.


Regards,
Igor

Maxim D. Wrote:

By default nginx doesn’t cache anything. You may want to look
into your php code to find out what is cached / causes reduced
response time in subsequent requests.

I think about it, but this is heavy app, and its cannot generate a page
with
100-200 msec (unfortunatelly:) ).

Posted at Nginx Forum:

On 7/1/2013 4:33 AM, imanenkov wrote:

For some testing I need to switch off a nginx caching (nginx + php-fpm). Now
I have a trouble - when I request a server (PHP app) first time, response
generated about 10 sec (its ok), but when a request a server another time
(during approx 1-2 mins from first request) response is returned within
50-100 msec, as I understand from some cache.

Are you using some type of opcode-caching software, e.g. APC, memcached,
etc.? If you’re convinced that PHP is doing the caching, I would disable
any opcode-caching software first.

-Ben

Hi,

and don’t forget database’s cache. You write about PHP, often there is
mysql also involved, which have the ability to cache.

Regards
Alexander

Am 01.07.2013 10:33, schrieb imanenkov:

Hello!

On Mon, Jul 01, 2013 at 08:32:32AM -0400, imanenkov wrote:

Maxim D. Wrote:

By default nginx doesn’t cache anything. You may want to look
into your php code to find out what is cached / causes reduced
response time in subsequent requests.

I think about it, but this is heavy app, and its cannot generate a page with
100-200 msec (unfortunatelly:) ).

On the other hand, 100-200 msec is way too long for nginx to
return a cached response.

If you assume the response is cached by nginx somehow, simpliest
test is to switch off php-fpm and check if you are still able to
request a resource.


Maxim D.
http://nginx.org/en/donation.html

Ben J. Wrote:

Are you using some type of opcode-caching software, e.g. APC,
memcached,
etc.? If you’re convinced that PHP is doing the caching, I would
disable
any opcode-caching software first.

-Ben
Yes, initially I use APC, but I switch it off, and problem still exist.

Posted at Nginx Forum:

Hello!

On Tue, Jul 02, 2013 at 02:08:52AM -0400, imanenkov wrote:

my index.php file. Then I revert location changes back to .php, restart
nginx, make request, and server return fast response of correct page again
(0.01 sec with wget, and 60 msec with httperf).

Unfortunately, all the tests you did actually prove nothing.
You’ve been told to switch off php-fpm, not to change nginx
configuration.

If you want to change nginx configuration - just add
$upstream_cache_status variable to a log, it will show if a
response was from nginx cache (HIT) or was requested from a
backend.

Other upstream-related variables may be interesting too, in
particular $upstream_response_time. See here for more:

http://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables


Maxim D.
http://nginx.org/en/donation.html

Maxim D. Wrote:

Unfortunately, all the tests you did actually prove nothing.
You’ve been told to switch off php-fpm, not to change nginx
configuration.
Do you mean stopping php-fpm with “/etc/init.d/php5-fpm stop” command?
In
this case I receive a “error 502 bad gateway” error.

Posted at Nginx Forum:

Maxim D. Wrote:

On the other hand, 100-200 msec is way too long for nginx to
return a cached response.

If you assume the response is cached by nginx somehow, simpliest
test is to switch off php-fpm and check if you are still able to
request a resource.
Thanks for idea! I change a location path in template named “php” from
“location ~ .php$” to “location ~ .pZp$” (just for excluding *.php
processing), restart nginx, and server returned a just content (source)
of
my index.php file. Then I revert location changes back to .php, restart
nginx, make request, and server return fast response of correct page
again
(0.01 sec with wget, and 60 msec with httperf).

Posted at Nginx Forum:

Hello!

On Tue, Jul 02, 2013 at 07:49:56AM -0400, imanenkov wrote:

Maxim D. Wrote:

Unfortunately, all the tests you did actually prove nothing.
You’ve been told to switch off php-fpm, not to change nginx
configuration.
Do you mean stopping php-fpm with “/etc/init.d/php5-fpm stop” command?

Yes.

In this case I receive a “error 502 bad gateway” error.

This proves that the response is not cached by nginx, but it’s
got from php-fpm instead. As already suggested early, you have to
look into your php code.


Maxim D.
http://nginx.org/en/donation.html

Hello!

On Tue, Jul 02, 2013 at 08:37:05AM -0400, imanenkov wrote:

log_format main '$remote_addr - $remore_user, $upstream_cache_status :
192.168.111.254 - -, - : 0.049
192.168.111.254 - -, - : 0.053

wait some time (~2 mins), run again, and another string:
192.168.111.254 - -, - : 23.998

And this again proves that nginx doesn’t cache anything but passes
requests to php-fpm. As previously suggested, you have to look
into your php code.


Maxim D.
http://nginx.org/en/donation.html

Maxim D. Wrote:

If you want to change nginx configuration - just add
$upstream_cache_status variable to a log, it will show if a
response was from nginx cache (HIT) or was requested from a
backend.

Other upstream-related variables may be interesting too, in
particular $upstream_response_time. See here for more:

I add new log_format in /etc/nginx/nginx.conf:
log_format main ‘$remote_addr - $remore_user, $upstream_cache_status :
$upstream_response_time’

and assign this formatter to access.log.

On several times running on “caches/fast” site output is:
192.168.111.254 - -, - : 0.090
192.168.111.254 - -, - : 0.044
192.168.111.254 - -, - : 0.054
192.168.111.254 - -, - : 0.057
192.168.111.254 - -, - : 0.047
192.168.111.254 - -, - : 0.049
192.168.111.254 - -, - : 0.053

wait some time (~2 mins), run again, and another string:
192.168.111.254 - -, - : 23.998

Posted at Nginx Forum:

Hello,

Am 02.07.2013 14:37, schrieb imanenkov:

log_format main '$remote_addr - $remore_user, $upstream_cache_status :
192.168.111.254 - -, - : 0.049
192.168.111.254 - -, - : 0.053

wait some time (~2 mins), run again, and another string:
192.168.111.254 - -, - : 23.998

do you use a PHP framework? Most frameworks can cache also. What happens
if you request the page with a unique parameter which is not used by
PHP? Somethink like a random value at the end of your url
test.php?random=xxxxx

What happens on your page/script generally? 24 seconds is a long time.
Are you querying a database? Or filesystem operations? Perhaps it can
help you commenting out step by step in your PHP page/script.

What kind of sotware do you use for this load test? Is this
“192.168.111.254” your localhost? Or is it possible that there is a
proxy between your test server and load generator which is not bypassed?

It’s not a nginx caching result.

Kind regrads

Alexander

Alexander K. Wrote:

do you use a PHP framework? Most frameworks can cache also.
Yes, site based on Drupal 7. I trying to switch off drupal cache, all
the
same.

What
happens
if you request the page with a unique parameter which is not used by
PHP? Somethink like a random value at the end of your url
test.php?random=xxxxx
When I add a new parameter (http://site/?qqq), page generate long time.
When
a request a page with the same parameter again, page return fast. When I
change parameter again, page generate long time again.

What happens on your page/script generally? 24 seconds is a long time.
This is some sort of information portal, during page render scripts make
about 50-75 requests to db.

Are you querying a database?
Yes, mysql 5 on anotner VM (in the proxmox virtual local network).

Or filesystem operations?
No, filesystem is not using (during start page generation, which I use
for
this tests).

Perhaps it can
help you commenting out step by step in your PHP page/script.

What kind of sotware do you use for this load test?
I run tests via httperf (and now for single requests trying simple
wget).
All machines is VM under proxmox with 512mb RAM and 1 virtual core,
except
nginx+php server - there is 1 Gb.
Dictinct VMs for nginx+php, db, and machine for test running. Also there
is
one proxy/load balancer machine, but now balancer have 1 node in config
and
redirect all requests to nginx (proxy using nginx too). I trying to
exclude
proxy totally (with direct access to nginx+php server - all the same).

Is this
“192.168.111.254” your localhost? Or is it possible that there is a
proxy between your test server and load generator which is not
bypassed?
This is VM - proxy, but I trying to exclude it and make direct requests
to
nginx+php machine, this has no effect.

Posted at Nginx Forum:

Alexander K. Wrote:

question in a drupal developer mailinglist?
Thanks a lot! I trying to disable all drupal caches and clear cache
tables,
and all for as needed (every request process “long” time. I could not
believe that drupal cache so fast (in testing environment), so initially
I
did not think about this case. My fault(

Thank to all for the right search direction!

Best regards.

Posted at Nginx Forum:

Hello,

Am 02.07.2013 15:46, schrieb imanenkov:

Alexander K. Wrote:

do you use a PHP framework? Most frameworks can cache also.
Yes, site based on Drupal 7. I trying to switch off drupal cache, all the
same.

i am no drupal user/developer but if i google about drupal cache it
sounds, there is not only one cache, and it sounds like its not only one
click to disable it complete. Perhaps you can find some informations
about the cache here:

https://drupal.org/node/797346

or it is a good point so start. If you exclude the frontend proxy, for
me it sounds like a cache “problem” in drupal. Perhaps you can post a
question in a drupal developer mailinglist?

good luck,

Alexander

Hello,

thanks for your feedback and nice to hear its solved.

have a nice day.

Alexander

Am 03.07.2013 08:50, schrieb imanenkov: