Zauważyliśmy wzrost ruchu na Shelly Cloud pochodzący z forum dlatego doszliśmy do wniosku, że założymy tutaj osobny wątek dotyczący zmian oraz nowości jakie wprowadzamy. Oprócz tego zawsze możecie śledzić nas na Twitterze - @shellycloudhttps://twitter.com/shellycloud lub na blogu http://blog.shellycloud.com .
Dla przypomnienia - Shelly Cloud to PaaS. Chmury hostowane u nas mają oddzielną przestrzeń dyskową, zarówno dla plików jak i baz danych. Serwery konfigurowane są za pomocą pliku “Cloudfile”, który umieszczony jest wraz z całą aplikacją w repozytorium i to developer ustala jakie usługi mają być uruchomione na poszczególnych serwerach. W tym momencie z baz danych wspieramy: PostgreSQL, MongoDB (+ możliwość utworzenia repliki), Redisa, natomiast z innych usług: dostosowywanie ilości thinów, workerów delayed job, whenever, elasticsearch, websockety. Deployment robiony jest przez gita.
Chmurę można przetestować. Przy pierwszej aplikacji dajemy €20 za darmo, co wystarcza na około miesiąc hostingu przy najsłabszej konfiguracji (jeden mały serwer 1GB RAM) lub dwa tygodnie w przypadku jednego dużego serwera (2GB RAM), więcej szczegółów można znaleźć w pricingu - http://shellycloud.com/pricing .
Z ostatnich rzeczy które dodaliśmy to wsparcie dla Elasticsearcha na serwerach oraz Organizacje do łatwiejszego zarządzania wieloma chmurami (jedna faktura, a w przyszłości jedna płatność kartą kredytową, usprawnione zarządzanie użytkownikami, nowy dashboard).
W tym momencie skupiamy się na obsłudze płatności kartami, czytelniejszym dostępie do logów i przyspieszeniu deploymentu.
Chętnie odpowiemy na wszelkie pytania i wysłuchamy sugestii.
Znamy Thina i używamy go w wielu projektach stworzonych w Ragnarsonie. Jest szybki, ma wydajny, bezpieczny i zgodny z RFC parser HTTP, nie ma problemów z instalacją i jest stabilny.
Na przykład jako upload progress: https://github.com/slawosz/upload_progress
Jest to o tyle fajne, że możesz się podpiąć w każdym miejscu przetwarzanego request-u, przez co możesz zrobić wszystko co chcesz (Rack jest dostępny już po przetworzeniu całego requestu).
Zatem wygląda, ze kierowaliście się “przezwyczajeniem” i doświadczeniem z tą konkretnie technologią(Thin)? Ciekawi mnie dlaczego nie był to Unicorn bądź np. Puma i czy w ogóle był taki wybór rozważany?
Oczekiwałem odpowiedzi bardziej w stylu: “Uzywamy Thin, gdyz przy uruchomieniu wielu instancji, oszczędzamy RAM w porównaniu z takim samym setupem na Unicorn” albo “Uzywamy bo na Herku tez zalecają”
Doświadczenie z daną technologią to bardzo dobry argument, zwłaszcza dla firmy hostingowej (gdzie ma działać, a jak nie działa to ludzie którzy zjedli zęby na każdym z elementów stosu naprawią w ciągu minut).
[quote=mkacz]Zatem wygląda, ze kierowaliście się “przezwyczajeniem” i doświadczeniem z tą konkretnie technologią(Thin)? Ciekawi mnie dlaczego nie był to Unicorn bądź np. Puma i czy w ogóle był taki wybór rozważany?
Oczekiwałem odpowiedzi bardziej w stylu: “Uzywamy Thin, gdyz przy uruchomieniu wielu instancji, oszczędzamy RAM w porównaniu z takim samym setupem na Unicorn” albo “Uzywamy bo na Herku tez zalecają” :)[/quote]
Oprócz powodów o których wspomniał Bragi, nie wybraliśmy Unicorna ze względu na jego architekturę.
Przy korzystaniu z haproxy mielibyśmy podwójny load balancing: haproxy -> unicorn master (jeden na instancje) -> workery unicorna (wiele na każdej instancji). Mogłoby to powodować, że aplikacja, która chodzi na kilku serwerach oraz ma “ciężkie” i “lekkie” requesty, to część jej instancji byłaby bardziej obciążona niż pozostałe. Co ważne, mamy ustawione max 1 połączenie na thinach, więc requesty nie czekają na nich, tylko na haproxy, bo Railsy i tak nie są w stanie obsłużyć 2 requestów na raz.
W ciągu najbliższych dni dodamy lepszy opis architektury Shelly Cloud do naszej dokumentacji.
btw. Akutalnie pracujemy nad udostępnieniem JRuby na instancjach, do którego będziemy używać Pumy.
Chciałbym to sprostować, to zdanie będzie bliższe prawdzie jak dodasz “bo Railsy na thinie i tak nie są w stanie obsłużyć 2 requestów na raz”. Na innych serwerach (np. puma) nie ma takiego problemu. Wiem, że pewnie to wiesz ;), ale niestety ruby w świecie ma opinię języka, w którym wątków najlepiej nie użyać, co jest kiepskie dla rozwoju języka i nie chciałbym tego pogłębiać.
Niekoniecznie. 1.9 ma co prawda GIL, więc efekty będą tam gorsze niż na implementacjach, które już się GILa pozbyły, ale wszystko zależy od aplikacji jaką tworzysz. Jeżeli jeden wątek czeka na I/O, to drugi może działać, więc aplikacje webowe powinny skorzystać z wielowątkowości nawet na MRI - z reguły dużą część czasu zajmują zapytania do bazy. W przypadku wątpliwości najlepiej przetestować konkretny przypadek.
<cool story, bro>
To mi pzypomniało jak raz dyskutowałem gdzieś w internetach z jednym PHPowcem pracującym również na projektach railsowych, który pisał o tym, że Ruby jest kiepski, bo ma GIL i będzie wolniejszy niż PHP w przypadku użycia wątków i że w railsach nie można uruchomić dodatkowego wątku nigdzie, bo nie są thread safe i stek innych bzdur. Jako dowód tego, że PHP będzie szybszy pokazał benchmark, który używał implementacji wątków w PHP opartej o posixowy fork O_o
To mi pzypomniało jak raz dyskutowałem gdzieś w internetach z jednym PHPowcem pracującym również na projektach railsowych, który pisał o tym, że Ruby jest kiepski, bo ma GIL i będzie wolniejszy niż PHP w przypadku użycia wątków i że w railsach nie można uruchomić dodatkowego wątku nigdzie, bo nie są thread safe i stek innych bzdur. Jako dowód tego, że PHP będzie szybszy pokazał benchmark, który używał implementacji wątków w PHP opartej o posixowy fork O_o
</cool story, bro>[/quote]
Jedynym sposobem, żeby w PHP zrobić wielowątkowe odpytywanie zewnętrznych API to użyć libcurl. Jednak libcurl służy tylko do zrobienia requestu HTTP. Ponieważ każde API ma inną semantykę więc uzyskane stamtąd wyniki trzeba obrobić. Trudno to zrobić po tym jak libcurl wykona swoją robotę - bo dostajesz wtedy tablicę różnych wyników z różnych API z różną semantyką.
Rozwiązaniem tego problemu jest callback do własnej aplikacji pod URL który dostarcza wspólny wrapper dla różnych API. Wygląda to tak: przychodzi zapytanie do aplikacji i odpalany jest proces PHP, żeby je obsłużyć. Ten proces uruchamia libcurl z callbackiem do aplikacji na każde API. Każdy callback odpala kolejny proces PHP i uruchamia libcurl, żeby się dobić do serwisu trzeciego.
Jeśli obsługujesz 5 różnych API to masz w sumie 6 procesów na raz na jedno zapytanie z przeglądarki. A teraz wyobraź sobie, że niektóre API idą po SSL via SOAP, którego implementacja w PHP nie honoruje timeout. Kiedy zewnętrzny serwis nie odpowiada to całość sobie ślicznie wisi przez Bóg wie ile.
I dlatego aplikacja PHP działa na 20 serwerach a aplikacja Ruby, która (obsługuje dla tej z PHP cały ruch z referali) - na dwóch instancjach na Shelly.
Porównywanie rozwiązań opartych o “surowy” hardware z tymi opartymi o EC2 to trochę kopanie szczeniaczka
Znaczy, nie jestem ani trochę zaskoczony tym, że Shelly Cloud jest o wiele bardziej wydajne.
[1] Tak, wiem że Shelly to też wirtualizacja, ale “bliżej” sprzętu niż EC2.
Jak dla mnie to bardziej łaskotanie 800 funtowego goryla
Problem z porównywaniem do Heroku jest taki, że ciężko pokazać że mamy gigantyczną przewagę w łatwości pisania pod Shelly w porównaniu z Heroku. No ale nie o tym był post, tylko o szybkości.
Musimy jeszcze przygotować kolejny post, tym razem o supporcie. Dla klientów to nadal jest jeden z najważniejszych punktów.
@phocke wymaga to przynajmniej dwóch serwerów aplikacyjnych, każdy z thinami/puma tak aby w czasie deploymentu jeden obsługiwał requesty. Jestem na Camfire jeżeli potrzebujesz więcej info.
