🚀 go-pugleaf

Dnia 06.08.2006 Jaroslaw Zabiello <hipertracker@gmail.com> napisał/a:
> http://blog.zabiello.com/articles/2006/08/06/skalowanie-ror

Używa ktoś tego produkcyjnie ?

Rozłożę obciążenie np. na 6 serwerów i 6 krotnie wzrośnie
mi liczba zapytań do bazy danych ?


Gdzie centralny cache ?

-- 
Tomasz Drobiszewski

baklarz wrote:
> Dnia 06.08.2006 Jaroslaw Zabiello <hipertracker@gmail.com> napisał/a:
>> http://blog.zabiello.com/articles/2006/08/06/skalowanie-ror
> 
> Używa ktoś tego produkcyjnie ?
> 
> Rozłożę obciążenie np. na 6 serwerów i 6 krotnie wzrośnie
> mi liczba zapytań do bazy danych ?
> 
Liczba zapytań nie wzrośnie 6 krotnie tylko przez to, że dołożysz kilka 
instancji serwerów mongrel. Wzrośnie liczba połączeń z bazą ale to nie 
jest żaden problem.

Jeśli zastanawiasz się jak skalować bazę danych to polecam projekt 
memcached.

--
Karol Hosiawa

Dnia 07.08.2006 Karol Hosiawa <hosiawak@gmail.com> napisał/a:
> baklarz wrote:
>> Dnia 06.08.2006 Jaroslaw Zabiello <hipertracker@gmail.com> napisał/a:
>>> http://blog.zabiello.com/articles/2006/08/06/skalowanie-ror
>> 
>> Używa ktoś tego produkcyjnie ?
>> 
>> Rozłożę obciążenie np. na 6 serwerów i 6 krotnie wzrośnie
>> mi liczba zapytań do bazy danych ?
>> 
> Liczba zapytań nie wzrośnie 6 krotnie tylko przez to, że dołożysz kilka 
> instancji serwerów mongrel. Wzrośnie liczba połączeń z bazą ale to nie 
> jest żaden problem.
Wzrośnie.
Maszynę dostawia się gdy nie wyrabia serwer www co oznacza duży ruch.
Zakładając pełne obciążenie i użycie cache lokalnego
po przeterminowaniu owego musi iść zapytanie do bazy.
n maszyn n zapytań

>
> Jeśli zastanawiasz się jak skalować bazę danych to polecam projekt 
> memcached.
Niestety jest to cache płaski co powoduje pewne problemy i uniemożliwia
uzycie w pewnych zastosowaniach -  unieważnienie całej gałęzi.


Pozdrawiam. 
-- 
Tomasz Drobiszewski

Jaroslaw Zabiello napisał(a):
> http://blog.zabiello.com/articles/2006/08/06/skalowanie-ror

Ciekawy artykuł, dzięki.
Jestem już po lekturze książki, ale ciągle brakuje czasu, żeby
się zabrać za RoR na poważnie. Chciałbym zacząć przekonywać
klientów na porzucenie (przy niektórzych projektach) PHP na korzyść
RoR, co bardzo by mi poprawiło humor i zdrowie, ale pozostają
właśnie kwestie wydajności.
W obecnych warunkach nie mam możliwości wykonać własnych testów,
ale po przeczytaniu kilkunastu artykułów RoR vs. Django, itp.
zaczynam mieć wrażenie jakby RoR był tak wolny, że dla byle
aplikacji trzeba stawiać dedyka, a w momencie kiedy ruch wzrośnie do
kilkuset odwiedzin dziennie to trzeba będzie już stawiać klaster i w
zasadzie zacząłem się zastanawiać nawet nad Django.
Problem w tym, że grzebiąc trochę w Ruby'm przy stringach,
wyrażeniach regularnych i RoR wogule, poważnie się zadłużyłem w
tym duecie.

Stąd pytanie - jak to jest rzeczywiście z tą wydajnością ("IT'S
FAST ENOUGH" mnie nie przekonuje :)) ?
Ile aplikacji/klientów można upchnąć na przeciętnym serwerze typu
PIV 3.0, 4GB RAM, dyski SATA ?
Lepiej jeden mocny czy 2-3 słabsze ?
Rozbicie na dwa serwery - jeden na WWW i jeden na baze dużo da ?

Z góry dziękuję za dyskusję.

Pozdrawiam

Jaroslaw Zabiello wrote:
> http://blog.zabiello.com/articles/2006/08/06/skalowanie-ror

Ciekawy artykuł, dzięki.
Jestem już po lekturze książki, ale ciągle brakuje czasu, żeby
się zabrać za RoR na poważnie. Chciałbym zacząć przekonywać
klientów na porzucenie (przy niektórzych projektach) PHP na korzyść

RoR, co bardzo by mi poprawiło humor i zdrowie, ale pozostają
właśnie kwestie wydajności.
W obecnych warunkach nie mam możliwości wykonać własnych testów,
ale po przeczytaniu kilkunastu artykułów RoR vs. Django, itp.
zaczynam mieć wrażenie jakby RoR był tak wolny, że dla byle
aplikacji trzeba stawiać dedyka, a w momencie kiedy ruch wzrośnie do
kilkuset odwiedzin dziennie to trzeba będzie już stawiać klaster i w

zasadzie zacząłem się zastanawiać nawet nad Django.
Problem w tym, że grzebiąc trochę w Ruby'm przy stringach,
wyrażeniach regularnych i RoR wogule, poważnie się zadurzyłem w
tym duecie.

Stąd pytanie - jak to jest rzeczywiście z tą wydajnością ("IT'S
FAST ENOUGH" mnie nie przekonuje :)) ?
Ile aplikacji/klientów można upchnąć na przeciętnym serwerze typu
PIV 3.0, 4GB RAM, dyski SATA ?
Lepiej jeden mocny czy 2-3 słabsze ?
Rozbicie na dwa serwery - jeden na WWW i jeden na baze dużo da ?

Z góry dziękuję za dyskusję. 

Pozdrawiam

> Używa ktoś tego produkcyjnie ?
>
> Rozłożę obciążenie np. na 6 serwerów i 6 krotnie wzrośnie
> mi liczba zapytań do bazy danych ?
>
>
> Gdzie centralny cache ?


Tu by było dobre coś w stylu C-JDBC.
Nie jestem pewien czy możnaby to wykorzystać w Ruby
- jest jakiś wrapper do jdbc ?

-- 
Jan Słupicki 

On 7 Aug 2006 09:47:03 -0700, yezooz wrote:

> W obecnych warunkach nie mam możliwości wykonać własnych testów,

Dlaczego? Rails możesz uruchomić na lokalnej maszynie.

> Ile aplikacji/klientów można upchnąć na przeciętnym serwerze typu
> PIV 3.0, 4GB RAM, dyski SATA ?
> Lepiej jeden mocny czy 2-3 słabsze ?

Zależy jakie aplikacje. Aplikacja aplikacji nierówna.

> Rozbicie na dwa serwery - jeden na WWW i jeden na baze dużo da ?

Da, ale tylko wtedy jak faktycznie masz do obsługi tak duży ruch, że serwer
ci się nie wyrabia. Najprotsza zasada: optymalizację zostaw na później jak
stwierdzisz że jest potrzebna. Być może sam cache, jaki zapewnia RoR,
wystarczy. A jak nie, tzn. jak ruch rośnie tak że serwer się nie wyrabia,
to wtedy dostawiaj drugi, wydzielaj bazę itp.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Jaroslaw Zabiello wrote:
> On 7 Aug 2006 09:47:03 -0700, yezooz wrote:
>
> > W obecnych warunkach nie mam możliwości wykonać własnych testów,
>
> Dlaczego? Rails możesz uruchomić na lokalnej maszynie.

Mam laptopa 1.5 ghz centrino, więc nie jest chyba to dobra maszyna do
testów.

> > Ile aplikacji/klientów można upchnąć na przeciętnym serwerze typu
> > PIV 3.0, 4GB RAM, dyski SATA ?
> > Lepiej jeden mocny czy 2-3 słabsze ?
>
> Zależy jakie aplikacje. Aplikacja aplikacji nierówna.

No zgadza się. Ale powiedzmy jakieś bardziej zaawansowane forum czy
nieduży portalik ?

>
> > Rozbicie na dwa serwery - jeden na WWW i jeden na baze dużo da ?
>
> Da, ale tylko wtedy jak faktycznie masz do obsługi tak duży ruch, że serwer
> ci się nie wyrabia. Najprotsza zasada: optymalizację zostaw na później jak
> stwierdzisz że jest potrzebna. Być może sam cache, jaki zapewnia RoR,
> wystarczy. A jak nie, tzn. jak ruch rośnie tak że serwer się nie wyrabia,
> to wtedy dostawiaj drugi, wydzielaj bazę itp.

Tak, ale jeżeli planujesz uruchomienie usługi, która ma szansę na
dużą popularność w niedługim czasie - dobrze jest się
przygotować...

pozdrawiam

On 8 Aug 2006 08:04:13 -0700, yezooz wrote:

>> Dlaczego? Rails możesz uruchomić na lokalnej maszynie.
> 
> Mam laptopa 1.5 ghz centrino, więc nie jest chyba to dobra maszyna do
> testów.

A dlaczego by nie? Jak najbardziej dobra. Używaj mongrela zamiast webricka.
Będzie chodzić dużo szybciej.

>>> Lepiej jeden mocny czy 2-3 słabsze ?
>>
>> Zależy jakie aplikacje. Aplikacja aplikacji nierówna.
> 
> No zgadza się. Ale powiedzmy jakieś bardziej zaawansowane forum czy
> nieduży portalik ?

Zaawansowane forum? Naprawdę chce ci się odkrywać na nowo koło? Są gotowe,
dobre aplikacje w php: phpBB czy lepsze: Invision Power Board. Ja używam
tego drugiego, ma tak duże ogromne możliwości że nie przeszkadza mi, że nie
jest darmowe. 

Już dawno minęły czasy w których wszystko należałoby robić w jednym języku
i w jednej techonologii (hehe, to były marzenia w środowisku javowców - nic
z tego nie wyszło) Np. ja do CMS używam Plone, do bloga: Rails, do szybkiej
wyszukiwarki Django, a do forum: Invision Power Bord w PHP.

Co do portalu, to też nie powinno być problemu. Przecież Railsy mają
wbudowany cache na poziomie strony, fragmentu strony czy kontrolera. Poza
tym, część funkcjonalności możesz oprzeć na AJAX więc odpada ciężkie
przeładywanie całej strony. Obsługa AJAX'a w Rails jest genialnie
zaimplementowana. To jeden z głównych powodów dla których wolę Rails od
innych frameworków. Drugi to: wieksza prostota kodu niż u innych.

> Tak, ale jeżeli planujesz uruchomienie usługi, która ma szansę na
> dużą popularność w niedługim czasie - dobrze jest się
> przygotować...

Jeśli to usługa komercyjna, to jak ci serwer będzie puchł od obciążenia, na
pewno znajdzie się kasa na rozbudowę. A jak to projekt niekomercyjny, i
stwierdzasz, że Rails faktycznie nie uniesie ci obciążenia, to może
faktycznie pora na zainteresowanie się... Django.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Jaroslaw Zabiello wrote:

>> Tak, ale jeżeli planujesz uruchomienie usługi, która ma szansę na
>> dużą popularność w niedługim czasie - dobrze jest się
>> przygotować...
> 
> Jeśli to usługa komercyjna, to jak ci serwer będzie puchł od obciążenia, na
> pewno znajdzie się kasa na rozbudowę. A jak to projekt niekomercyjny, i
> stwierdzasz, że Rails faktycznie nie uniesie ci obciążenia, to może
> faktycznie pora na zainteresowanie się... Django.
> 

W zupełności się zgadzam :) Jeśli będziesz miał już te kilka milionów 
zapytań i Twój serwer z railsową aplikacją będzie ciężko dyszał to na 
pewno znajdzie się $200 na kolejny serwer, co więcej będzie to raczej 
powód do zadowolenia niż do rozpaczy :)

Z obecnie dostępnymi narzędziami (mongrel, lighttpd, memchached) 
rozbudowa nie powinna przysporzyć kłopotu osobie średniozaawansowanej w 
obsłudze *nix'ów

Z moich 1,5 letnich doświadczeń w testowaniu Railsów wynika, że 
przeciętna railsowa aplikacja działa średnio rzecz biorąc podobnie 
szybko jak przeciętna aplikacja napisana w PHP. 90% osób piszących o 
tym, że Railsy są wolniejsze od x tak naprawdę nigdy nie będzie 
potrzebowała takiej mocy obliczeniowej jak podczas testów. Jeśli będzie 
to koszt skalowania nie będzie dla nich żadnym problemem (jak wyżej).

Podsumowując, IMHO nie ma się czym zbytnio przejmować przy obecnych 
kosztach utrzymania serwerów tylko brać się do pisania (jeśli oczywiście 
masz jakiś fajny pomysł) :D

Pozdrawiam

--
Karol Hosiawa

Karol Hosiawa wrote:

> Podsumowując, IMHO nie ma się czym zbytnio przejmować przy obecnych
> kosztach utrzymania serwerów tylko brać się do pisania (jeśli oczywiście
> masz jakiś fajny pomysł) :D

Wielki dzięki za wszelkie rady!

Pozdrawiam,
Marek Mikuliszyn