If you configure Apache to enable gzip compression for your static HTML/CSS/JS/etc. files, it automatically outputs a gzipped version to any client that sends an appropriate Accept-Encoding request header. (And for other clients, it just sends the raw uncompressed file.)
My question is: does Apache recompress the raw file every time it is requested by a gzip-accepting client? Or does it cache the gzipped copy, and only recompress it if it notices the last-modified time on the file has changed?
And if it does cache a gzipped copy of your files, where is this cache stored?
No it doesn't cache the gzipped file.
However the cost of compressing the file is less than the cost of squirting the extra packets across the network, hence even without caching you will see lower overall CPU usage (and lower memory usage, and fewer context switches) on your server - and a faster response at the client.
Note that the compressed file is NOT stored in the temp folder - mod_deflate reads input into a fixed size buffer in memory - and when the buffer is full (or the stream ends) the content is compressed and handed back to the webserver.
It will use even less CPU (although speed won't improve noticably) if the content is pre-compressed or cached serverside - there's multiple ways of doing this - mod_rewrite can test for the presence of filename.gz and serve it up in place of filename or you can use a reverse proxy (assuming the content is also served up with caching instructions).
No, it does not. This is described in the mod_deflate documentation now:
Since mod_deflate re-compresses content each time a request is made, some performance benefit can be derived by pre-compressing the content and telling mod_deflate to serve them without re-compressing them.
Apache does not keep any cached files. It only keeps the files you tell it to keep. Here is how compression works:
Browser requests page and states it accepts compression
Server finds page and reads the header of the request.
Server sends page to the browser (compresses if stated it accepts in header request - compressed file is stored in memory/temp folder)
Browser receives the information and displays (after decompression if compressed). The browser then caches the page and images.
Server removes any hint of the compressed file from memory/temp folder to free up space for the next request. It does log in the access_log the transaction.
The browser when it requests the same file or page again. It sends a request to the server stating that it accepts compression, and the current files and Modified Date. From here the server would respond that they are the same and send no additional information, or send only the changed files based on the Modified Date.
Related
I'm running WP website with cache plugin enabled.
The site is running slow so I decided to check which element is consuming more time to load.
Straight to F12 (chrome web tools) and from there the tab Network.
What I see and I don't understand is why some of the files are loading from disk cache and other no.
Please see the attached image (column "Size")
So, if you know the answer guys, please share it.
Thank you!
Memory Cache- stores and loads resources from Random Access Memory (RAM). It is fast because it is easy to load resources from RAM. These resources will persist until you close the Browser or you manually clear it.
Disk Cache- It stores and load the resources from disk and it is persistent. It will not contact webserver over network to get the data.Disk cache is usually included as part of the hard disk.
I guess browser will decide the type of cache storage based on the type of the resources or based on their frequency of usage.
Sometimes we use assets or resources from other sites(third party) these contents will be transferred over the network and size of those contents will be donated in Bytes(B).
It seems that all resources are loaded from cache. The difference is some resources are read from disk cache. Some resource are read from memory cache and the rest come from 304.
ETag and cache-control decide whether a resource should be read from local disk/memory cache or require to be refreshed(304). If the resource expired, then chrome will send request to server to check whether the file need to be updated. The size of 304 request is just the size of request entity not the size of your source file.
If the resource didn't expire, chrome will try to read from memory/disk cache and it won't send any request to server side.
It is unclear how web browser decide the cache type.
According to some document, we just notice that chrome are prefer to save css file into disk cache and save img/font/js file into memory cache.
I'm trying to increase performance of webpage. I'm using ReactJS + webpack, which compiles my jsx files into one file - search.bundle.js. And server is returning this file for 2-3 seconds. File size is ~200KB. Is file size the only reason?
On local server it works pretty well. But on remote webserver it is really slow..
There is Google Map and listing of items on page, which I get using ajax request. This is recursive request (while not get enough data, or timeout) which is called in componentDidMount, but as I understand it can't because it can start request items only after script is loaded on page.
So is there any way to achive more faster downloading this script? Or I should just try to reduce size of script?
And some data from headers tab:
on local:
on remote:
The answer to this question is that script has a source map available. With Chrome's Developer Tools panel open, it makes transparent requests to any available source map files (which it does not show you).
These files are often absolutely massive (mine are 3MB+) and take considerable time to pull on every refresh. Nginx specifically also handles them very poorly, at least in my setup. I think setting the max sendfile chunk size to be lower helps.
In an HTTP service implementation, I'm allowing multipart http file upload with the PUT method.
However, before writing everything into the hard drive, I'd like to check if the size of the file is OK. E.g. has to be under 50MB.
How to do this in go?
You might want to check out http.MaxBytesReader. It limitates the maximum amount of data which can be received from/sent by a single request.
MaxBytesReader prevents clients from accidentally or maliciously sending a large request and wasting server resources.
I am running a Rails 3.2.2 app on Ruby 1.9.3 and on my production server i run a Phusion Passenger/Apache Server.
I deliver a relatively huge amount of data objects in JSON format which contain redundant data from a related model and I want to know how many bytes the server has to deliver and how the redundant content can be gziped by the server and how the redundant data influences the size of the http response that has to be shipped.
Thanks for your help!
If you just want to know in general how much data is being sent, use curl or wget to make the request and save to a file -- the size of the file is (approximately) the size of the response, not including the headers, which are typically small. gzip the file to see how much is actually sent over the wire.
Even cooler, use the developer tools of your favorite browser (which is Chrome, right?). Select Network tab, then click the GET (or PUT or POST) request that is executed and check things out. One tab will contain the headers of the response, one of which will likely contain a Content-Length header, assuming your server is set up to gzip, you'll be able to see how much compression you're getting (compare uncompressed to the Content-Length). The timings are all there, so you can see how much time it takes to get a connection, for the server to do the work, for the server to send back the data, etc. Brilliantly cool tools for understanding what's really happening under the covers.
But echoing the comment of Alex (capital A) -- if you're sending a ton of data in an AJAX request, you should be thinking of architecture and design in most cases. Not all, but most.
We have a Rails app that instantiates a SWF object 16 times (it has to do this, it's just the nature of the application). Instead of being downloaded once, it is being downloaded 16 times.
How can we ensure this SWF is cached by the browser the first time it is downloaded? It's being served directly from Apache - can we modify the HTTP headers to accomplish this?
Some information:
Browser caching the resources with
code 304.
Domain points to cluster and traffic
is forwarded to two servers(.3 and
.4) in the cluster.
Each server has own copy of the code
with different timestamp of the
files.
If there are any subsequent requests to the SWF then chances are that .3 or .4 may
serve and browser treats image as modified on the server since image file timestamp is different.
Any help would be appreciated, as it would greatly improve the app's performance after the initial load.
Try to set the Expires header to a high enough value. also adding Cache-Control: max_age=<some high number> will help.
Apache's mod_expires will help with all of that.