Skalowalność/wydajność Ruby on Rails? [zamknięte]

RoR jest używany z wieloma ogromnymi witrynami, ale tak jak w przypadku dowolnego języka lub frameworka, potrzeba dobrej architektury (skalowanie db, buforowanie, strojenie itp.), aby skalować do dużej liczby użytkowników.

Wprowadzono kilka drobnych zmian w RoR, aby ułatwić skalowanie, ale nie oczekuj, że będzie skalowany magicznie dla Ciebie. Każda witryna ma inne problemy ze skalowaniem, więc musisz włożyć trochę pracy, aby ją skalować.

Rozwijaj się w technologii, która da Twojemu projektowi największe szanse na sukces - szybki rozwój, łatwe debugowanie, łatwe wdrażanie, dobre narzędzia, znasz to na wylot (chyba że chodzi o naukę nowego języka) itp.

Jeśli masz dziesiątki milionów uników miesięcznie, zawsze możesz zatrudnić kilka osób i przepisać w innej technologii, jeśli potrzebujesz as ...

... będziesz rake - ing w cache (sorry-couldn ' t opieraj się!!)

Po pierwsze, być może bardziej sensowne byłoby porównywanie Railsów z Symfony, CodeIgniter lub CakePHP, ponieważ Ruby on Rails jest kompletną aplikacją webową ramy. W porównaniu do PHP czy frameworków PHP, Aplikacje Rails oferują zalety, że są małe, czyste i czytelne. PHP is perfect dla małych, osobistych stron (pierwotnie oznaczało to " Personal Home Page"), podczas gdy Rails jest pełnym FRAMWORKIEM MVC, który może być użyty do budowania dużych miejsca.

Ruby on Rails nie ma a większy problem ze skalowalnością niż porównywalne frameworki PHP. Zarówno Rails, jak i PHP będą dobrze skalowane, jeśli masz tylko umiarkowaną liczbę użytkowników (10 000-100 000), którzy działają na podobnej liczbie obiektów. Dla kilku tysięcy użytkowników klasyczna monolityczna architektura będzie wystarczy. Z odrobiną M & M (Memcached i MySQL) możesz także obsługiwać miliony obiektów. Architektura M&M wykorzystuje serwer MySQL do obsługa zapisów i Memcached w celu obsługi dużych obciążeń odczytu. Tradycyjna storage pattern, a pojedynczy serwer SQL z wykorzystaniem znormalizowanych tabel relacyjnych (lub w najlepszym wypadku Konfiguracja SQL Master/Multiple Read Slave), już nie działa dla bardzo dużych witryn.

Jeśli masz miliardy użytkowników takich jak Google, Twitter i Facebook, to prawdopodobnie Architektura rozproszona będzie lepsza. Jeśli naprawdę chcesz skaluj swoją aplikację bez ograniczeń, użyj jakiegoś taniego sprzętu towarowego jako fundament, podziel swoją aplikację na zestaw usług, zachowaj każdy komponent lub usługa skalowalna sama (Zaprojektuj każdy element jako skalowalną usługę) i dostosować architekturę do aplikacji. Następnie będziesz potrzebował odpowiednich skalowalnych magazynów danych, takich jak bazy danych NoSQL i rozproszonych tabel hashowych (DHTs), będziesz potrzebował rozbudowanej mapy-zmniejsz algorytmów do pracy z nimi, będziesz musiał poradzić sobie z SOA, zewnętrzne usługi i wiadomości. Ani PHP, ani Rails nie oferują tutaj magicznej kuli.

Co jest załamuje się z RoR jest to, że jeśli nie jesteś w top 100 Alexa, nie będziesz miał żadnych problemów ze skalowalnością. Będziesz miał więcej problemów ze stabilnością hostingu współdzielonego, chyba że możesz wycisnąć Phusion, Passenger lub Kundel.

Poświęć trochę czasu, aby przyjrzeć się problemom, z którymi musieli sobie poradzić użytkownicy Twittera, a następnie zadaj sobie pytanie, czy Twoja aplikacja będzie musiała skalować się do tego poziomu.

To i tak zbuduj go w Rails, bo wiesz, że to ma sens. Jeśli dojdziesz do woluminów na poziomie Twittera, będziesz w szczęśliwej sytuacji, rozważając opcje optymalizacji wydajności. Przynajmniej będziesz je stosować w ładnym języku!

Nie można porównywać PHP i ROR, PHP jest językiem skryptowym jak Ruby, a Rails jest frameworkiem jak CakePHP.
Stwierdziłem, że zdecydowanie sugeruję Ci Rails, ponieważ będziesz miał aplikację ściśle zorganizowaną we wzorze MVC , a to jest musi dla Twoich wymagań skalowalności. (Używając PHP trzeba było zadbać o organizację projektu na własną rękę).
Ale jeśli chodzi o skalowalność, Rails to nie tylko MVC: na przykład, możesz zacząć rozwijać swoje aplikacja z bazą danych, zmieniając ją na drodze bez żadnego wysiłku (w większości przypadków), więc możemy stwierdzić, że aplikacja Rails jest (prawie) niezależna od bazy danych ponieważ jest to ORM (które pozwalają uniknąć zapytań do bazy danych), możesz zrobić wiele innych rzeczy.
(Spójrz na ten film http://www.youtube.com/watch?v=p5EIrSM8dCA )

Chciałem tylko dodać trochę więcej informacji do inteligentnego punktu Keitha Hansona o problemie 1 + N, gdzie stwierdza:

DataMapper jest doskonałym sposobem radzenia sobie z powyższym problemem( nie ma z nim problemów 1 + N), ale jeszcze lepszym sposobem jest użycie mózgu i zaprzestanie wykonywania takich zapytań :d kiedy potrzebujesz surowej wydajności, większość warstw ORM nie poradzi sobie z ekstremalnie niestandardowymi zapytaniami, więc równie dobrze możesz je napisać ręcznie.

Doktryna jest jednym z najpopularniejszych ORM dla PHP. Rozwiązuje ten problem złożoności 1 + N nieodłącznie związany z ORMs, dostarczając język o nazwie Doctrine Query Language (DQL). Pozwala to na pisanie wyrażeń podobnych do SQL, które wykorzystują istniejące relacje modelu. e. g

$q = Doctrine_Query:: Create() - >wybierz(*) - >z (Model m) - >leftJoin (m. ModelB) - >execute ()

Odnoszę wrażenie z tego wątku, że problemy ze skalowalnością ROR sprowadzają się przede wszystkim do bałaganu, w którym orms jest w odniesieniu do ładowania obiektów potomnych - tj. W powyższym przykładzie Ryan dał z psami i właścicielami:

Dog.find(:all).each do |dog|
   #N queries
   dog.owner.siblings.each do |sibling|
      #N queries per above N query!!
      sibling.pets.each do |pet|
         #Do something here
      end
   end
end

Potrzebujesz składni, która z góry informuje system, jakie Dzieci chcesz załadować dla tego konkretnego zapytania. Możesz to zrobić poprzez "chętne" Ładowanie LinqToSql (C#), które nie jest częścią ROR, ale mimo że skutkuje to jedną podróżą w obie strony do DB, to nadal są to setki oddzielnych instrukcji SQL w sposób, w jaki został on obecnie skonfigurowany. Chodzi bardziej o historię ORM. Po prostu ruszyli złą drogą z to i nigdy tak naprawdę nie odzyskałem w moim opnion. "Leniwe ładowanie" jest domyślnym zachowaniem większości ORM, tj. ponawianie kolejnej podróży w obie strony za każdą wzmiankę o obiekcie dziecka, co jest szalone. Następnie z "eager" loading-Ładowanie dzieci z góry, które jest ustawione statycznie we wszystkim, co wiem poza LinqToSql - tj. które dzieci zawsze ładują z pewnymi obiektami - tak jakbyś zawsze potrzebował tych samych dzieci załadowanych podczas ładowania kolekcji psów.

You need some kind of mocno wpisana składnia mówiąca, że tym razem chcę załadować te dzieci i wnuki. Czyli coś w stylu:

Dog.Owners.Include()
Dog.Owners.Siblings.Include()
Dog.Owners.Siblings.Pets.Include()

Wtedy możesz wydać polecenie:

Dog.find(:all).each do |dog|

SYSTEM ORM będzie wiedział, jakie tabele musi połączyć, a następnie zszyć wynikowe dane do heirarchii OM. To prawda, że można rzucić sprzętem na obecny problem, który generalnie jestem za, ale nie jest to powód, dla którego ORM (tj. Hibernate, Entity Framework, Ruby ActiveRecord) nie powinien być po prostu lepszy napisane. Sprzęt naprawdę nie wyciąga cię z zapytania 8 w obie strony, 100-SQL, które powinno być jedną w obie strony i jedną instrukcją SQL.