rails hosting впечатления
40 views
Skip to first unread message
Петьо Иванов
Aug 9, 2008, 4:37:52 PM8/9/08
to Ruby on Rails: България
От една седмица деплойвам дълго разработвания и мигриран семеен
бизнес, който бъхтя от половин година. Реших да си споделя
впечатленията, белким помогнете, или помогнат на някого.
Ситуация: от момента на пускането удрям мощен трафик. Няма постепенно
скалиране, понеже услугата имаше предишна версия, с мощен трафик и
употреба.
Изключително непредпазливо се натиках на хостинг, който предлага 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, по препоръки на Сава.
бизнес, който бъхтя от половин година. Реших да си споделя
впечатленията, белким помогнете, или помогнат на някого.
Ситуация: от момента на пускането удрям мощен трафик. Няма постепенно
скалиране, понеже услугата имаше предишна версия, с мощен трафик и
употреба.
Изключително непредпазливо се натиках на хостинг, който предлага 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, по препоръки на Сава.
Stanislav Bozhkov
Aug 10, 2008, 4:00:12 AM8/10/08
to ruby-on-rai...@googlegroups.com
Разглеждал ли си възможностите на Amazon EC2/S3? С инвестиция в малко разучаване на услугата можеш да има виртуално всичко от което имаш нужда. По-добре е от VPS според мен.
2008/8/9 Петьо Иванов <unde...@gmail.com>
Stoyan Zhekov
Aug 10, 2008, 10:05:12 PM8/10/08
to Ruby on Rails: България
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/a31872d447e867cb/40a92a28e9e03793#40a92a28e9e03793
Добра идея е може би също да използваш 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-haproxy-and-nginx/
4. god: Поне аз предпочитам monit [ http://www.tildeslash.com/monit/ ]
- лично мнение. Мисля, че ползва по-малко памет.
5. thin: предимствата са, че може да го "вържеш" с nginx на unix
socket - някой твърдят, това ускорява нещата -
http://macournoyer.wordpress.com/2008/01/26/get-intimate-with-your-load-balancer-tonight/
. Но ако ползваш HAproxy, това май губи смисъл.
6. Може да помислиш по пренаписването на някой части (специално ако
има upload) от сайта на Merb [ http://merbivore.com/ ] - по-малко
памет и по-бърз (не е CGI базиран и би трябвало да обслужва няколко
request-а едновременно).
Петьо Иванов
Aug 11, 2008, 3:50:13 AM8/11/08
to Ruby on Rails: България
Мерси много.
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...
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
>
>
> Добра идея е може би също да използваш 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...
> Добра идея е може би също да използваш 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
> ]
>
> 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...
> 4. god: Поне аз предпочитам monit [http://www.tildeslash.com/monit/]
> - лично мнение. Мисля, че ползва по-малко памет.
>
> 5. thin: предимствата са, че може да го "вържеш" с nginx на unix
Петьо Иванов
Aug 18, 2008, 5:19:12 PM8/18/08
to Ruby on Rails: България
Отбелязвам ей това:
http://clockingit.wordpress.com/2008/06/18/ruby-on-rails-and-memory-usage-leaks/
За момента останах на thin + nginx + monit. Станчо, вие перете с
enterprise, нали?
http://clockingit.wordpress.com/2008/06/18/ruby-on-rails-and-memory-usage-leaks/
За момента останах на thin + nginx + monit. Станчо, вие перете с
enterprise, нали?
Stanislav Bozhkov
Aug 19, 2008, 3:16:53 AM8/19/08
to ruby-on-rai...@googlegroups.com
За сега най-стабилната комбинация е apache + mongrel_rails , nagios za monitoring.
Искам да преминем на Nginx + Mongrel, но за сега имаме проблем. Има един-два сайта от които, след пускане на "кофти" заявки към нас и Mongrel-a връща Errors. Същите грешки, чупят напълно Thin. От друга страна, ако се пуне Nginx с Монгрел, не се чупи но пък се натоварва прекалено много от писане на error logs (апачито, някак по-кротко "плюе" подобните грешки).
Тук съм описал проблема:
http://railsforum.com/viewtopic.php?id=21497
Ако някой от вас се сети за решение на описания във форума проблем, ще сме много щастливи. Също, кажете ако се сещате за други активни Rails общества, където мога да потърся помощ.
Стан.
Искам да преминем на Nginx + Mongrel, но за сега имаме проблем. Има един-два сайта от които, след пускане на "кофти" заявки към нас и Mongrel-a връща Errors. Същите грешки, чупят напълно Thin. От друга страна, ако се пуне Nginx с Монгрел, не се чупи но пък се натоварва прекалено много от писане на error logs (апачито, някак по-кротко "плюе" подобните грешки).
Тук съм описал проблема:
http://railsforum.com/viewtopic.php?id=21497
Ако някой от вас се сети за решение на описания във форума проблем, ще сме много щастливи. Също, кажете ако се сещате за други активни Rails общества, където мога да потърся помощ.
Стан.
2008/8/19 Петьо Иванов <unde...@gmail.com>
Stoyan Zhekov
Aug 19, 2008, 5:36:59 AM8/19/08
to Ruby on Rails: България
On Aug 19, 4:16 pm, "Stanislav Bozhkov" <stanislav.bozh...@gmail.com>
wrote:
в монгрел). Няма смисъл да се пробва с thin, защото и той ползва същия
parser + event machine. Според Google най-често е резултат от Ajax
(XHR) или HTTPS заявки, който не могат да се parse-нат. Някой даже си
е играл да види как се държат разните application servers с "гадни"
заявки: [ http://ninh.nl/blog/2008/04/07/robustness-comparison-between-phusion-passenger-thin-ebb-and-mongrel/
].
Ето тука скриптчето за подаване на "гадни" заявки: [ 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
wrote:
> За сега най-стабилната комбинация е apache + mongrel_rails , nagios za
> monitoring.
> monitoring.
> Тук съм описал проблема:http://railsforum.com/viewtopic.php?id=21497
>
> Ако някой от вас се сети за решение на описания във форума проблем, ще сме
> много щастливи. Също, кажете ако се сещате за други активни Rails общества,
> където мога да потърся помощ.
Описаната грешка изглежда е в Ragel HTTP parser-а (единствената C част
>
> Ако някой от вас се сети за решение на описания във форума проблем, ще сме
> много щастливи. Също, кажете ако се сещате за други активни Rails общества,
> където мога да потърся помощ.
в монгрел). Няма смисъл да се пробва с thin, защото и той ползва същия
parser + event machine. Според Google най-често е резултат от Ajax
(XHR) или HTTPS заявки, който не могат да се parse-нат. Някой даже си
е играл да види как се държат разните application servers с "гадни"
заявки: [ http://ninh.nl/blog/2008/04/07/robustness-comparison-between-phusion-passenger-thin-ebb-and-mongrel/
].
Ето тука скриптчето за подаване на "гадни" заявки: [ 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
Stanislav Bozhkov
Aug 21, 2008, 2:44:16 AM8/21/08
to ruby-on-rai...@googlegroups.com
В крайна сметка, намерих пач за монгрел-а. Сега сме с Nginx + Mongrels и всичко върви екстра. Ако някой се сблъска с този проблем да се обажда да му хвърля пача :)
2008/8/19 Stoyan Zhekov <sto...@gmail.com>
Reply all
Reply to author
Forward
0 new messages