RubyPolRails : Ruby cms -

Wezmę udział w konferencji RuPy 2008

Wed, 13 Feb 2008 21:36:00 +0000

Właśnie dostałem informację, że mój wykład “Complicated SQL queries in Ruby on Rails applications” (tytuł angielski, bo konferencja po angielsku) został zaakceptowany na konferencję RuPy 2008, która odbędzie się w Poznaniu 12-13 kwietnia. Szczegóły na stronie konferencji. Zapraszam serdecznie - poza niezwykle pouczającymi :) wykładami będzie również okazja spotkać się i pogadać.

Współbieżność - testowanie

Mon, 11 Feb 2008 21:14:00 +0000

W poprzednim poscie opisałem typowe problemy współbieżnościowe i zaproponowałem ich rozwiązania, natomiast teraz chciałbym uzupełnić ten opis o sposoby testowania pod kątem współbieżności w sposób jak najbardziej zgodny z filozofią Rails.

Na początku zastrzeżenie - opisuję coś, co napisałem sam na własne (tzn. tworzonego projektu) potrzeby. Na pewno wiele elementów dałoby się ulepszyć i może uda mi się z tego zrobić kiedyś plugina, ale na razie mój “system testowania współbieżnego” pozostaje w pierwszej, oryginalnej wersji zgodnie z zasadą, że prowizorki są najbardziej trwałe :)

Warto stworzyć osobny katalog na testy współbieżności, ja swój nazwałem test/concurrent.W tym katalogu tworzymy bazową klasę dla testów, np. ConcurrentTest:

    require 'test/unit/ui/console/testrunner'

    class ConcurrentTest < Test::Unit::TestCase

      def concurrent( count )
        saved_config = ActiveRecord::Base.remove_connection
        (1..count).collect { |i|
          fork do
              ActiveRecord::Base.establish_connection( saved_config )
              yield i
          end
        }.each {|process_id| Process.waitpid process_id}
      end

      def self.run
        Test::Unit::UI::Console::TestRunner.run(self)
      end
    end

Jeśli chcemy korzystać z istniejącego test helpera, to dodajemy na początku pliku linię require File.dirname( __FILE__ ) + '/../test_helper'.

Myślę, że kod jest zrozumiały - w samym teście wywołujemy metodę concurrent_test zadając jej ilość współbieżnych procesów, a metoda ta forkuje odpowiednią ich ilość i dla każdego wykonuje blok. Bardzo ważne jest prawidłowe zarządzanie połączeniami do bazy danych - jeśli nie będziemy tworzyli osobnego połączenia dla każdego procesu potomnego, to ten, który zakończy pierwszy nieźle namiesza zamykając połączenie używane przez pozostałe.

Teraz przykład testu:

    #!/usr/bin/env ruby
    require File.dirname( __FILE__ ) + '/concurrent_test_helper'

    class PostTest < ConcurrentTest

      fixtures :posts

      def test_view_count
        count = 10
        post = Post.find 1
        assert_equal 0, post.view_count
        concurrent( count ) do
          post = Post.find 1
          sleep 1
          post.increase_view_count
        end
        post = Post.find 1
        assert_equal count, post.view_count
      end

    end

    PostTest.run

Dziesięciokrotnie zwiększamy licznik odsłon posta (w 10 współbieżnych procesach), a następnie sprawdzamy, czy wartość licznika wynosi 10. Prawda, że proste?

Wątpliwości może budzić użycie funkcji sleep - otóż jedną z najbardziej wkurzających cech błędów związanych ze współbieżnością jest trudność ich powtórzenia. W podanym wyżej przykładzie trzeba by liczyć na to, że któryś proces wykona find i increase_view_count naprzemiennie z innym, a nie że każdy z procesów wykona po kolei obie te metody, a dopiero potem pozwoli się wykonać następnemu. Użycie sleep praktycznie gwarantuje nam najpierw wykonanie find przez wszystkie procesy, a dopiero potem increase_view_count, co (przy założeniu, że increase_view_count nie dba o współbieżność) pozwoli nam na zreprodukowanie błędu za każdym razem.

Nie w każdym przypadku umieszczenie sleep w ciele testu pozwoli na odtworzenie błędu. Czasami trzeba tę funkcję wywołać w inkryminowanej metodzie albo nawet w procedurze bazodanowej (dla Postgresa byłoby to pg_sleep). Pamiętajcie u usunięciu tego wywołania po zakończeniu testowania!

Teraz wystarczy odpalić nasz plik z testem i czekać na wynik.

Integracja

Możemy zintegrować nasze współbieżne testy nieco bardziej z infrastrukturą testową Rails. W tym celu tworzymy następującego taska Rake:

    namespace :test do

      task :concurrency => 'db:test:prepare' do
        Dir.glob( "test/concurrent/*test.rb" ).each { |test| system test }
      end
    end

I teraz możemy odpalić wszystkie nasze testy używając rake test:concurrency.

Mam jeszcze taki pomysł, żeby wyprodukować ładny raport dot. ilości błędów (taki jak podaje rake test) i użyć kodu wyjścia programu w celu podliczenia ilości testów, które oblały, ale na razie pozostawiam to jako ćwiczenie dla czytelnika :)

Uwagi

jako że aplikacje Rails nie oszczędzają specjalnie pamięci, a my odpalamy ich np. 10 naraz, należy zaopatrzyć się w odpowiednią ilość RAM. Moja praktyka pokazuje, że przy 10 współbieżnych procesach laptop z 1GB RAM potrafi swapować (oczywiście uruchomione były też różne inne programy) - specjalnie do testów współbieżnych dorzuciłem jeszcze 1GB :)
ilość współbieżnych procesów można zdefiniować tak: minimalna ilość, która pozwala na w miarę regularne odtworzenie błędu. W powyższym przykładzie właściwie wystarczyłoby uruchomić 2 procesy, ale czasami i 10 to za mało.
jeśli błąd nie chce się pojawić mimo wielokrotnego uruchamiania testów, to należy jeszcze raz dokładnie przeanalizować kod: aplikacji, że potwierdzić, że błąd naprawdę może wystąpić i testu, by sprawdzić, że stworzone zostały odpowiednie warunki do jego wystąpienia (patrz uwaga nt. sleep). Pamiętajcie, że błędy “współbieżnościowe” są mało deterministyczne i kilkukrotny bezbłędny przebieg testów może świadczyć zarówno o poprawności programu jak i niskiej jakości testów
zamiast testować ponownie podobne kawałki kodu (np. licznik odsłon posta, licznik odsłon artykułów użytkownika, licznik odsłon komentarza) lepiej jest użyć sprawdzonego kawałka kodu jako wzorca, a czas przeznaczony na testowanie poświęcić na przetestowanie innego przypadku

Niepopularne problemy ze współbieżnością

Thu, 31 Jan 2008 22:29:00 +0000

Chyba każdy programista obcujący z Rails dłużej niż 3 miesiące miał do czynienia z aplikacją uruchamianą w wielu (w sensie więcej niż jednej) instancjach za pośrednictwem np. Mongrela lub FastCGI. Za to niestety bardzo niewielu zdaje sobie sprawę z problemów, jakie wielość instacji przysparza - a także, jak wiele wygodnych, skrótowych metod w Rails jest potencjalnie niebezpiecznych.

Houston, czy naprawdę mamy problem?

Przykład pierwszy: unikalność

Na początek weźmy naprawdę trywialny przykład:

category = Category.find_or_create_by_name( "Tips and tricks" )

Czytelne? Tak. Eleganckie? Tak. Może spowodować jakiś błąd? Niestety odpowiedź również brzmi “tak”. Zobaczmy, jakie kwerendy SQL “lecą do bazy” po wywołaniu powyższej linii kodu:

SELECT * FROM categories WHERE (categories."name" = 'Tips and tricks') LIMIT 1
INSERT INTO categories ("name") VALUES('Tips and tricks')

Na razie dobrze - nie ma się czego czepić. A teraz załóżmy, że mamy dwa Mongrele i że inkryminowana linia kodu jest wykonywana przez oba (np. dlatego, że użytkownik znudził się czekaniem na odpowiedź serwera i nacisnął przycisk “Submit” formularza tworzącego kategorię drugi raz). Oto jak mogą wyglądać zapytania SQL (cyfra na początku to numer serwera):

 1: SELECT * FROM categories WHERE (categories."name" = 'Tips and tricks') LIMIT 1
 2: SELECT * FROM categories WHERE (categories."name" = 'Tips and tricks') LIMIT 1
 2: INSERT INTO categories ("name") VALUES('Tips and tricks')
 1: INSERT INTO categories ("name") VALUES('Tips and tricks')

i Mongrel pierwszy zwraca błąd, bo próba stworzenia kategorii o nazwie już istniejącej spowoduje obiekcje naszego indeksu UNIQUE na polu name (bo przecież zawsze zakładamy takie indeksy, prawda? :).

Przykład drugi: zmiana atrybutu

Załóżmy, że mamy model Post (tak, wiem, niezbyt to oryginalne :)) z atrybutem view_count. Działanie zwiększające licznik odsłon posta na poziomie Rails wygląda typowo mniej więcej tak:

post = Post.find 1
post.update_attribute( :view_count, post.view_count + 1 )

co tłumaczy się na następujące linie SQL:

SELECT * FROM post WHERE id = 1
UPDATE post SET view_count = 1 WHERE id = 1

Wstawka nie na temat - co sprytniejsi czytelnicy w tym momencie zauważą, że wystarczyłoby po prostu trochę się pobawić i wywołać “ręcznie” SQL: UPDATE post SET view_count = view_count + 1 WHERE id = 1, ale po pierwsze wymaga to ręcznej zabawy (a nie po to piszemy w Rails, żeby cokolwiek robić ręcznie, prawda?), a po drugie nie pasuje mi to do koncepcji przykładu :)

Teraz ponownie weźmy nasze 2 Mongrele i obejrzyjmy zapytania SQL powstałe wskutek oparcia łokcia naszego użytkownika na przycisku F5 (oczywiście gdy otwarta jest przeglądarka na stronie z postem), co skutkuje serią szybko następujących po sobie requestów zwiększających nasz licznik view_count:

1: SELECT * FROM post WHERE id = 1
2: SELECT * FROM post WHERE id = 1
1: UPDATE post SET view_count = 1 WHERE id = 1
2: UPDATE post SET view_count = 1 WHERE id = 1

Tym razem Jedynka wykonała UPDATE przed Dwójką, ale efekt jest błędny - mimo 2 odsłon postu nasz licznik ma wartość 1! Dlaczego? Po prostu oba Mongrele pobrały post z poprzednią wartością licznika (czyli 0), zwiększyły go w pamięci i zaktualizowały w bazie. Nie wiedziały jednak biedaczki sprawy o sobie nawzajem, więc jeden z nich miał de facto nieaktualną wartość licznika.

To się naprawdę zdarza

Powyższe przykłady nie są wyssane z palca, ale trafiają się w rzeczywistych, poważnych aplikacjach. Lista potencjalnie niebezpiecznych sytuacji jest o wiele dłuższa, np. eleganckie validates_uniqueness_of wbrew pozorom nie gwarantuje nam unikalności, jeśli nie zadbamy o nią sami na poziomie bazy danych; praktycznie wszystkie sytuacje wymagające unikalności czegokolwiek narażają nas przynajmniej na błędy ze strony bazy danych (zamiast ładnych i eleganckich komunikatów Railsowych); itd.

“I co teraz, i co teraz, co z denatem?”

Możliwych rozwiązań jest kilka - najpierw omówię najogólniejsze, a potem przejdę do takich, które mają zastosowanie w specyficznych wypadkach. Na pewno zdecydowanie najgorszą możliwością jest zignorowanie problemu z nadzieją, że “jakoś to będzie”. Uwierzcie mi - nie będzie, a jeśli nie zadbaliśmy o właściwie indeksy, klucze itp. na poziomie bazy danych, to w końcu obudzimy się z ręką w nocniku i np. pięcioma kategoriami o nazwie “Tips and tricks” mimo obecności linii validates_uniqueness_of :name…

Transakcja i lock

Zdecydowanie najbardziej ogólnym, a często również najprostszym rozwiązaniem jest użycie transakcji, a następnie zapewnienie, że będą się one wykonywać po kolei (a nie jednocześnie). Można to osiągnąć ustawiając poziom izolacji transakcji bezpośrednio w naszej bazie danych, ale jako że brzydzimy się (przynajmniej na razie) brzydkimi słowami typu set transaction isolation level serializable oraz umieszczaniem SQL bezpośrednio w kodzie naszej aplikacji pokażę sposób bardziej “railsowaty”.

Weźmy drugi przykład (ten z Post i view_count). Podany kod z użyciem transakcji i locka wyglądałby mniej więcej tak:

Post.transaction do
    post = Post.find( 1, :lock => true )
    post.update_attribute( :view_count, post.view_count + 1 )
end

I już. Niepoliczona odsłona posta już się nam nie zdarzy. Prawda, że proste?

Niestety, obiecałem, że rozwiązanie będzie ogólne, a powyższy kod nie daje się zastosować do pierwszego przykładu z początku artykułu (Category.find_or_create...), ponieważ nie mamy rekordu, który potencjalnie moglibyśmy zalockować (tzn. kategoria zostanie potencjalnie stworzona, a na razie być może nie istnieje). Na szczęście z reguły nasz obiekt nie występuje sam, ale jest powiązany z innymi obiektami już istniejącymi (a co istnieje, może zostać potraktowane lockiem :). Załóżmy, że kategoria, którą chcemy znaleźć lub stworzyć ma być przypisana do postu. Wtedy nasz kod mógłby wyglądać np. tak:

post = Post.find 1
transaction do
    post.lock!
    category = Category.find_or_create_by_name( "Tips and tricks" )
    ...
end

Tutaj niewątpliwe przyda się kilka słów wyjaśnienia:

Post.find jest umieszczone przed blokiem transakcji, ponieważ nie istnieje konieczność posiadana aktualnych informacji o jakimś atrybucie posta (jak było w przypadku view_count) - nawet jeśli ustawiamy np. post.category_id, to poprzednia wartość nas w sumie nie obchodzi
użyłem transaction zamiast Post.transaction, ale przyznam się bez bicia, że nie widzę specjalnej różnicy między nimi. Prawdopodobnie zauważyłbym, gdyby jeden z modeli biorących udział był w innej bazie danych :) Ja osobiście stosuję taką zasadę: jeśli transakcja dotyczy tylko jednego modelu, to stosuję np. Post.transaction, jeśli kilku różnych - gołe transaction. Ale nie upieram się, że to idealne rozwiązanie i jestem otwarty na sugestie :)
clue całej sprawy (i różnicą w porównaniu z “prostym” lockowaniem przedstawionym wyżej) jest fakt, że kod zadziała dobrze nawet jeśli nie zmienamy nic w obiekcie post! Innymi słowy jeśli w kodzie w miejsce kropek nie wstawimy nic, to transakcje będą i tak wykonywane po kolei. Dzieje się tak dlatego, że metoda lock! powoduje wykonanie odpowiedniej, specyficznej dla danej bazy danych operacji (np. w Postgresie będzie to coś w stylu SELECT * FROM post WHERE id = 1 FOR UPDATE), która spowoduje, że inne transakcje chcące wykonać tę samą kwerendę będą musiały poczekać, aż pierwsza transakcja się zakończy. Obiekt zalockowany w ten sposób zostanie odblokowany automatycznie po zakończeniu transakcji.

Opisana metoda jest niewątpliwie najbardziej uniwersalna, natomiast czasami rzeczywiście nie da się znaleźć obiektu, który moglibyśmy zalockować (można w tym celu użyć np. aktualnie zalogowanego użytkownika, bo raczej nie wykona on zbyt wiele operacji jednocześnie, ale użycie np. kategorii używanej przy co drugiej akcji fatalnie wpłynie na wydajność). Wtedy pozostaje nam użycie jednej z pozostałych, mniej uniwersalnych, za to czasami szybszych metod.

Uproszczenie do jednego zapytania SQL

O tym było już w drugim przykładzie. Zamiast:

SELECT * FROM post WHERE id = 1
UPDATE post SET view_count = 1 WHERE id = 1

możemy użyć:

UPDATE post SET view_count = view_count + 1 WHERE id = 1

Trzeba to zrobić albo ręcznie (nie lubimy…) albo zrobić sobie metodę w stylu:

def increase_attribute( attribute, step = 1 )
  self.class.connection.execute( self.class.sanitize_sql(["UPDATE #{self.class.table_name} SET #{attribute} = #{attribute} + ? WHERE id = ?", step, self.id]) )
end

(tak naprawdę, żeby uniknąć tego powtarzanego self.class, robię z tego z reguły metodę klasy).

Polecam tę metodę, bo jej skutkiem jest bardzo prosty (i szybki) kod SQL.

Użycie funkcji/procedury bazodanowej

Ta metoda jest dość mało elegancka, ale czasami jest jedynym wyjściem, kiedy chcemy stworzyć nowy obiekt lub zupdateować stary, a nie mamy żadnego “jelenia” do zalockowania. Wróćmy do przykładu z kategorią - załóżmy, że zamiast kategorii mamy model SearchString, gdzie nie tylko przechowujemy wszystkie przeszukiwania naszych użytkowników, ale również ilość ich wystąpień. W takim wypadku funkcja dla PostgreSQL mogłaby wyglądać następująco:

CREATE FUNCTION add_search_string(str varchar) RETURNS boolean AS $$
BEGIN
  LOCK TABLE search_strings IN ACCESS EXCLUSIVE MODE;
  UPDATE search_strings SET string_count = string_count + 1, updated_at = current_timestamp WHERE string = str;
  IF NOT FOUND THEN
    INSERT INTO search_strings (string, created_at, updated_at) VALUES (str, current_timestamp, current_timestamp);
  END IF;
  RETURN true;
END;
$$ LANGUAGE 'plpgsql';

Mam nadzieję, że jest ona zrozumiała, choć niewątpliwie wyjaśnić należy linię “LOCK TABLE…”. Otóż linia ta lockuje całą tabelę (trzeba z tym uważać - akurat w tym przykładzie jedynie ta funkcja dobiera się do tabeli search_strings, ale w innych wypadkach pozostałe transakcje będą czekać, aż odblokujemy tabelę), żebyśmy mogli dodać/zupdateować naszego search_stringa bez ryzyka, że ktoś w tym czasie doda nam takiego samego stringa do tabeli.

Wywołanie funkcji w Rails wygląda tak:

class SearchString < ActiveRecord::Base
  def self.store( string )
     self.connection.execute( sanitize_sql( ["SELECT add_search_string (?)", string] ))
  end
end

Nie polecam tej metody, ponieważ jest skomplikowana, ale czasami naprawdę nie mamy innego wyjścia. I jeszcze 2 uwagi:

w PostgreSQL w funkcjach/procedurach nie działają transakcje, więc nie liczcie na nie!
w MySQL jest coś o wiele wygodniejszego, czyli dyrektywa REPLACE, która tworzy nowy wiersz lub zmienia istniejący

Podsumowanie

Jak widać, właściwe rozwiązanie problemów współbieżności nie jest tak proste, jak byśmy chcieli, ale na szczęście nie tak skomplikowane, jak byśmy się obawiali :)

Ponieważ artykuł się “nieco” rozrósł, kwestię testowania kodu pod względem współbieżności opiszę wkrótce w osobnych artykule.

Rails 2.0

Sun, 27 Jan 2008 07:37:00 +0000

W zeszłym miesiącu pojawił się długo oczekiwany release Rails 2.0. Nie będę tutaj wymieniał wszystkich nowych “ficzerów”, bo je można znaleźć chociażby tutaj, natomiast postaram się odpowiedzieć na pytanie “Czy warto migrować na nową wersję?”.

Nowe aplikacje

W przypadku nowych aplikacji odpowiedź jest prosta - na pewno warto (choć w tym przypadku ciężko jest mówić o “migracji”):

Rails 2.0 są po prostu lepsze (wydajnościowo i architektonicznie, nie licząc nowych funkcjonalności)
należy się spodziewać, że nowe wersje pluginów będą tworzone dla nowych wersji Rails, więc używanie Rails 2.0 pozwoli na uniknięcie problemów z kompatybilnością
zmiany nie są na tyle wielkie, żeby trzeba było się czegoś na nowo uczyć

Nierozwijane aplikacje

W przypadku aplikacji istniejących, lecz już nie rozwijanych odpowiedź również jest prosta - nie ma sensu migrować na Rails 2.0, bo zyski będą niewielkie, a wysiłek może być spory. Jedynym wyjątkiem jest sytuacja, kiedy istnieje ryzyko, że Rails 1.x zniknie z serwera, na którym jest zainstalowana nasza aplikacja :)

Pozostałe aplikacje

Tutaj nie da się już odpowiedzieć w dwóch zdaniach. Za migracją przemawiają na pewno argumenty z sekcji “Nowe aplikacje”. Przeciwko da się też jednak coś znaleźć:

niektóre rzadko aktualizowane lub źle napisane pluginy mogą przestać działać
może zaistnieć konieczność dokonania wielu zmian słabo poddających się automatyzacji (np. zmiany w named routes typu admin_new_post_path => new_admin_post_path - takich ścieżek bywa w aplikacji kilkadziesiąt lub więcej)
nowe funkcjonalności niewiele nam dają

Poniższa lista ma na celu pomoc w podjęciu decyzji o migracji lub jej braku. Generalna zasada jest taka, że im więcej odpowiedzi twierdzących, tym bardziej zalecałbym przejście na Rails 2.0:

tworzysz (lub chcesz tworzyć) aplikacje zgodne z REST (czyli używasz resources)
używasz multiviews, tzn. serwujesz strony jako HTML, RSS, TXT itd.
stosujesz różne metody generacji treści, np. erb, xml builder itd.
pozwalasz użytkownikom twojej aplikacji tworzyć własną treść zawierającą potencjalne niebezpieczne elementy np. HTML
stosujesz zasadę trzymania w sesji jak najmniejszej ilości danych
twoja aplikacja obsługuje bardzo dużo sesji
używasz serializacji obiektów ActiveRecord
masz problemy z zależnościami pomiędzy pluginami

Przed samą migracją na Rails 2.0 należy niewątpliwie zainstalować ostatnią wersję z serii 1.x (1.2.5) i zająć się pojawiającymi się warningami (jeśli nie pojawią się żadne, to migracja nie powinna być zbyt kłopotliwa).

Witam na moim blogu

Sat, 26 Jan 2008 16:28:00 +0000

Niniejszym ogłaszam oficjalne otwarcie mojego blogu o RubyOnRails. Dalsze informacje znajdują się na stronie About.

Jest to mój pierwszy blog w życiu, więc proszę o wyrozumiałość :)