- Posted in: Uncategorized
- Tags: Nginx
30 Aug2006
If you will try to compile nginx in Redhat Linux, you can get following error even if you have pcre-devel package installed:
1
2
3
4
5
6
7
8
9
10
| Configuration summary
+ threads are not used
+ PCRE library is not found
....
....
./configure: error: the HTTP rewrite module requires the PCRE library.
You can either disable the module by using --without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with nginx by using --with-pcre=<path> option.
</path> |
If you are experiencing this small problem, you should simply use following parameter of configure script:
1
| # ./configure --with-cc-opt="-I /usr/include/pcre" |
And voila!
1
| + using system PCRE library |
Now it can see and will use system PCRE library.
[lang_en]
This article is part of “Looking For Optimal Solution” series, devoted to testing various Ruby On Rails deployment schemes and doing some simple benchmarks on these schemes. General idea of testing is to find subset of most optimal RoR deployment schemes for different situations.
This small article is about Rails+Mongrel setup and its performance. List of other tested deployment schemes, description of testing methodology and, of course, all benchmark results you can find on “Ruby On Rails Benchmark Summary and Findings” page.
[/lang_en]
[lang_ru]
Эта статья является частью серии “В поисках оптимального решения“, посвященной тестированию производительности различных схем развертывания приложений на Ruby On Rails. Основной идеей тестирования является поиск подмножества самых оптимальных с точки зрения производительности решений по установке RoR-приложений в различных ситуациях.
Эта небольшая статья посвящена установке связки Rails+Mongrel и ее производительности. Список всех протестированных схем развертывания, описание методики тестирования и результаты всех тестов вы можете найти на странице “Результатов и Выводов“.
[/lang_ru]
Read the rest of this entry →
[lang_en]
Aftrer my previous post about high-performance RoR deployment methods, I’ve got lots of messages/emails/IM conversations about some errors in previous benchmarks and there were lots of suggestions about extending of tested software set and modifying testing methodology. So, that is why I decided to perform deep and wide performance testing for all deployment schemes I can find. In this article you can find description of testing methodology and, of course, benchmarks results. If you want to know details of specific software setup, take a look at articles in category “Ruby On Rails” to find all articles from “Looking for optimal Solution” series (I’ll post all of them in next few days).
[/lang_en]
[lang_ru]
После выхода моей предыдущей статьи о методах высокопроизводительной настройки проектов на RoR, я получил море сообщений/писем и поговорил с кучей народу через IM и многие сообщения касались логических или методических ошибок в процессе тестирования или содержали в себе просьбу расширить или изменить параметры тестирования. Именно поэтому я решил провести новое тестирование – более глубокое и намного более широкое в плане охвата различных решений. В этой статье Вы сможете ознакомиться с методикой тестирования и, конечно же, с результатами проведенных тестов. Если Вас интересуют детали настройки ПО в отдельных тестах, Вы можете заглянуть в раздел сайта, посвещенный “Ruby On Rails” и прочесть отдельные сообщения из серии “В поисках оптимального решения” о каждом из тестировавшихся подходов к запуску rails-приложений (статьи о конфигурации будут готовы в течение ближайших нескольких дней).
[/lang_ru]
Read the rest of this entry →
[lang_en]
While I’ve been doing performance testing of different Ruby on Rails deployment schemes, I came across very interesting software – HAProxy.
HAProxy is a TCP/HTTP reverse proxy which is particularly suited for high
availability environments. Indeed, it can :
– route HTTP requests depending on statically assigned cookies ;
– spread the load among several servers while assuring server persistence
through the use of HTTP cookies ;
– switch to backup servers in the event a main one fails ;
– accept connections to special ports dedicated to service monitoring ;
– stop accepting connections without breaking existing ones ;
– add/modify/delete HTTP headers both ways ;
– block requests matching a particular pattern ;
It needs very little resource. Its event-driven architecture allows it to easily
handle thousands of simultaneous connections on hundreds of instances without
risking the system’s stability.
As for me, I’m really impressed by HAProxy’s performance and I will suggest to try to use it in some high-availability environments because of its performance and set of features. Take a look at this software – it is really good tool!
[/lang_en]
[lang_ru]
Пока я проводил тестирование производительности различных схем запуска проектов на Ruby on Rails, я наткнулся на очень интересное ПО – HAProxy.
HAProxy is a TCP/HTTP reverse proxy which is particularly suited for high
availability environments. Indeed, it can :
– route HTTP requests depending on statically assigned cookies ;
– spread the load among several servers while assuring server persistence
through the use of HTTP cookies ;
– switch to backup servers in the event a main one fails ;
– accept connections to special ports dedicated to service monitoring ;
– stop accepting connections without breaking existing ones ;
– add/modify/delete HTTP headers both ways ;
– block requests matching a particular pattern ;
It needs very little resource. Its event-driven architecture allows it to easily
handle thousands of simultaneous connections on hundreds of instances without
risking the system’s stability.
Что касается меня, я был очень впечатлен производительностью HAProxy и хочу посоветовать Вам попробовать его в своих проектах, связанных с high-availability решениями. Данный балансировщик обладает очень хорошей производительностью и набором функциональности – взгляните на него и, возможно, он сможет помочь Вам сделать вашу систему быстрее и стабильнее!
[/lang_ru]
[lang_en]
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 Rails as primary framework. My first task was to prepare runtime environment for it on one of our development servers. When I have tried to research how people doing it, I noted that there is no information about how to deploy rails application with nginx as frontend and what is performance of such solution. Before blindly make any decisions about future platform I’ve decided to make some performance tests of the some most popular rails web servers/frontends. Results of these tests you can find here with configuration samples for all software that I have used.
[/lang_en]
[lang_ru]
Из-за возможных ошибок в методике тестирования приведенные результаты могут быть не корректными. Потому бяло принято решение провести тестирование заново с измененными параметрами и набором тестов. Новые результаты тестирования Вы можете получить в серии статей “В Поисках Оптимального Решения” и в статье, описывающей результаты всей серии тестов.
На этой неделе мы начали проект, использующий Ruby on Rails как основное средство разработки. Моей первоочередной задачей являлась настройка окружения на одном из наших development-серверов. Когда я попытался разобраться, как же другие люди запускают и используют RoR, я заметил, что в Internet нет информации о настройке rails-приложений в связке с nginx frontend и нет информации о производительности такого решения. Перед тем, как вслепую выбирать решение для хостинга нового проекта я решил провести небольшое тестирование популярных решений для запуска Rails-приложений. Результаты этих тестов и конфигурационные файлы, использованные при тестировании, вы можете увидеть в этой статье.
[/lang_ru]
Read the rest of this entry →