7
Oceniamy kilka opcji rozwoju platformy aplikacji związanej z telekomunikacją (i migracji/konsolidacji niektórych autonomicznych aplikacji na nową platformę). Jednym z naszych głównych problemów jest możliwość obsługi dużej liczby żądań w godzinach szczytu.JRuby/TorqueBox dla aplikacji o wysokiej wydajności/znaczeniu krytycznym
czujemy TorqueBox wydaje się ciekawe rozwiązanie, które zasługują na uwagę, ponieważ:
- Prędkość (Obok czystej wydajności Java)
- Krótszy czas rozwoju na Javie
- utrzymywalności
- Wsparcie dla wątków/Współbieżność, nawet jeśli jest to Ruby
- Szybsze/Łatwiejsze projektowanie frontów z Railsami
- ...
- RedHat obsługiwane i działa na JBoss (skalowalność, przyszłego rozwoju i zdolność do wywołania Java jeśli to konieczne)
- ktoś opracowanej/wdrożonej podobnej aplikacji (ów) z JRuby/TorqueBox?
- Jakieś poważne wąskie gardła wydajności? (lub dlaczego nie powinniśmy używać JRuby i powinniśmy trzymać się Javy?)
Z tego co ja zebrane od wzorców i IRC: jruby/Torquebox mogą i obsługiwać duże obciążenia całkiem dobrze. Być może opracowujemy aplikację PoC za pomocą Celluloid.IO (dla współbieżności) + TorqueBox i testujemy, jak będzie się to odbywać z aplikacją referencyjną Java. Zaktualizuje statystyki obciążenia, jeśli zdecydujemy się na stworzenie aplikacji JRuby PoC. – bud
Połączenie celuloidu: io z Torqueboxem wydawało się przesadą przynajmniej dla naszych wymagań i skończyliśmy z wykorzystaniem wbudowanych funkcjonalności kolejki TB i te działają bez problemów. Jedną z rzeczy, na które należy zwrócić uwagę, jest to, że zauważyliśmy, że tryb programowania w trakcie pracy dawał błędy z limitami pamięci jboss. Wdrożenie aplikacji w trybie produkcyjnym usunęło je. – bud