2012-11-21 49 views
5

Przełączyliśmy się na nowy serwer programisty i przekonaliśmy się, że nasz pakiet testowy potrzebuje dwa razy tyle czasu, co. Przetestowaliśmy bazę danych, system plików itp., Ale te rzeczy są dość szybkie, nawet szybciej niż wcześniej.Ruby działa wolno na maszynie wirtualnej w zależności od silnika wirtualizacji.

Więc napisałem mały test porównawczy rubin (Fibonacciego) i wykonywane go kilka razy (średnio poniżej):

time_start = Time.now 
f = lambda { |x| x < 2 ? x : f.call(x-1) + f.call(x-2) } 
f.call(35) 
time = Time.now - time_start 

puts "#{time.round(4)}s needed" 

urządzenia przed z XEN: 6s

Maszyna po z OpenVZ: 11,5

Na obu komputerach jest Debian Squeeze z zainstalowanym RVM (-> skompilowane) Ruby-1.9.3-p194. Nie ma dużego obciążenia na tych maszynach, pamięć też jest w porządku.

Mniej lub więcej jedyna różnica to silnik wirtualizacji. W produkcji używamy VMware ESXi. Benchmark potrzebuje tam około 11s. Przetestowaliśmy inny serwer z KVM, tam potrzeby benchmarkowe 2,5s.


  • Maszyna z XEN: 6s
  • Maszyna z OpenVZ: 11,5s
  • automat z VMware ESXi: 11s
  • maszyna z KVM: 2,5s

Co możemy zmienić w naszej wirtualizacji, aby nasz rubin był szybszy? A może masz inny pomysł, jaki może być problem?

+0

intersting pytanie, ale moim zdaniem trudno porównać odniesienia na różnych technologiach wirtualizacji! – Robin

+0

@Sam: Niestety, nie mamy innego pojęcia, jaki to może być problem ... – MMore

+0

Uruchomiłbym test porównawczy nie-Ruby na wszystkich systemach, aby upewnić się, że problem jest związany z Rubinem. Czy wszystkie komputery są 64-bitowe? – claasz

Odpowiedz

1

Właśnie przetestowałem to na naszym ESXi 5 System z Debian Squeeze i jednym z Ubuntu Precise (Server). Na Squeeze Ruby-1.9.3-p194 należy skompilować i na Ubuntu nie. Ale wyniki są takie same w obu systemach: 11.x Sekundy. Myślę więc, że możemy zignorować wersję jądra i skoncentrować się na warstwie wirtualizacji.

+0

Właśnie przetestowałem te same rekurencyjne obliczenia fibonacci z KSH pod Ubuntu. uruchom w 0,01 s. i dowiedziałem się, że "powolny" rubin musi coś zrobić z rvm i/lub kompilacją ruby ​​przez rvm. Właśnie usunąłem ruby ​​z "rvm remove ruby-1.9.3-p194", a następnie "implem rvm". następnie ponownie zalogowałem się i zainstalowałem "apt-get install ruby1.9.3" z Ubuntu Precise Repository, która jest w zasadzie ruby-1.9.3-p0. trwało to 4,8 sekundy. więc prawie tak samo, jak z naszymi macbookami tutaj. więc każdy wie, jak rvm kompiluje ruby. Jestem pewien, że znajdziemy tam Graala! – martinseener

+0

Nawet instalując Squeeze, zmieniając źródła apt na wheezy, robiąc apt-get update i apt-get install ruby ​​(który teraz instaluje 1.9.3 z wheezy), czas wynosi 4,8 sekundy, jak powinno być. więc w jakiś sposób rvm kompiluje to "źle" i musimy na to patrzeć. – martinseener

+0

Martin - zobacz moją odpowiedź poniżej, która może pomóc ci wyjaśnić, co znalazłeś. – Casper

0

Być może narzędzie @martinseener jest włączone. Czasami warto spojrzeć na to:
http://alisnic.net/blog/making-your-ruby-fly/

a to:
https://gist.github.com/1688857?utm_source=rubyweekly&utm_medium=email

Zasadniczo RVM jest kompilacją rubin bez flag optymalizacyjnych. Może to jest problem? Opublikowane przeze mnie linki idą jednak głębiej w jeszcze większe przyspieszenia z łatami, ale podstawową poprawką jest włączenie flag optymalizacyjnych podczas kompilacji ruby ​​z rvm.

Część dalsza dyskusja tutaj:
http://www.reddit.com/r/ruby/comments/13mc3s/making_your_ruby_fly/