I'm running some audits in my open-source project, BTC-Stores, and some times Chrome shows me that I need "Enable Gzip compression".
Sometime ago I read "High Performance Websites", from Steve Souders, and I already know the basic concepts about how make your page load faster. My project is using Ruby 2.0.0 and Rails 4.
I want know, Rails 4 already have a "gzip like compression" or I need to activate it by some gem or config? If you can, please link some good articles about Rails 4 performance and how to optimize it.
Here's some more about using gzip with Rails!
From http://guides.rubyonrails.org/asset_pipeline.html:
4.1.2 GZip Compression
When files are precompiled, Sprockets also creates a gzipped (.gz)
version of your assets. Web servers are typically configured to use a
moderate compression ratio as a compromise, but since precompilation
happens once, Sprockets uses the maximum compression ratio, thus
reducing the size of the data transfer to the minimum. On the other
hand, web servers can be configured to serve compressed content
directly from disk, rather than deflating non-compressed files
themselves.
Nginx is able to do this automatically enabling gzip_static:
location ~ ^/(assets)/ { root /path/to/public; gzip_static on; #
to serve pre-gzipped version expires max; add_header Cache-Control
public; } This directive is available if the core module that provides
this feature was compiled with the web server. Ubuntu packages, even
nginx-light have the module compiled. Otherwise, you may need to
perform a manual compilation:
./configure --with-http_gzip_static_module If you're compiling nginx
with Phusion Passenger you'll need to pass that option when prompted.
A robust configuration for Apache is possible but tricky; please
Google around. (Or help update this Guide if you have a good example
configuration for Apache.)
Also, the following may be of interest!
http://api.rubyonrails.org/classes/ActiveSupport/Gzip.html
Hope this helps!
Yes you need to use Gzip in a Rails 4 or any other project. You do that in the production server and not on your local.
Duplicated question: Compressing rails assets and nginx gzip (with nginx server)
Related
I am trying to configure Rails production server with Apache 2.2, Passenger 4.0.59 and XSendFile 0.12. Application is deployed via Capistrano.
Deployed application produces (maybe large) PDF to #{Rails.root}/tmp and serves this file using send_file.
The problem is that Capistrano uses symlinks to point to currently deployed version of application. XSendFile on the other hand dereferences symlinks and refuses to serve a file if its real location is outside document root even if it is allowed by XSendFilePath. Apache's error.log states:
(20023)The given path was above the root path: xsendfile: unable to find file: /resolved/path/to/file.pdf
Everything works well when I set PassengerAppRoot and XSendFilePath to the real location of current version of application, without symlinks on the path. But it's OK until next deploy, which requires apache reconfiguration. Not very useful.
How should I configure Capistrano deploy and XSendFile parameters to make it work together?
I tried solutions with ln -nFs described in Capistrano & X-Sendfile and in mod_xsendfile with symbolic links but none works.
I finally managed to make it work. A few tips for the ones who will have problems with XSendFile
I set XSendFilePath to user's $HOME, there are no symlinks on the path to $HOME, so it works. I can accept this from functional and security point of view, but it is obviously a workaround.
Be aware that XSendFilePath is sensitive to paths containing multiple slashes /like//this. I am using apache macros and while concatenatingXSendFilePath parameter from a few macro parameters I put some obsolete slashes. This caused XSendFile to refuse to send files.
Good luck!
I have a rails app where users can manage large files (currently up to 15 GB). They have also the possibility to download the stored files.
Everything works perfect for files < 510 MB. But for > 510 MB, the download stops after 522,256 KB (510 MB).
I think thin produces this issue. When I start my dev server using thin, I cannot download the complete file. When I start the dev server using webrick, everything works.
I used top to compare the RAM/CPU behavior, but both server, thin and webrick, behave the same way. In development, both server read the complete file into RAM and then send it to the user/client.
I tried to change some options of send_file like stream, or buffer_size. I also set length manually. But again, I was not able to download the complete file using thin.
I can reproduce this behavior using Firefox, Chrome, and curl.
The problem is that my productive rails app uses 4 thin servers behind an nginx proxy. Currently, I cannot use unicorn, or passenger.
In development, I use thin 1.6.3, rails 4.1.8, ruby 2.1.2.
def download
file_path = '/tmp/big_file.tar.gz' # 5 GB
send_file(file_path, buffer_size: 4096, stream: true)
end
If you are using send_file, it is ideal to use a front end proxy to pass off the responsibility of serving the file. You said you are using nginx in production, so:
In your production.rb file, uncomment config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect'.
You will also have to change your nginx configuration to accommodate Rack::Sendfile. Its documentation is located here. The changes amount to adding:
proxy_set_header X-Sendfile-Type X-Accel-Redirect;
proxy_set_header X-Accel-Mapping /=/files/; # or something similar that doesn't interfere with your routes
to your existing location block and adding an additional location block that handles the X-Accel-Mapping that you added. That new location block might look like:
location ~ /files(.*) {
internal;
alias $1;
}
You will know it is working correctly when you ssh to your production server and curl -I the thin server (not nginx) and see a X-Accel-Redirect header. curl (no -I) directly to the thin server should not send the file contents.
You can see my recent struggle with nginx and send_file here.
I am using Rails 3.1 w/asset pipeline, phusion 3.0.x and apache 2.2.17.
In the configuration documentation at http://guides.rubyonrails.org/asset_pipeline.html, in section 4.1.1 it states that I need to add a section to my apache config:
<LocationMatch "^/assets/.*$">
# Some browsers still send conditional-GET requests if there's a
# Last-Modified header or an ETag header even if they haven't
# reached the expiry date sent in the Expires header.
Header unset Last-Modified
Header unset ETag
FileETag None
# RFC says only cache for 1 year
ExpiresActive On
ExpiresDefault "access plus 1 year"
</LocationMatch>
I have been assuming that Phusion Passenger has just been "handling" this... or have I been negligent in not RTFM? If I want to take advantage of the fingerprinting, do I need to add this to the apache config?
If you want the full benefits of the asset pipeline, you do, indeed, need to add this to your Apache configs. Without that section, your Apache configuration is likely specifically telling browsers not to cache assets - resulting in an unnecessary number of round trips between the browser and your server.
In order to get this to work, you may need to enable a few more Apache modules. To do this:
sudo a2enmod
# Choose headers
sudo a2enmod
# Choose expires
sudo service apache2 restart
To debug your set-up, I recommend using the Live Headers Firefox plugin. Using that, specifically request an asset URL (e.g. http://mysite.com/assets/application-8a0ae0b2d708f797674b7123c37501ba.css)and look at the cache headers before and after you make this change. Find an example asset URL by doing a View Source on any page.
After the change, you should see that the cache expiration is set to one year in the future.
I'm struggling with send_file with rails 3.0.9 running ruby 1.9, passenger 3.0.8 on apache on ubuntu lucid
The xsendfile module is installed and loaded into apache
root~# a2enmod xsendfile
Module xsendfile already enabled
Its symlinked correctly in mods-enabled
lrwxrwxrwx 1 root root 32 Aug 8 11:20 xsendfile.load -> ../mods-available/xsendfile.load
config.action_dispatch.x_sendfile_header = "X-Sendfile" is set in my production.rb
using send_file results in zero byte files being sent to the browser
filepath = Rails.root.join('export',"#{filename}.csv")
if File.exists?(filepath)
send_file filepath, :type => 'text/csv'
end
I believe the previous answer isn't the right way to go because, as far as I can tell, Apache isn't handling the downloads at all when this solution is applied, instead the rails process is. That's why the nginx directive, which shouldn't work, appears to. You get the same result by commenting out the config directive.
Another drawback (aside from tying up a rails process for too long) is that when the data streaming is handled by the rails process the response doesn't seem to send the content length header. So a user doesn't know how large the file they're downloading is, nor how long it will take (a usability problem).
I was able to get it to work by ensuring that mod_sendfile was properly included and loaded in my apache config, like so (this will be dependent on your apache install, etc.):
LoadModule xsendfile_module /usr/lib64/httpd/modules/mod_xsendfile.so
...
# enable mod_x_sendfile for offloading zip file downloads from rails
XSendFile on
XSendFilePath /
We have an app that queries for locations for a customer. We're getting to the point where some customers could have upwards of 10,000 locations. The JSON response for this can get quite large, over 1mb sometimes.
I'm wondering first off the best way to compress this. We have apache in front of a Rails app running in trinidad with JRuby. Can I just set mod_deflate to always compress any responses that are application/json? How might I go about doing this?
Next, what is the browser support for gzip'd json? When I gzip a sample response of 200k it goes down to 30k. That's a significant savings. We're really like to be able to minimize the size of that response without having to minimize the number of locations returned.
In general, for newer versions of Rails, you can do it by adding
use Rack::Deflater
before the "run" line in the config.ru file. This will work perfectly with browsers/clients that support gzip. We use it in production on major websites.
Note for JRuby users: This assumes that your Rails app is launched through Rack, which it often isn't for JRuby. You need a recent version of JRuby-Rack and configure it in Warbler to run in 'rack' mode instead of 'rails' mode.
If the browser supports gzip'd/deflated data, then JSON will go through it just fine. AJAX data is just a regular HTTP request that was done on behalf of a script, rather than a human. At the HTTP level, there's absolutely zero difference between transferring some HTML or a JSON string - it's just data.
For Googlers... [I'm running Apache 2.2.16 and don't care about IE6]
JSON Responses with Content-Encoding = gzip didn't happen until I edit mod_deflate.conf to include this:
AddOutputFilterByType DEFLATE application/json
You can check server response headers with Firefox / Firebug / Net tab
First, make sure you have apache's mod_deflate installed by running this command.
a2enmod deflate
If this command installed it, restart apache. If not, you're good for now.
service apache2 restart
In apache2.conf usually located at /etc/apache2 append this line to the end of the file. This will include a file that we'll create in a little.
Include mod_deflate.conf
Next, we'll edit the mod_deflate.conf with our options:
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \
\.(?:exe|t?gz|zip|bz2|sit|rar)$ \
no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
#Skip browsers with known problems
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
The first block of code disables gzipping exes, gzs, pdfs.. etc
The second block of code skips deflation from browsers that don't support it.
Finally, restart apache again
service apache2 restart
The settings were copied from the link below:
http://www.howtoforge.com/apache2_mod_deflate