Który z Warp i przystawki serwera Yesod powinienem wybrać dla wydajnego serwera aplikacji?

Question

Widziałem testy porównawcze na stronie domowej Yesod, ale są to głównie pliki statyczne. Testy porównawcze na stronie Snap są nieaktualne.

Próbuję odsłonić moduł Haskella jako usługę. Logika serwera polega na otrzymaniu nazwy funkcji i argumentów w json, wywołania funkcji haskell i dostarczenia jej ponownie jako json. Przejrzysta przezroczystość gwarantuje bezpieczeństwo wątków oraz możliwość pamiętania i buforowania funkcji.

Jeśli miałbym obsługiwać równoczesne połączenia w zakresie 2k - 5k, jak mam go wdrożyć? Jak skalowalne może być to podejście?

Answer 1

Zdecydowanie polecam wybór pomiędzy Warp/Yesod i Snap w zależności od tego, który system oferuje najlepszy zestaw narzędzi do tworzenia aplikacji. Zarówno Warp jak i Snap używają tego samego podstawowego menedżera we/wy GHC i oba są wysoce zoptymalizowane. Byłbym zaskoczony, gdyby dobrze napisana aplikacja dla każdego systemu, robiąc coś niebanalnego, pokazała lukę w wydajności istotności.

Twój ostatni akapit jest trochę niejasny, ale myślę, że podstawową odpowiedzią dla Warp lub Snap jest napisanie kodu, a menedżer I/O skaluje się tak dobrze, jak to możliwe. Jeśli naprawdę znajdziesz równoległe połączenia, które mogą być wąskim gardłem, możesz rozważyć wypróbowanie techniki preforków, używając GHC 7.8 (jeszcze nie wydany, ale ma znacznie poprawiony menedżer I/O) lub używając wielu serwerów.

Answer 2

Większość benchmarków opublikowanych dla Warp i Snap opiera się na niezwykle prostym i bardzo wymyślnym benchmarku, który zwraca statyczny ciąg "ponga". Jest to świetne rozwiązanie do testowania wydajności serwera WWW podczas analizowania żądań HTTP, konstruowania odpowiedzi HTTP itd., Ale w większości aplikacji czas spędzony na robieniu takich danych będzie znikomy. Po drugie, przypuszczam, że wszelkie różnice w wydajności pomiędzy Warp i Snap mogą teraz w przyszłości ulec zmniejszeniu, ponieważ oba serwery nadal poprawiają się i zbliżają do teoretycznego limitu. Oczekuję również, że oba serwery również skorzystają znacząco z poprawy wydajności w GHC 7.8.

Haskell to doskonały wybór dla uzyskania wysokiej wydajności przy dużej liczbie równoczesnych połączeń. Haskell ma zielone nici, które są niezwykle tanie w porównaniu do wątków w większości innych języków. Dzięki temu struktury sieciowe Haskell mają ogromną przewagę. Możemy odpalić nowy wątek dla każdego połączenia i wykorzystać ogromną ilość wysiłku, który podjął się optymalizacji GHC, aby uzyskać świetną wydajność przy jednoczesnym zachowaniu ładnego modelu programowania.

Jeśli chodzi o Yesod vs Snap, istnieje powód, że oba istnieją jako oddzielne projekty. Zbliżają się do problemu tworzenia stron internetowych w Haskell z dwóch zupełnie różnych kierunków. Obaj odniosą korzyść z wydajności, którą dostaje Haskell, więc powinieneś wybierać między nimi na podstawie preferowanego podejścia. Oto kilka zasobów, które pomogą Ci zacząć:

• A StackOverflow question with some pretty good answers
• My very generalized comparison matrix
• A more detailed and objective comparison I wrote
• Haskell wiki page comparing web frameworks