Ruby On Rails jest powolny...?

Ile z tych zapytań 0-10 MS jest wykonywanych na dostęp do widoku? Jakie części modelu danych są odwołane? Czy używasz :include, aby uzyskać chętne ładowanie na swoje Stowarzyszenia?

Rails jest tak powolny, jak to robisz. Ze zrozumieniem przychodzi szybkość (Zwykle!)

Rozszerzając powyższe, czy masz skojarzenia has_many, gdzie w szczególności twój pogląd odnosi się do strony "wielu" Bez :include? Powoduje to, że Twój find(:all) na stole głównym zostanie wykonany z dołącz do szczegółów - jeśli masz dużą liczbę szczegółowych rekordów i przetwarzasz wszystkie z nich indywidualnie, może to być drogie.

Coś takiego:

Master.find(:all, :include => :details)

...może pomóc. Ale wciąż zgaduję z nielicznych informacji.

Jest stary Railscast na temat tutaj

Podczas gdy R-n-r ma reputację powolnego , brzmi to zbyt ekstremalnie, aby być prostym problemem z językiem.

Powinieneś uruchomić profiler, aby dokładnie określić, które funkcje są wolne i dlaczego. Najczęstszą rzeczą spowalniającą aplikację internetową jest " N+1 problem". Oznacza to, że gdy masz n pozycji danych w bazie danych, aplikacja sprawia n oddzielnych zapytań do bazy danych zamiast jednego zapytania, które je pobiera. Ale nie możesz wiedzieć dopóki nie uruchomisz profiler. ruby-prof to jeden profiler, którego używałem.

Edit based on profile results edit:

Mocno wierzę, że można zawsze usuń pętlę zapytań. Jak mówi Mike Woodhouse, Rails sposobem na to jest określenie relacji między tabelami z has_many lub inne skojarzenie, a następnie niech rails automatycznie wygeneruje połączenie tabeli, jest to jasne, szybkie i "droga szyn". Ale jeśli zaczynasz od goły SQL lub jeśli skojarzenia nie działają w tym przypadku, możesz po prostu wygenerować odpowiednie połączenia samodzielnie. A jeśli Wszystko inne zawiedzie, możesz utworzyć widok lub tabelę denormalizowaną, która przechowuje wyniki, które wcześniej zostały znalezione za pomocą pętli. Rzeczywiście, fakt, że musisz iterację poprzez generowane zapytania Może być znakiem, że sam projekt tabeli ma pewne wady.

Wszystko, co powiedział, Jeśli buforowanie wyników zapytań działa wystarczająco dobrze dla Ciebie, a następnie pozostać z nim. Optymalizuj w razie potrzeby.

To nie jest normalne. Masz jakąś logikę, która Cię spowalnia. Próbując komentować fragmenty kodu, które Twoim zdaniem zajmują dużo czasu i sprawdź, czy to pomaga. Jeśli tak, to musisz wymyślić, jak zoptymalizować tę logikę.

Of you are doing lots for a loop iterating through a very large objects, then of course it will be slow.

Tego typu problemy mogą pojawić się w dowolnym języku lub frameworku. Podczas gdy Ruby nie jest tak szybki jak w innych językach, jest wystarczająco szybki przez większość czasu. Jeśli musisz stale obliczać z dużymi zestawami danych, Ruby może nie być odpowiednim językiem dla Ciebie. Spójrz na napisanie rozszerzenia Ruby C, które obsłuży Twój kod zmniejszający wydajność. Ale najpierw spróbuj zdiagnozować i refaktor.

Na koniec sprawdź RubyProf , aby zobaczyć, czy może pomóc Ci znaleźć wąskie gardło.

Dwie poprzednie odpowiedzi są pomocne, zwłaszcza przy użyciu narzędzi do monitorowania wydajności. Używam New Relic RPM i bardzo mi to pomogło w przeszłości.

Jednak tego rodzaju narzędzia są naprawdę najlepsze, gdy próbujesz przyspieszyć z, powiedzmy, 3 sekund do mniej niż 1 sekundy.

2-4 minuty na renderowanie widoku nie są normalne w żadnych normalnych okolicznościach.

Czy mógłbyś nam pokazać niektóre dzienniki rozwoju, aby dowiedzieć się, gdzie wąskie gardła są?

Czy uwzględniasz czas potrzebny przeglądarce na załadowanie obrazów, javascriptów lub innych plików do tego całkowitego pomiaru?

Tak długi czas wykonania sprawi, że będę podejrzewał problem z siecią - może zapytanie DNS jest timing out na głównym serwerze DNS?

Możesz spróbować użyć JRuby lub przełączyć się na Ruby 1.9.
Oba z nich powinny spowodować ogromne zwiększenie wydajności.
Problem z JRuby polega na tym, że kamienie używające C nie będą kompilować/działać. Istnieją odpowiedniki Javy, które są instalowane przez aplikację " gem " jruby, ale niektóre z nich po prostu nie działają]}

Zasadniczo będziesz miał ten sam problem z Ruby 1.9. Trochę zmieniła się składnia, ale głównym problemem jest to, że duża ilość klejnotów już nie działa. Ludzie się rozwijają aktualizacji (sprawdź postęp w http://isitruby19.com/)

Dlaczego nie pobrać wszystkich danych i mieć pętli for znaleźć je lokalnie w pamięci, zamiast odpytywania bazy danych za każdym razem? 1000 zapytań dla pojedynczego widoku wskazuje, że coś jest poważnie nie tak z Twoim projektem.

Jest kilka dobrych screenów na ten temat http://railslab.newrelic.com/scaling-rails

Takie rzeczy jak buforowanie fragmet i używanie: include (aby uniknąć n+1) mogą pomóc. Wygląda na to, że już używasz memcached, więc dlaczego nie zwinąć adresu url, aby wstępnie ustawić pamięć podręczną?

Kiedy przywiązałem serwer do adresu IP Box zamiast 0.0.0.0, przyspieszyło to wszystko dla mnie.

Możesz najpierw profilować kod przed zrobieniem czegokolwiek, jednak zapytania wewnątrz pętli są bardzo częstą przyczyną problemów z wydajnością i na pierwszy rzut oka wydaje się to Twoim problemem. W każdym razie możesz znaleźć praktyczny profiler tutaj :

Jak już wspomniano na innych odpowiedziach, jeśli oba modele są ze sobą powiązane, należy załadować Asocjacje, co implikuje polecenie Active Record do wykonania zapytań join:

#left outer join
ofkbs=Ofkb.includes(:operation).where(name: "banana")

Jeśli nie potrzebujesz ofkbs, a tylko operacje, można wykonać połączenie wewnętrzne

#inner join (discards the Ofkbs that do not have any operation)
operations=Operation.joins(:ofkb).where(ofkb:{name:"banana"})

To rozwiązanie preformuje tylko jedno zapytanie, a następnie pozwala na iterację danych, które zostaną już zebrane z DB:

operations=ofkbs.map{|of| of.operations}.flatten

operations.each do |o|
  do_whatever_you_want_with_operation(o)
end

Jeśli zapytania są bardzo skomplikowane, powinieneś użyć arel .