Most used front end: poll results
For severals month now I put a poll about which front end people use for their website. Even if it s not a reference with only 85 votes I would like to publsih some result. Of course as the content of this website is ruby oriented, then the results will be also.
First it started with most of votes for apache. At the end Apache it’s still the first:
- 47%: apache
- 40%: nginx
- 7% : lighttpd
- 5% : others
The result for nginx is over general real stats but for the trend is here and nginx is more and more the choice for a ruby stack as I did present in my last post
Scaling a Rails app (Part 3 of 3)
This the third and last part for a summary about solutions to help better computing of your rails app
Some home made benchmarks
NB: Following benchmarks have been made to a quick look study and not for a proof of concept.
The test machine (dedibox, ubuntu 6.10) is 1 core cpu @2Ghz – 1024 Mo memory. In each case the http server uses 10 processes on a real world application (not just ‘hello world!’). Sending 500 rq with 1 or 10 concurrency req:
| conc. req. | 1 | 10 |
|---|---|---|
| apache | ||
| mongrel | 39.4s – 12.7 r/s | 21.9s – 22.8 r/s |
| thin | 37.6s – 13.3 r/s | 17.7s – 28,15 r/s |
| nginx | ||
| mongrel | 39.2s – 12.8 r/s | 22.2s – 22.5 r/s |
| thin 0.5.4 | 39.8s – 12.6 r/s | 17.7s – 28.15 r/s |
| thin 0.6.1 socket x2 | 37.6s – 13.3 r/s | 17.8s – 28.1 r/s |
Since last time, Rails world has a new nice app server: thin. Replacement of mongrel, based on rack interface, it’s also recently added a unix socket connector where usually we use IP connector. For better performance, avoid longest stuff as scripts (google analytics). Other scripts/images/css are keys in http performances also, usage of assets in recommended.
As we can see in equivalent configuration there is no major difference for http server. Thin seems to be definitly faster than mongrel when you need to server more than 1 request at a time. And of course on a 1 core cpu, having more than one app server doesnt make the content served really faster.
Memory usage
Mongrel (48 Mo) → Thin (40 Mo) less 15%
Apache (10 Mo) → Nginx (1.4 Mo) less 85%
Finally I decided to move to a nginx / thin on socket configuration because of the memory usage and the fair performances. I even moved my PHP stuff with an fcgi connector.
Other ideas of tests: Varnish, Nginx and memcached. Maybe next time :)
[update]
Please find a good benchmark about nginx vs apache on Joe’s blog
Overall conclusion
I think when we need to compare two framework, about which one is faster, we should keep in mind all these levels of optimisation to scale an application, and then the raw performance is a secondary issue.
Scaling a Rails app (Part 2 of 3)
This the second part for a summary about solutions to help better computing of your rails app (1st part).
Application
To help your application to focus on replying fast to user, you can use a distributed queueing to give the job to other processes:
And second thing, you can cache things you don’t need to compute for each request, this can incredibly increase the response of your server, but need to modify your code and it s recommend for very big sites:
Back end
DB
For your database you can find some sql proxy, but I haven’t tried it yet. You have also the way to replicate your databse and serve data from several servers.
- sql relay
- use jruby with a jdbc pool connection and caching
Important things you have to check about your databse is if you have the right indexed fields. You should find some tools on mysql helping you to find where indexes missing. Check about cache too.
A last way is to serialize some of your data in a single object.
Mysql
Otherwise you can configure your mysql with some optimized configuration (mysql.ini):
- skip-name-resolve
- query_cache_size = 52428800;
- query_cache_type = 1
And in your ActiveRecord object you can use the :include parameter.
Filesystem
Optimizing the filesystem, in other sense than choose a good OS, can been done with not overloading the management of files by using some rules:
- max 10K files / subdir
- 16 top level / 256 sub / 10K per sub dir
- use a hasher to manage files
OS
As we have seen, file and memory management are keys of good performances. And these are managed by OS. The two best OSs mentionned are
- Sunsolaris
- FreeBSD (can be use for a all in one stack), avoid the version 5
And upcoming, last part of this article, some home made benchmarks for my own purpose.
Scaling a Rails app (Part 1 of 3)
One of the most interesting topic in the RailsConf was Scaling your Rails app. There are 2 ways of doing it:
- adapt your code
- adapt your servers
But the second one will not help to make your code faster. It will just help to give maximum resources to compute it right.
Summaries from the conference (sorry for the so few litterature it will be only a summarize):
Some theories
These theories are for big websites with millions of hits every month. This can involve thousand of servers, different location, … BTW some tips can be use to help smaller configurations.
The 7 layers to be considered, a la OSI.
- DNS
- frontend
- proxy
- application server
- application
- backend (Db , filesystem)
- OS
DNS
Nice website to check your DNS configuration: dnsstuff.com
Good tool to optimize your DNS: speed, dispatching, and so on…: powerdns
DNS can be quite fast to address the right server from a request, scripts allow to manage complex configurations. The tip is to use 1 DNS entry per 1 controller, then managing part of the routing.
Frontend and Proxy
Load balancing is about dispatching requests taking in account the charge of each cluster.
Load balancers:
Varnish
HAProxy
Both look promising and HAProxy seems to be more and more popular.
Front end with load balancer:
Nginx : fast, low memory usage, http server with load balancing, easy configuration, very good in front of mongrel cluster.
Apache 2.2 + mod_proxy_balancer, you can find how to setup it in previous post: apapche, mongrel cluster, rails on a load balancer
Application server
- mongrel server: enough for a personnal server
gem install mongrel
mongrel_rails start (more information) - mongrel_cluster: useful to scale up your configuration, need at least a multi-processor or multi server environnment.
gem install mongrel_cluster
mongrel_rails cluster::configure …
mongrel_rails cluster::start - Evented Mongrel (swiftiply): it’s a mongrel based an event triggering
- jruby / glassfish: the technology java comes with some good environment to speed up part of your application like connection to database (jdbc, pool connection)
to be continued (application, backend, OS, and some home benchmark)
Apache, Mongrel (cluster) and Rails are on a load balancer
Following the conference, and some information about scaling Rails application, I decided to investigate about it and write a post on it.
First, I tried to install FreeBSD as recommended for small configuration… Well, I still don’t get it, I’m not fan of this installation and stop trying to understand, instead I installed a Debian 4.0R1, not so bad and closer to what I know :)
Secondly, I want to try Nginx. First, need to find the good one to install on Debian, not last dev, maybe the one on the testing repository. Finally I found package with the 0.5.31, latest stable version. Easy to install with dpkg, I only wanted to simply configure static server and point on php application I have. Ouch, the php-cgi stuff is pretty much more complicated than expected, I had a look to a Rails configuration and gave up :p.(update: configuration of one server is not so complicated, at least for rails, not more than load_balancer in apache, but it is for php and if you want to dispatch URL on the same domain, it doenst seem trivial)
Then I went back to something I can handle: apache. I have read some article about 2.2 you can use with load_balancer and several mongrel instances. Let’s go for it. I found a very complete article: Time For A Grown-Up Server: Rails, Mongrel, Apache, Capistrano and You used also by mongrel website about Apache Best Practice Deployment.
As I faced some issues, please be careful about the following:
1/ Mods to activate:
a2enmod proxy a2enmod proxy_http a2enmod rewrite a2enmod deflate a2enmod headers a2enmod cache a2enmod mem_cache a2enmod file_cache
2/ Forbidden access ?
If you have some issue with forbidden access please check your proxy conf file and replace
Order deny,allow Deny from all
by
Order allow,deny Allow from all
Enjoy!
I’ll try again Nginx and maybe also pen / pound and litespeed. A buzzy load balancer: HAProxy. A lot of work is coming :p. If you have some feedback about these configuration don’t hesitate to share it :)