Wcześniej już pisałem trochę o długich procedurach i background taskach (starling/workling), ale nie potrafię przeskoczyć pewnego problemu. Posłużę się przykładem. Mam akcję, która wyświetla listę elementów w zestawieniu (co łączy się z kilkoma zapytaniami do bazy, które obciążają akcje). Nie chodzi mi tutaj o rozwiązanie problemu ciężkich zapytań SQL, ale tylko o przedstawienie problemu. Podczas kiedy wykonuje się akcja, aplikacja nie jest dostępna dla innych użytkowników (dopiero jak akcja się skończy to dopuszcza innych użytkowników). Używam worklinga, żeby odciążyć aplikację z długich metod takich jak generowanie raportów itp. (użytkownik dostaje informację, że raport jest generowany, a gdy zostanie wygenerowany, może go zobaczyć). Są jednak takie akcje, gdzie nie mogę sobie pozwolić na coś takiego, a wynik musi być zwrócony zaraz po załadowaniu strony. Czy jest możliwe, że użytkownik poczeka sobie na wynik, ale nie będzie blokował całej aplikacji? Jest wiele serwisów, gdzie trzeba czekać kilka sekund na wynik, a jednak nie jest blokowana cała aplikacja.
Jeśli dobrze pamiętam tamten wątek to w nim jest także moja odpowiedź na Twój aktualny problem. Musisz albo odpalać kilka procesów mongrela/thina lub (polecane) używać passengera (moduł apache), który domyślnie odpala kilka procesów.
Siedziałem dzisiaj trochę i myślałem nad takim rozwiązaniem, które by nie wymagało wielu instancji serwera. Wymyśliłem pewne rozwiązanie przy użyciu starling/workling (lub innego serwera kolejkowania) i ajaxa. Można zrobić coś takiego.
Tworzymy ajaxowy link. Po jego uruchomieniu nasze zadanie ląduje w serwerze kolejkowania oraz uruchamia ajaxową procedurę “periodically_remote_call”, która to sprawdza co kilka sekund czy jest już wynik z kolejki (możemy użyć memcache), i jeżeli jest to kończy i przenosi użytkonika na stronę z wynikami, lub pokazuje wynik korzystając z ajaxa. Trochę były problemy z zatrzymaniem “periodically_remote_call” ale wszystko działa dość fajnie i najważniejsze nie blokuje aplikacji, a użytkownik otrzymuje informację (ajaxem), że działanie jest w toku.
Bardziej zasobów. W zasadzie to nie bedzie problem w przyszłości, ale teraz aplikacja jest w fazie testów i ma trochę ograniczone możliwości. Po odpaleniu starlinga, worklinga, i mongrela w szczycie pracy dochodzi do 140 mega, czyli max co może na tę chwilę wykorzystywać. Tak naprawdę jeszcze jakiś czas może to chodzić na jednej instancji, ale właśnie brałem się za wspomnianego passengera. Nie bronię się przed wieloma wątkami, ale początkowo myślałem, że rozwiązuje się to jakoś inaczej. Ale przynajmniej się poduczyłem ajaxa. P.S.: Jak by ktoś miał problem jak zatrzymać ‘periodically_remote_call’ to chętnie pomogę bo mi trochę czasu na to zeszło.
Sprawdź passengera + REE, który na prawdę zużywa mniej pamięci. Dodatkowo zadbaj by na serwerze docelowym ilość zainstalowanych gemów była jak najmniejsza - to też wpływa (sic!) na zużycie pamięci. 140MB na proces to dosyć sporo.
bo mi trochę czasu na to zeszło.