> Ситуация: от момента на пускането удрям мощен трафик. Няма постепенно
> скалиране, понеже услугата имаше предишна версия, с мощен трафик и
> употреба.

> Изключително непредпазливо се натиках на хостинг, който предлага vps,
> но не разбира нищо от релси. Резултата - това, което крепи vps-а трепе
> монгрели по-успешно от софийски кучкар. Панически инсталирам god, за
> който между другото преди това не си направих труда да прочета. Което
> що годе закрепи нещата, но въпреки всичко постоянните убийства правеха
> страниците да се зареждат за минути. God съвестно си ги resurrect-ва,
> докато накрая онуй отдолу не му писва, и не убива и god, и nginx, и
> mongrel_rails. Обикновено го прави към 0:00, та да може цяла нощ сайт
> да го няма.

> Между другото, тествах първо thin. Заблуден от бавния хостинг, го
> махнах, но може и да има хляб в него.

> Хостинга нямаха никаква идея. Дебили. В 2:00 АМ решавам - ще се местя.
> Отивам до магазина за бири.

> От тук - http://www.railshostinginfo.com/

> си харесах slicehost. Много силно профилиран developer-ски хостинг.
> Дават ти чист vps + статии как да си инсталираш каквото ти трябва.
> бръкнах за 210$ и взех хостинг с 1гб за 3 месеца. Изкефих се
> максимално, поне за сега. Няма нито едно мъртво псе след цял ден
> работа.

> Това, което много ми липсва са
> * Външен MySQL сървър, който много би ме забързал;
> * Външен (и преконфигуриран) SMTP сървър. Щото станах на сервитьорката
> орнела докато разбера как се пуска smtp. И пак ще ми смъкне от
> ресурсите.

> Първо се бях навил на http://www.brightbox.co.uk/ , но много скъпи.
> Чудя се дали изнасянето на MySQL няма да ми помогне и да компенсира
> цената. Писах им един мейл с описание на какво искам да им причиня,
> като им стана клиент. Не отговориха. Вероятно не щат.

> Изкефих се на slicehost, имаха campfire, в който влязох и си питах
> зоровете. Казаха каквото има.

> За предница ползвам nginx, по препоръки на Сава.

> > От една седмица деплойвам дълго разработвания и мигриран семеен
> > бизнес, който бъхтя от половин година. Реших да си споделя
> > впечатленията, белким помогнете, или помогнат на някого.

> Универсални рецепни няма, но все пак ето някой неща, които надявам се
> да помогнат:
> 1. slicehost: Използват 64-битови Xen domUs - хубаво за mysql, но Ruby
> процесите използват доста памет - почти два пъти повече, отколкото на
> 32 битови domU. Затова се отказах от slicehost.

> 2. Ruby: Не знам каква дистрибуция ползваш, поне на Debian/Ubuntu Ruby
> се компилира с --enable-pthread заради ruby-tk, което при vps доста
> забавя нещата. Малък тест:

> strace -c ruby -e '1.upto(100000) {|i| i.to_s}'

> и виж реда:

> 99.65    1.462627           7    200006           sigprocmask

> Дискусия по проблема:http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/a3...

> Добра идея е може би също да използваш ruby-enterprice [http://www.rubyenterpriseedition.com/] - patch-нати са garbage
> collection, memory allocator и др.

> 3. nginx: всички напоследък го препоръчват, но все пак не е silver
> bullet - Добър е за статиката, но като load balancer е слаб. По
> принцип си идва с прост Round Robin. RoR е извесна с това, че обслужва
> само по един request - то си е  CGI базирано. Затова и ти трябват
> повечко application servers, било то mongrel или thin. Но ако е прост
> Round Robin и вече се обслужва някой request, nginx просто натиква
> следващия в опашката на поредния app server и той си чака там. Така
> скоро всички процеси са заети. Решения:
> - nginx-fair balancer: [http://wiki.codemongers.com/NginxHttpUpstreamFairModule
> ]
> - HAproxy (което бих ти препоръчал) -http://affectioncode.wordpress.com/2008/06/28/another-comparison-of-h...

> 4. god: Поне аз предпочитам monit [http://www.tildeslash.com/monit/]
> - лично мнение. Мисля, че  ползва по-малко памет.

> 5. thin: предимствата са, че може да го "вържеш" с nginx на unix
> socket - някой твърдят, това ускорява нещата -http://macournoyer.wordpress.com/2008/01/26/get-intimate-with-your-lo...
> . Но ако ползваш HAproxy, това май губи смисъл.

> 6. Може да помислиш по пренаписването на някой части (специално  ако
> има upload) от сайта на Merb [http://merbivore.com/] - по-малко
> памет и по-бърз (не е CGI базиран и би трябвало да обслужва няколко
> request-а едновременно).

> 1. И на мен ми направи впечатление това. Монгрелите наистина гълтат
> памет.

> 2. По принцип карам с компилирано от сорс ръби. Причини - собствената
> ми глупост. Има части от сайта (за щастие, административни), които
> ползват стара версия на hobo, която работи с пачнат rexml, страшно
> бавен. Който на всичкото отгоре не работи с нови ruby дистрибуции. Май
> първото което трябва да направя, е да ги изхвърля. Ето и резултата от
> strace:

> <pre>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>    nan    0.000000           0         9           read
>    nan    0.000000           0        16           open
>    nan    0.000000           0        16           close
>    nan    0.000000           0        32        27 stat
>    nan    0.000000           0         9           fstat
>    nan    0.000000           0        27           mmap
>    nan    0.000000           0         8           mprotect
>    nan    0.000000           0         2           munmap
>    nan    0.000000           0        13           brk
>    nan    0.000000           0        12           rt_sigaction
>    nan    0.000000           0         2           rt_sigprocmask
>    nan    0.000000           0         9         9 access
>    nan    0.000000           0         1           execve
>    nan    0.000000           0         1           getrlimit
>    nan    0.000000           0         1           getuid
>    nan    0.000000           0         1           getgid
>    nan    0.000000           0         2           geteuid
>    nan    0.000000           0         2           getegid
>    nan    0.000000           0         1           arch_prctl
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.000000                   164        36 total
> </pre>

> Имам някакви проблеми точно с GC, ще прегледам enterprise-а. Макар че
> думичката ми вдъхва страх.

> Мерси и за останалите препоръки. Ще пробвам да swap-на с thin, и ще
> пиша впечатления. Upload-а за сега не боли.

> Петьо

> On Aug 11, 5:05 am, Stoyan Zhekov <sto...@gmail.com> wrote:

> > On Aug 10, 5:37 am, Петьо Иванов <under...@gmail.com> wrote:

> > > От една седмица деплойвам дълго разработвания и мигриран семеен
> > > бизнес, който бъхтя от половин година. Реших да си споделя
> > > впечатленията, белким помогнете, или помогнат на някого.

> > Универсални рецепни няма, но все пак ето някой неща, които надявам се
> > да помогнат:
> > 1. slicehost: Използват 64-битови Xen domUs - хубаво за mysql, но Ruby
> > процесите използват доста памет - почти два пъти повече, отколкото на
> > 32 битови domU. Затова се отказах от slicehost.

> > 2. Ruby: Не знам каква дистрибуция ползваш, поне на Debian/Ubuntu Ruby
> > се компилира с --enable-pthread заради ruby-tk, което при vps доста
> > забавя нещата. Малък тест:

> > strace -c ruby -e '1.upto(100000) {|i| i.to_s}'

> > и виж реда:

> > 99.65    1.462627           7    200006           sigprocmask

> > Дискусия по проблема:http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/a3...

> > Добра идея е може би също да използваш ruby-enterprice [http://www.rubyenterpriseedition.com/] - patch-нати са garbage
> > collection, memory allocator и др.

> > 3. nginx: всички напоследък го препоръчват, но все пак не е silver
> > bullet - Добър е за статиката, но като load balancer е слаб. По
> > принцип си идва с прост Round Robin. RoR е извесна с това, че обслужва
> > само по един request - то си е  CGI базирано. Затова и ти трябват
> > повечко application servers, било то mongrel или thin. Но ако е прост
> > Round Robin и вече се обслужва някой request, nginx просто натиква
> > следващия в опашката на поредния app server и той си чака там. Така
> > скоро всички процеси са заети. Решения:
> > - nginx-fair balancer: [http://wiki.codemongers.com/NginxHttpUpstreamFairModule
> > ]
> > - HAproxy (което бих ти препоръчал) -http://affectioncode.wordpress.com/2008/06/28/another-comparison-of-h...

> > 4. god: Поне аз предпочитам monit [http://www.tildeslash.com/monit/]
> > - лично мнение. Мисля, че  ползва по-малко памет.

> > 5. thin: предимствата са, че може да го "вържеш" с nginx на unix
> > socket - някой твърдят, това ускорява нещата -http://macournoyer.wordpress.com/2008/01/26/get-intimate-with-your-lo...
> > . Но ако ползваш HAproxy, това май губи смисъл.

> > 6. Може да помислиш по пренаписването на някой части (специално  ако
> > има upload) от сайта на Merb [http://merbivore.com/] - по-малко
> > памет и по-бърз (не е CGI базиран и би трябвало да обслужва няколко
> > request-а едновременно).

> http://clockingit.wordpress.com/2008/06/18/ruby-on-rails-and-memory-u...

> За момента останах на thin + nginx + monit. Станчо, вие перете с
> enterprise, нали?

> On Aug 11, 10:50 am, Петьо Иванов <under...@gmail.com> wrote:
> > Мерси много.

> > 1. И на мен ми направи впечатление това. Монгрелите наистина гълтат
> > памет.

> > 2. По принцип карам с компилирано от сорс ръби. Причини - собствената
> > ми глупост. Има части от сайта (за щастие, административни), които
> > ползват стара версия на hobo, която работи с пачнат rexml, страшно
> > бавен. Който на всичкото отгоре не работи с нови ruby дистрибуции. Май
> > първото което трябва да направя, е да ги изхвърля. Ето и резултата от
> > strace:

> > <pre>
> > % time     seconds  usecs/call     calls    errors syscall
> > ------ ----------- ----------- --------- --------- ----------------
> >    nan    0.000000           0         9           read
> >    nan    0.000000           0        16           open
> >    nan    0.000000           0        16           close
> >    nan    0.000000           0        32        27 stat
> >    nan    0.000000           0         9           fstat
> >    nan    0.000000           0        27           mmap
> >    nan    0.000000           0         8           mprotect
> >    nan    0.000000           0         2           munmap
> >    nan    0.000000           0        13           brk
> >    nan    0.000000           0        12           rt_sigaction
> >    nan    0.000000           0         2           rt_sigprocmask
> >    nan    0.000000           0         9         9 access
> >    nan    0.000000           0         1           execve
> >    nan    0.000000           0         1           getrlimit
> >    nan    0.000000           0         1           getuid
> >    nan    0.000000           0         1           getgid
> >    nan    0.000000           0         2           geteuid
> >    nan    0.000000           0         2           getegid
> >    nan    0.000000           0         1           arch_prctl
> > ------ ----------- ----------- --------- --------- ----------------
> > 100.00    0.000000                   164        36 total
> > </pre>

> > Имам някакви проблеми точно с GC, ще прегледам enterprise-а. Макар че
> > думичката ми вдъхва страх.

> > Мерси и за останалите препоръки. Ще пробвам да swap-на с thin, и ще
> > пиша впечатления. Upload-а за сега не боли.

> > Петьо

> > On Aug 11, 5:05 am, Stoyan Zhekov <sto...@gmail.com> wrote:

> > > On Aug 10, 5:37 am, Петьо Иванов <under...@gmail.com> wrote:

> > > > От една седмица деплойвам дълго разработвания и мигриран семеен
> > > > бизнес, който бъхтя от половин година. Реших да си споделя
> > > > впечатленията, белким помогнете, или помогнат на някого.

> > > Универсални рецепни няма, но все пак ето някой неща, които надявам се
> > > да помогнат:
> > > 1. slicehost: Използват 64-битови Xen domUs - хубаво за mysql, но Ruby
> > > процесите използват доста памет - почти два пъти повече, отколкото на
> > > 32 битови domU. Затова се отказах от slicehost.

> > > 2. Ruby: Не знам каква дистрибуция ползваш, поне на Debian/Ubuntu Ruby
> > > се компилира с --enable-pthread заради ruby-tk, което при vps доста
> > > забавя нещата. Малък тест:

> > > strace -c ruby -e '1.upto(100000) {|i| i.to_s}'

> > > и виж реда:

> > > 99.65    1.462627           7    200006           sigprocmask

> > > Дискусия по проблема:
> http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/a3...

> > > Добра идея е може би също да използваш ruby-enterprice [
> http://www.rubyenterpriseedition.com/] - patch-нати са garbage
> > > collection, memory allocator и др.

> > > 3. nginx: всички напоследък го препоръчват, но все пак не е silver
> > > bullet - Добър е за статиката, но като load balancer е слаб. По
> > > принцип си идва с прост Round Robin. RoR е извесна с това, че обслужва
> > > само по един request - то си е  CGI базирано. Затова и ти трябват
> > > повечко application servers, било то mongrel или thin. Но ако е прост
> > > Round Robin и вече се обслужва някой request, nginx просто натиква
> > > следващия в опашката на поредния app server и той си чака там. Така
> > > скоро всички процеси са заети. Решения:
> > > - nginx-fair balancer: [
> http://wiki.codemongers.com/NginxHttpUpstreamFairModule
> > > ]
> > > - HAproxy (което бих ти препоръчал) -
> http://affectioncode.wordpress.com/2008/06/28/another-comparison-of-h...

> > > 4. god: Поне аз предпочитам monit [http://www.tildeslash.com/monit/]
> > > - лично мнение. Мисля, че  ползва по-малко памет.

> > > 5. thin: предимствата са, че може да го "вържеш" с nginx на unix
> > > socket - някой твърдят, това ускорява нещата -
> http://macournoyer.wordpress.com/2008/01/26/get-intimate-with-your-lo...
> > > . Но ако ползваш HAproxy, това май губи смисъл.

> > > 6. Може да помислиш по пренаписването на някой части (специално  ако
> > > има upload) от сайта на Merb [http://merbivore.com/] - по-малко
> > > памет и по-бърз (не е CGI базиран и би трябвало да обслужва няколко
> > > request-а едновременно).

> Ако някой от вас се сети за решение на описания във форума проблем, ще сме
> много щастливи. Също, кажете ако се сещате за други активни Rails общества,
> където мога да потърся помощ.

> > Тук съм описал проблема:http://railsforum.com/viewtopic.php?id=21497

> > Ако някой от вас се сети за решение на описания във форума проблем, ще
> сме
> > много щастливи. Също, кажете ако се сещате за други активни Rails
> общества,
> > където мога да потърся помощ.

> Описаната грешка изглежда е в Ragel HTTP parser-а (единствената C част
> в монгрел). Няма смисъл да се пробва с thin, защото и той ползва същия
> parser + event machine. Според Google най-често е резултат от Ajax
> (XHR) или HTTPS заявки, който не могат да се parse-нат. Някой даже си
> е играл да види как се държат разните application servers с "гадни"
> заявки: [
> http://ninh.nl/blog/2008/04/07/robustness-comparison-between-phusion-...
> ].
> Ето тука скриптчето за подаване на "гадни" заявки: [
> http://pastie.org/174641
> ].
> Май никой не предлага удачно решение. Освен такива заявки да се
> "резнат" преди да са стигнали application server-a (някъде на frontend
> web server-а - mod_rewrite и т.н.).
> Може да се опита с  apache + mod_rails [ http://www.modrails.com/ ],
> ако те ползват друг parser.
> За помощ може да опиташ mongrel-users ML [
> http://rubyforge.org/mailman/listinfo/mongrel-users
> ], http://groups.google.com/group/rubyonrails-talk ,
> http://groups.google.com/group/rubyonrails-deployment
> Между другото IRC каналите също са доста активни (даже досадни ;) ):
> #rubyonrails, #merb