DISQUS

DISQUS Hello! Homo-Adminus Blog is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

Homo-Adminus Blog

Jump to original thread »
Author

High-Performance Ruby On Rails Setups Test: mongrel vs lighttpd vs nginx

Started by Scoundrel · 9 months ago

Because of not fully correct testing methodology, benchmark results are not fully correct. So, I decided to redo all tests. New benchmark results you can get in “Looking For Optimal Solution” series Summary post.
This week we have started one new project with Ruby on Ra ... Continue reading »

48 comments

  • kpumuk

    2 years ago

    Hello, Alex
    Thanks for useful article. But I have a question: where is the apache (2.0 and 2.2 with mod_balancer)? Why you haven't tested it?
    reply
  • Alexander Solovyov

    2 years ago

    Ошибка в статье. ;)

    > Как и ожидалось, результаты оказались лучше, чем с одним процессом mongrel:

    Это про pen. А насколько я вижу, результаты оказались хуже. ;)
    reply
  • Scoundrel

    2 years ago

    Исправил. Вот что значит - тестить днем, а писать и переводить ночью.
    reply
  • Alexander Solovyov

    2 years ago

    > Вот что значит - тестить днем, а писать и переводить ночью.

    Бывает. ;)

    А почему не было тестов через FastCGI? Так что, медленнее, чем через HTTP?
    reply
  • Alexander Solovyov

    2 years ago

    Сорри за такое количество комментов, еще хотелось узнать - а как это дело всё запускается? Писанный руками скрипт в init.d, или какой-то более удобный метод?

    А то руками скрипты ломает писать. ;)
    reply
  • Scoundrel

    2 years ago

    nginx - у меня где-то уже готовый срипт есть.
    mongrel - через скрипт + mongrel-cluster.
    reply
  • Roman Semenenko

    2 years ago

    > WEBrick (веб-сервер, написанный полностью на ruby и включенный в состав rails framework)

    WEBrick включен в дистрибутив ruby , в rails - только скрипт его запуска .

    Присоединяюсь к вопросу - а где же apache ?
    В общем и целом статья понравилась , спасибо.
    reply
  • Scoundrel

    2 years ago

    Насчет апача... Скажу честно - меня, как админа, видавшего апач много раз и в разных позах, сама мысль о том, что он как-то себя покажет в области проксирования сильно смущает... я попробовал поставить 2.2, но он тупо завалился при компиляции с синтакс еррором в области mod_load_balancer или как его там... дальше я не пробовал - НЕ ВЕРЮ! (с) и все тут...

    Если общественность настоит - могу попробовать еще раз - для большей полноты картины :-)
    reply
  • Alexander Solovyov

    2 years ago

    Насчёт апача - +1. Не верю, что он может достичь скоростей lighttpd/nginx.

    Но мой вопрос остался без ответа - почему не FastCGI, почему монгрел? ;)
    reply
  • insa

    2 years ago

    А не пробовал увеличивать количество mongrel listners? Думаю для 4x Xeon оптимально будет 8 процессов + nginx.
    reply
  • alrond

    2 years ago

    ошибка: "Вот и все, что необЗодимо."
    коммент потом можно удалить
    reply
  • Kpumuk

    2 years ago

    Кстати, померял скорость проксирования Apache 2.0/Mongrel и Apache 2.0/pen/Mongrel-cluster (5).

    Как и ожидалось, результат почти одинаковый (второй вариант дал 5% рост производительности).
    А вот на 2.2 посмотреть я не прочь :-) Ну же, Леха, когда будут результаты тестирования Apache 2.2 с load balancer'ом?
    reply
  • Kpumuk

    2 years ago

    Кстати, дебиановцы 2.2 уже включили в experimental, так что ждем его в скором времени в unstable :-)

    http://lists.debian.org/debian-apache/2006/08/m...
    reply
  • Kpumuk

    2 years ago

    2Alexander Solovyov:
    Я попробовал запустить бенчмарк для FastCGI. Машинка слабенькая - 500 селерон, 512 RAM, но mongrel 1000 запросов отрабатывает относительно шустро (104.550197 seconds).

    В общем эсперимент был сорван чрезвычайно низкой производительностью FastCGI. Я подождал полчаса, пока оно дошло до 300 реквестов, и на этом закончилось терпение :-)
    reply
  • Alexander Solovyov

    2 years ago

    > низкой производительностью FastCGI.

    Хмм... Надо бы с django поэкспериментировать, может у неё что-то подобное тоже есть? :\
    reply
  • Alexander Borovsky

    2 years ago

    > В общем эсперимент был сорван чрезвычайно низкой производительностью FastCGI. Я подождал полчаса, пока оно дошло до 300 реквестов, и на этом закончилось терпение :-)

    Вы его готовить не умеете: у меня на cel-400 c apache1+FastCGI было около 10 req/s
    reply
  • Alexander Borovsky

    2 years ago

    Может забыли перебить в .htaccess редирект с dispatrch.cgi на dispatch.fcgi?
    reply
  • eman

    2 years ago

    где фастцги, вопрошаю я, где?
    reply
  • Stoyan Zhekov

    2 years ago

    What about pound [ http://apsis.ch/pound/ ]? We are using it with good results. Is the nginx better/faster than pound?
    reply
  • Scoundrel

    2 years ago

    Notice: I'm going to review results of these tests and add some additional solutions like FastCGI with Lighttpd, Apache, nginx and pound server. So, stay tuned!
    reply
  • Ezra

    2 years ago

    Thanks for doing the benchmarks. But I have one big question. What exactly are you testing here? Arew you just hitting the default welcome to rails page of a fresh new rails app? It seems that way to me. So I think your tests are flawed because they are measuring a static html file and not a dynamic rails request. You shou7ld at least set up a hello world controller/action that does at least a siumnple db select query to really test the performance of rails. I seriously doubt that you can get almost 1000 req/sec with a dynamic rails page. It is in the range of what you can expect for static pages but for dynamic pages with at least one db query you will more likely get somewhere around 90-130req/sec. Can you run your tests again against a real rails request? When you just test a staic file, rails does not even get invoked so you are not really testing rails at all.
    reply
  • Scoundrel

    2 years ago

    2Ezra: Hmmm... I've tested on simple start page... Thanks for comment - I will redo all tests and will post results in next blog article.
    reply
  • Ezra

    2 years ago

    Cool. I wasn't aware of nginx before I saw your post so I am very interested in it. I downloaded it and I will play with it myself also. Thank you!
    reply
  • kpumuk

    2 years ago

    Alexander Borovsky: нет, не забыл. именно dispatcher.fcgi
    reply
  • Ezra

    2 years ago

    Alexey- would you mind emailing me so we could have a discussion about nginx? I am writing a book about rails deployment and I am very excited to learn of this project. I would love to work with you to get the optimal setup for running rails with nginx/mongrel and nginx/fastcgi. Would you please contact me so we could discuss more? I think you should have my email already from the comment form. Thank you for your time.
    reply
  • heri

    2 years ago

    hello
    thanks for this post, i did not knew about nginx.

    you might want to chechk out fcgi it is faster than fastcgi

    i thought i would use mongrel or lightpd but apache + fcgi was faster (for http://sprinj.com at least)
    reply
  • Wenix

    2 years ago

    Hi,

    Just a typo notice:
    The title says lihgttpd instead of lighttpd.
    reply
  • Ezra

    2 years ago

    I have another question regarding nginx. Is there a way to set it up for use with rails so that it will first check for static files and then if it doesn not find a file it will invoke the proxy to the backend to get the request? This is how rails page caching works. So if an url like example.com/foo/bar was to be requested, nginx would look for /foo/bar.html and serve it directly if it exists but if not exist it would foreward the request to the proxy backend server? Maybe by using a 404 error handler or something? I would be very interested in gettign a nginx config that has nginx serving all static and page cached files and then forwarding any other requests to a cluster of mongrels via the proxy.

    Thanks for mentioning nginx, I have been playiung with it today and I like it very much so far.
    reply
  • Scoundrel

    2 years ago

    2Ezra: yeah. You can create such setup for nginx. You can use rewrite module in following way:
    <pre>
    server {
    root /path/to/your/public;

    location / {
    if (!-f $request_filename.html) {
    # your proxy configuration
    ...
    ...
    }

    rewrite (.*) $1.html last;
    }

    location ~ \.html {
    #dummy location for static files
    }
    }</pre>
    reply
  • Ezra

    2 years ago

    Very cool Alexey. I think nginx is my new favorite front for rails apps. I'm not sure exactly what the dummy location for static files does? Can you explain? Also does this setup automatically serve images, js and css files as static if they are in the public dir of the rails app? Or do I need to add a location ~ .js and a location ~ .css, etc... ?

    I appreciate your help with this.
    reply
  • Alexander Solovyov

    2 years ago

    > I’m not sure exactly what the dummy location for static files does?

    There you must define root for cached pages, like:


    root /path/to/cache


    > Also does this setup automatically serve images, js and css files

    No, you must define location like this:


    location ~* ^.+\.(jpg|jpeg|gif|css|js)$ {
    root /path/to/static;
    }
    reply
  • Peter Zaitsev

    2 years ago

    Как и все удивлен почему FastCGI не тестировался... Касаемо Lighttpd - reverse proxy у него несколько кривой не держит keep-alive что я думаю и является причиной тормозов в данном случае.
    reply
  • Alexander Solovyov

    2 years ago

    Хмм... Да, кстати, насчёт keep-alive, заметка на будущее тестирование: статические файлы надо бы сервить отдельно самим фронтендом, без бэк-ендов. Так и быстрее будет, и keep-alive влиять не будет. ;)
    reply
  • Al

    2 years ago

    Hi,

    great blog-entry ;-)

    Please can you also add HAProxy to your tests ;-)

    http://haproxy.1wt.eu/

    --- advertisment from homepage
    .
    .
    HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications. It is particularly suited for web sites crawling under very high loads while needing persistence or Layer7 processing. Supporting tens of thousands of connections is clearly realistic with todays hardware. Its mode of operation makes its integration into existing architectures very easy and riskless, while still offering the possibility not to expose fragile web servers to the Net.
    .
    .
    ---
    reply
  • xing

    2 years ago

    We would love to see LiteSpeed, http://www.litespeedtech.com. Our 2.2 in-addition to our Ruby LSAPI is one of the top performing platforms for Rail deployment.
    reply
  • Scoundrel

    2 years ago

    2xing: I would be glad to add your software to next benchmark, but I can't get trial version from your site... there is some error after trial download form... If you want, you can send me archive with trial version by email and I will test it.
    reply
  • xing

    2 years ago

    2Scoundrel: We have fixed the trial form error. Please try to download the enterprise edition trial key once more. Thanks.
    reply
  • Scoundrel

    2 years ago

    2xing: no luck...

    Thank you trying out LiteSpeed Web Server Enterprise Edition. You will receive an email shortly with the trial license.


    But no mail... so, resend it to me manually, please.
    reply
  • Scoundrel

    2 years ago

    Wow I've got my license key for LiteSpeed! Will test it now...
    reply
  • Marc

    2 years ago

    Another question concerning nginx. Since it has been installed I can not figure out how to set php.ini values such as upload_max_size. Is there a specific way to go about configuring these settings? There is no php.ini file in the path now being reported in phpinfo()
    reply
  • Scoundrel

    2 years ago

    2Mark:

    $ php -i | grep php.ini
    Configuration File (php.ini) Path => /etc/php5/cli/php.ini


    Try such command and you'll see where php tries to find its configs.
    reply
  • Matte

    2 years ago

    Thanks for your benchmarks! You can also use httperf to get speed tests.
    reply
  • TomK32

    1 year ago

    There's a little difference in your setup, lighttpd has accesslogs on while nginx doesn't. I guess that should make a bit of a difference, no?
    reply
  • Scoundrel

    1 year ago

    2Thomas: strange, nginx always has really flexible and pretty convenient logging system.
    reply
  • Aleksey

    1 year ago

    Thomas means enabled logs on lighttpd may and probably will make things slower compared to nginx running without logging.
    reply
  • gamer

    1 year ago

    Mongrel еще поддерживает фреймверк IOWA
    reply
  • Ruby Developers

    1 year ago

    Aleksey,

    I agree, I believe that Thomas meant that enabling the logs on the Lighttpd would make everything run slower than Nginx without the logs. But isn't it obvious? If you want faster then you have to unable the logging features.

    Jenn
    reply
  • ashes999

    11 months ago

    Hi,

    We're having some discussion on the RailsRocket forums about the performance of different web-servers. Have you tried the Thin web-server? How does it compare to the rest?
    reply

Add New Comment

Returning? Login