2013-08-01 17 views
5

Pracuję nad aplikacją opartą na języku Python (HTTP - REST lub jsonrpc interface), która będzie używana w środowisku zautomatyzowanego testowania produkcji. Spowoduje to połączenie z klientem Java, który uruchamia wszystkie skrypty testowe. Oznacza to brak dostępu do ludzi (z wyjątkiem testowania samej aplikacji).Python bottle vs uwsgi/bottle vs nginx/uwsgi/bottle

Mamy nadzieję rozmieścić to na Raspberry Pi, więc chcę, aby był stosunkowo szybki i ma mały ślad. Prawdopodobnie nie otrzyma ogromnej liczby żądań (przy maksymalnym obciążeniu, może kilku na sekundę), ale powinna być w stanie działać i pozostać stabilna przez długi czas.

Osadziłem się na butelce jako ramce ze względu na jej prostotę (jeden plik). To był tossup przeciwko Flaskowi. Każdy, kto myśli, że Flask może być lepszy, daj mi znać, dlaczego.

Byłem nieco pewności co do stabilności Butelka wbudowany serwer HTTP, więc jestem oceny tych trzech opcji: Tylko

  1. Zastosowanie Bottle - jako serwer http + app
  2. Wykorzystanie Butelka na szczycie uwsgi - Użyj uwsgi jako serwer HTTP
  3. użyj butelki z nginx/uwsgi

pytania:

  • Jeśli nie robię niczego poza Pythonem/uwsgi, czy jest jakikolwiek powód, aby dodać nginx do miksu?
  • Czy połączenie uwsgi/bottle (lub Flask) zostanie uznane za gotowe do produkcji?
  • Czy jest prawdopodobne, że zdobędę cokolwiek, korzystając z oddzielnego serwera HTTP z wbudowanego produktu Bottle?

Odpowiedz

9

Flask vs Bottle sprowadza się do kilku rzeczy dla mnie.

  1. Jak prosta jest aplikacja. Jeśli jest to proste, to butelka jest moim wyborem. Jeśli nie, to mam Flask. Fakt, że butelka jest pojedynczym plikiem, sprawia, że ​​wdrożenie jest niezwykle proste dzięki włączeniu pliku do naszego źródła. Ale fakt, że butelka jest pojedynczym plikiem, powinien być całkiem dobrym wskazaniem, że nie implementuje pełnej specyfikacji WSGI i wszystkich jej przypadków krawędziowych.
  2. Co robi aplikacja. Jeśli będzie to wymagało renderowania czegokolwiek innego niż Python-> JSON, to pójdę z Flaskiem, aby uzyskać wsparcie dla Jinja2. Jeśli potrzebuję uwierzytelnienia i/lub autoryzacji, Flask ma już całkiem niezłe rozszerzenia do obsługi tych wymagań. Jeśli potrzebuję zrobić buforowanie, znowu istnieje Flask-Cache i wykonuje całkiem niezłą pracę przy minimalnej konfiguracji. Nie jestem do końca pewny, co jest dostępne w przypadku rozlewu butelek, więc może być nadal warta obejrzenia.

Problem z używaniem wbudowanego serwera jest taki, że będzie to pojedynczy proces/pojedynczy wątek, co oznacza, że ​​można obsługiwać przetwarzanie tylko jednego żądania naraz.

Aby uporać się z tym ograniczeniem, można wykonać dowolną z następujących czynności w dowolnej kolejności.

  1. Zawinięcie zawinięcia butelki do butelki.app (single threaded, non-blocking I/O, single process)
  2. uwsgi lub gunicorn (ten ostatni jest prostszy), który jest najczęściej instalowany jako pojedynczy gwint, wieloprocesowy (pracownicy)
  3. nginx przed uwsgi.

3 jest najważniejsze, jeśli masz zasoby statyczne, które chcesz obsłużyć, ponieważ możesz bezpośrednio obsługiwać te z nginx.
2 jest naprawdę łatwa do przejścia (szczególnie gunicorn) - mimo że używam uwsgi przez większość czasu, ponieważ ma on większą konfigurowalność do obsługi niektórych rzeczy, które chcę.
1 jest naprawdę prosty i działa dobrze ... a ponadto nie ma żadnych zewnętrznych flag konfiguracji lub linii poleceń.

+0

Świetna odpowiedź! Dzięki. Obecnie moja aplikacja jest skonstruowana w taki sposób, że w razie potrzeby powinna być dość łatwa do zmiany na Flask (lub inne środowisko), więc myślę, że na razie będę trzymać się butelki ... Spędziłem za dużo czasu aby nginx działał/konfigurował przed uwsgi, a do tej pory nie osiągnął żadnego sukcesu. Myślę więc, że wypróbuję zarówno gunicorn, jak i uwsgi przy minimalnej konfiguracji, i wybieram uwsgi tylko wtedy, gdy pokazuje bardzo wyraźną korzyść z wydajności; inaczej gunicorn ze względu na swoją prostotę (wciąż mam dużo czasu, aby to wszystko zmienić). – BobIsNotMyName

+0

Szybka uwaga: okazało się, że nginx nie działał, ponieważ plik gniazda był w/tmp, a to nie działa domyślnie z Fedorą ... Z wyjątkiem tego problemu, nie ma problemu z uzyskaniem którejkolwiek z tych opcji. Pomyśl, że nadal będę trzymać się gunicornu dla łatwości rozmieszczenia. – BobIsNotMyName

+0

Myślę, że pójdę z # 2: uwsgi bez nginx. Nie trzeba komplikować, bo nie sądzę, że moja prosta aplikacja może szybciej korzystać z plików statycznych. –

5

Podobny wybór miałam rok temu - potrzebowałem microframeworku do warstwy serwerowej, którą budowałem. Okazało się, że te slajdy (i towarzyszący mu wykład) są bardzo pomocne w przeglądaniu pola wyboru: Web micro-framework BATTLE!

Wybrałem Butelkę i byłem z niej bardzo zadowolony. Jest prosty, lekki (plus, jeśli wdrażasz na Raspberry Pis), łatwy w użyciu, intuicyjny, ma funkcje, których potrzebuję, i był wyjątkowo rozszerzalny, gdy potrzebowałem dodać własne funkcje. Many plugins są dostępne.

Nie używaj wbudowanego serwera butelkowego HTTP do celów innych niż dev.

Uruchomiłem Butelkę w produkcji z dużym sukcesem; był bardzo stabilny na Apache/mod_wsgi. nginx/uwsgi "powinien" działać podobnie, ale nie mam z tym doświadczenia.

0

Proponuję również, aby spojrzeć na prowadzenie butelki za pośrednictwem serwera gevent.pywsgi. Jest świetny, bardzo prosty w konfiguracji, asynchroniczny i bardzo szybki.

Butelka Plus ma już wbudowany adapter, dzięki czemu jest jeszcze łatwiejsza.

Kocham butelkę, a ta koncepcja, która nie jest przeznaczona dla dużych projektów, jest śmieszna. Jest to jeden z najbardziej wydajnych i dobrze napisanych frameworków, który można łatwo formować bez konieczności ręcznego wykręcania.