The response I am testing using Gatling has the following headers, which includes a Cache-Control header of 2 minutes.
Accept-Ranges: bytes
Cache-Control: max-age=120, public
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 17975
Content-Type: application/json;charset=UTF-8
Date: Tue, 06 Oct 2015 00:21:43 GMT
ETag: "0be271f09dc4c9a0ddea9e4b5899b59b4"
Expires: Tue, 06 Oct 2015 00:23:42 GMT
P3P: CP="CAO DSP COR CURa ADMa DEVa TAIa PSAa PSDa IVAi IVDi CONi OUR SAMo OTRo BUS PHY ONL UNI PUR COM NAV INT DEM CNT STA PRE"
Vary: Accept-Encoding
X-Application-Context: application:prod
When using a basic simulation like so, I can easily overwhelm the servers despite being behind a Varnish server. Is Gatling by default including a cache buster?
constantUsersPerSec(500) during(1 minute)
Each virtual users has its own caches, there's no global shared one (it wouldn't make sense). Here, you're creating 500 new virtual users by second. Assuming your scenario only sends one request, you'll be hitting your server 500 times/s. Isn't it what you observe?
Related
I am test running Drupal 7 on a local Centos/LAMP VM, not connected to the Internet, with Varnish and the Varnish Module installed.
I can't tell if Varnish is working or not. As I cannot put my instance on the Internet, I cannot use http://www.isvarnishworking.com/ to test.
Chrome returns the following at http://localhost/data:
1st run:
HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 17:22:12 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=60
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
X-Generator: Drupal 7 (http://drupal.org)
Etag: "1473268932-1"
Last-Modified: Wed, 07 Sep 2016 17:22:12 GMT
Vary: Cookie,Accept-Encoding
Content-Encoding: gzip
Content-Length: 7579
Content-Type: text/html; charset=utf-8
X-Varnish: 162
Age: 0
Via: 1.1 varnish-v4
Connection: keep-alive
Accept-Ranges: bytes
2nd run:
HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 17:23:01 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=60
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
X-Generator: Drupal 7 (http://drupal.org)
Etag: "1473268981-1"
Last-Modified: Wed, 07 Sep 2016 17:23:01 GMT
Vary: Cookie,Accept-Encoding
Content-Encoding: gzip
Content-Length: 7583
Content-Type: text/html; charset=utf-8
X-Varnish: 917543
Age: 0
Via: 1.1 varnish-v4
Connection: keep-alive
Accept-Ranges: bytes
curl -Ij http://localhost/data returns the following:
1st run:
HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 17:25:27 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=60
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
X-Generator: Drupal 7 (http://drupal.org)
Last-Modified: Wed, 07 Sep 2016 17:25:27 GMT
Vary: Cookie,Accept-Encoding
Content-Type: text/html; charset=utf-8
X-Varnish: 786539
Age: 0
Via: 1.1 varnish-v4
ETag: W/"1473269127-1"
Connection: keep-alive
2nd run:
HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 17:25:27 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=60
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
X-Generator: Drupal 7 (http://drupal.org)
Last-Modified: Wed, 07 Sep 2016 17:25:27 GMT
Vary: Cookie,Accept-Encoding
Content-Type: text/html; charset=utf-8
X-Varnish: 917560 786540
Age: 26
Via: 1.1 varnish-v4
ETag: W/"1473269127-1"
Connection: keep-alive
Here is part of my /etc/varnish/default.vcl:
# Default backend definition. Set this to point to your content server.
backend default {
.host = "127.0.0.1";
.port = "8080";
}
Here is part of my /etc/httpd/httpd.conf:
Listen 8080
NameVirtualHost *:8080
Finally, here are my admin/config/development/performance settings:
CACHING
Cache pages for anonymous users (checked)
Cache blocks (checked)
Minimum cache lifetime: none
Expiration of cached pages: 1 min
It seems like Varnish is working for curl but not for Chrome. From what I have read about Varnish under Drupal, I should be seeing a two values for X-Varnish, which I see on my second curl run but do not see in Chrome. I don't know if I should see Drupal cache as a HIT because doesn't Varnish provide the cache? Not seeing anything that says HIT for Varnish, however.
Any help would be great.
Thanks
In response to Ronald's question, here are the Chrome Request Headers:
GET /data HTTP/1.1
Host: localhost
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: has_js=1
If-None-Match: "1473274273-1"
Although this question should be trivial, I didn't success to enable browser caching on web google app engine java server.
I've try to put this kind of thing in my appengine-web.xml:
<static-files>
<include path="/**.cache.**" expiration="365d" />
...
but when I'm looking the response header I find this in local:
Content-Length: 196084
Cache-Control: public, max-age=31536000
Expires: Fri, 10 Jan 2014 19:40:45 GMT
Content-Type: image/png
Last-Modified: Tue, 18 Dec 2012 21:41:22 GMT
Server: Jetty(6.1.x)
Which is fine... but this in production environment:
HTTP/1.1 304 Not Modified
ETag: "RV4Bpg"
X-AppEngine-Estimated-CPM-US-Dollars: $0.000000
X-AppEngine-Resource-Usage: ms=109 cpu_ms=0
Date: Thu, 10 Jan 2013 19:41:20 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, must-revalidate
Server: Google Frontend
Which is definitively not what I want :(
Any idea ? something I've missed ?
[EDIT]
for not yet downloaded content, my browser receive the following header:
HTTP/1.1 200 OK
ETag: "RV4Bpg"
Date: Fri, 11 Jan 2013 12:50:50 GMT
Expires: Sat, 11 Jan 2014 12:50:50 GMT
Cache-Control: public, max-age=31536000
X-AppEngine-Estimated-CPM-US-Dollars: $0.000000
X-AppEngine-Resource-Usage: ms=3 cpu_ms=0
Date: Fri, 11 Jan 2013 12:50:50 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, must-revalidate
Content-Type: image/png
Server: Google Frontend
Content-Length: 196084
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
X-RBT-Optimized-By: eu-dcc-sh02 (RiOS 6.5.5b) SC
An ETag and several contradictory 'Expires' and 'Cache-Control' ...
Is there several way to configure caching policy ? Could it come from my ISP ? or a proxy ?
When you are logged in to a Google App Engine application as an administrator:
The X-AppEngine-* headers shown in your question are included.
The Cache-Control: no-cache, must-revalidate header is included, because the X-AppEngine-* headers are private and must not be cached.
This is hidden at the end of the Responses section at https://developers.google.com/appengine/docs/python/runtime#Responses, which says that:
Responses with resource usage statistics will be made uncacheable.
Yes, Cache-Control is off because reply is HTTP 304.
The problem is that your browser saved the ETag: http://en.wikipedia.org/wiki/HTTP_ETag
Now for every request for the same url/content, browser provides ETag and GAE replies with HTTP 304 Not Modified.
Try changing the resource (image) at this url, checking another url that you have not yet loaded in this browser or using another browser or computer altogether.
Also, this is relevant: What takes precedence: the ETag or Last-Modified HTTP header?
I have a django-nonrel app running in Google App Engine and am wanting all the content to be gzipped.
I keep reading that GAE automatically gzips the content but when I check the headers using Firefox's web developer toolbar I get the following result:
Via: 1.1 TL-ISA1
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
Transfer-Encoding: chunked
Expires: Thu, 09 Dec 2010 12:23:46 GMT
Date: Thu, 09 Dec 2010 12:23:46 GMT
Content-Type: text/html; charset=utf-8
Etag: "463ad22512f09050f76a291c11d9746d"
Server: Google Frontend
Last-Modified: Thu, 09 Dec 2010 12:23:46 GMT
Cache-Control: max-age=0
200 OK
I was expecting to see Content-Encoding: gzip, but since it is not there, my assumption is that the content is not being gzipped as it should.
Am I missing something? For example, do I need to do something extra if I am using django-nonrel?
Just to add, I am new to Web development - so don't be afraid to patronise. Thanks
Gzip should work out of the box, you are probably requesting the page through a proxy.
I'm having problems getting SharePoint 2010/IIS 7.5 to respect byte-range requests. I'm developing a SharePoint 2010 Web Part using Silverlight, and am trying to retrieve part of a document stored inside SharePoint.
When I request a byte range of a file in SharePoint, the server responds with the entire file. However, if I request the same byte range from a file sitting on an Apache server, everything works as expected. Below are the http headers observed with Fiddler.
Any help would be really appreciated! Thanks.
Sent:
GET http://example.com/file.abc HTTP/1.1
Accept: */*
Accept-Language: en-US
Referer: http://example.com/index.html
Accept-Encoding: identity
Range: bytes=1061285-1064594
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4
Host: example.com
Connection: Keep-Alive
SharePoint also takes login credentials:
Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==
Received from Apache:
HTTP/1.1 206 Partial Content
Date: Wed, 25 Aug 2010 22:40:34 GMT
Server: Apache/2.0.54
Last-Modified: Fri, 20 Aug 2010 23:27:18 GMT
ETag: "b68e346-103ea9-a3c20180"
Accept-Ranges: bytes
Content-Length: 3310
Vary: User-Agent
Content-Range: bytes 1061285-1064594/1064617
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: application/x-zip
Received from SharePoint 2010 / IIS 7.5
HTTP/1.1 200 OK
Cache-Control: private,max-age=0
Content-Length: 1064617
Content-Type: application/octet-stream
Expires: Tue, 10 Aug 2010 22:40:56 GMT
Last-Modified: Wed, 25 Aug 2010 19:28:39 GMT
ETag: "{5A1DF927-D8CD-4BC0-9590-8188CF777A3D},1"
Server: Microsoft-IIS/7.5
SPRequestGuid: 99799011-5bdc-489f-99fd-d060a56d3ae4
Set-Cookie: WSS_KeepSessionAuthenticated={7703be10-bb56-4fa1-ba8b-cd05f482859f}; path=/
X-SharePointHealthScore: 5
ResourceTag: rt:5A1DF927-D8CD-4BC0-9590-8188CF777A3D#00000000001
X-Content-Type-Options: nosniff
Content-Disposition: attachment; filename=file.abc
X-Download-Options: noopen
Public-Extension: http://schemas.microsoft.com/repl-2
Set-Cookie: WSS_KeepSessionAuthenticated={7703be10-bb56-4fa1-ba8b-cd05f482859f}; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 14.0.0.4762
Date: Wed, 25 Aug 2010 22:40:56 GMT
The problem is that SharePoint caching is off be default, and needs to be turned on to enable byte-range requests. See Disk-Based Caching for Binary Large Objects.
Note http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2:
"A server MAY ignore the Range header."
Thus whenever you are using a Range header you must be able to handle a 200 response. The fact that your server doesn't appear to support range serving is unfortunate, but conformant.
I am trying to set a cookie in my Google App Engine page:
self.response.headers.add_header('Set-Cookie','CookieName=1234; expires:Sun, 31-May-2009 23:59:59 GMT; path=/;')
The expiration date is not showing up in the browser. So it deletes itself at the end of the session.
Here is the output from curl -D:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Set-Cookie: CookieName=1234; expires:Fri, 01 Jan 2010 11:48:41 GMT
Date: Fri, 08 May 2009 11:57:25 GMT
Server: Google Frontend
Expires: Fri, 08 May 2009 11:57:25 GMT
Transfer-Encoding: chunked
What am I missing?
The problem is you're using "expires:" with a colon. Needs to be "expires=" with an equals.
With a "curl -D somefile" I can check that your cookie comes to the client exactly as specified. Can you check that, and confirm that the issue is with your browser and its settings rather than with the server side?