WSGI và uWSGi với Nginx [đã đóng]

89

Bất cứ ai có thể vui lòng giải thích ưu / nhược điểm khi sử dụng WSGI VS uWSGI với Nginx.

Hiện tại, tôi đang xây dựng một máy chủ sản xuất cho trang web Django mà tôi đã chuẩn bị nhưng không thể quyết định nên sử dụng WSGI hay uWSGI. Bạn có thể vui lòng giải thích chi tiết những gì phân biệt từng cấu hình? Cấu hình nào nên mở rộng quy mô tốt nhất?

Cảm ơn trước

python  django  nginx  wsgi  uwsgi 
— Fear_matrix
nguồn
Bài đăng trên blog này là một so sánh rất chi tiết về rất nhiều máy chủ Python WSGI, với một bản tóm tắt và một số khuyến nghị ở cuối.
— Lowe Thiderman
Và cũng sử dụng các cấu hình cho một số máy chủ thực sự khó hiểu và khiến chúng có vẻ tệ hơn mức có thể. Người ta phải cẩn thận những gì người ta đọc trong so sánh đó.
— Graham Dumpleton
25
WSGI là một đặc điểm kỹ thuật. uWSGI cung cấp việc triển khai đặc tả WSGI. Bạn không thể so sánh chúng. Bạn chỉ có thể so sánh các triển khai khác nhau.
— Graham Dumpleton

Câu trả lời:

101

Ok, các bạn nhầm lẫn này là do thiếu chi tiết từ một số nguồn và cách đặt tên của các giao thức này và WSGI thực sự là gì.

Tóm lược:

  1. WSGI và uwsgi đều LÀ giao thức, không phải máy chủ. Nó được sử dụng để giao tiếp với các máy chủ web để cân bằng tải và đặc biệt là để tận dụng các tính năng bổ sung mà HTTP thuần túy không thể cung cấp. Cho đến nay Nginx và Cherokee đã triển khai giao thức này.
  2. uWSGI là một máy chủ và một trong những giao thức mà nó triển khai là WSGI (đừng nhầm lẫn giữa giao thức uwsgi với máy chủ uWSGI). WSGI là một đặc tả Python . Có một số triển khai của đặc tả WSGI và nó được dự định sử dụng cho nhiều hơn là máy chủ ứng dụng / máy chủ web, nhưng có khá nhiều máy chủ ứng dụng WSGI (tức là CherryPy, cũng có máy chủ web tuân thủ WSGI sẵn sàng sản xuất , nếu bạn chưa đủ bối rối!).
  3. So sánh uwsgi với WSGI là so sánh cam với táo.
— Derek Litz
nguồn
3
Đánh máy: "1. uwsgi là một giao thức không phải là một máy chủ." -> "1. WSGI là một giao thức không phải là một máy chủ."
— Aman
9
Trên thực tế, những gì tôi đã viết cho 1 là đúng, nhưng đúng là WSGI là một giao thức cũng như uwsgi, vì vậy cả hai câu lệnh bạn đã viết đều đúng :). Tất nhiên, không có phần còn lại của ngữ cảnh 1. Đó là giao thức được sử dụng bởi máy chủ uWSGI. wiki.nginx.org/HttpUwsgiModule , - "Đừng nhầm lẫn giao thức uwsgi với máy chủ uWSGI (nói giao thức uwsgi)"
— Derek Litz
4
À được rồi. Tôi đã nghĩ rằng bạn đang cố gắng vẽ ra một liên kết giữa câu 1. "wsgi là một giao thức .." và 2. "uwsgi là một máy chủ thực thi giao thức".
— Aman
2
@DerekLitz, django chạy trên máy chủ nào khi chúng tôi làm vậy python manage.py runserver?
— Piyush S. Wanare
python manage.py runserverlà một máy chủ nội bộ được tích hợp sẵn cho Django. Nó không phải là apache, nginx, gunicorn hay bất cứ thứ gì khác. django-extensionscung cấp một runserver_pluskhung sử dụng khung Werkzeug, nhưng điều đó gần với một máy chủ nhất runserver.
— Mike DeSimone
32

Nói chung, tốt nhất là chạy Python trong một quy trình riêng biệt từ máy chủ web chính của bạn. Bằng cách đó, máy chủ web có thể có nhiều luồng nhỏ phục vụ nội dung tĩnh thực sự nhanh, trong khi các quy trình Python riêng biệt của bạn sẽ lớn và nặng và mỗi quy trình đang chạy trình thông dịch Python của riêng chúng. Quá đơn giản WSGIlà không tốt, bởi vì nó làm phình ra mọi luồng nginx của bạn với một trình thông dịch Python lớn. Sử dụng fluphoặc gunicornhoặc uWSGIphía sau nginxthì tốt hơn nhiều, vì điều đó giải phóng nginx để đơn giản phân phát nội dung và cho phép bạn chọn số lượng chuỗi nginx nhỏ nhẹ để chạy, không phụ thuộc vào lựa chọn của bạn về số lượng chủ đề Python nặng mà bạn đưa lên để phân phát nội dung động. Mọi người có vẻ rất hài lòng gunicornvào lúc này, nhưng bất kỳ tùy chọn nào trong ba tùy chọn đó đều hoạt động tốt.

Về sau, nó cũng giúp bạn giải phóng Python sang một máy chủ khác khi tải bắt đầu trở nên nghiêm trọng.

— Brandon Rhodes
nguồn
1
Tôi hơi bối rối trước câu trả lời của bạn. Tôi không thể thấy rằng anh ấy đã đề cập đến việc chạy bất kỳ loại triển khai WSGI nào bên trong nginx. Anh ấy đã tham khảo trang wsgi.org chính. Do đó, so sánh ban đầu của anh ấy giữa WSGI và uWSGI là hơi ngớ ngẩn ngay từ đầu vì uWSGI là một triển khai của đặc tả WSGI. Bản thân bạn đã sử dụng thuật ngữ WSGI chung chung một cách khó hiểu khi nói rằng 'nó làm phình ra mọi luồng nginx của bạn bằng một trình thông dịch Python lớn'. Bản thân đặc tả WSGI không thể làm được điều đó, chỉ có triển khai mới có thể.
— Graham Dumpleton
1
Sẽ có ý nghĩa nếu chúng ta so sánh nginx + mod_wsgi (mô-đun có thể cắm được) và nginx + uWSGI (vùng chứa máy chủ ứng dụng).
— clime
Vì vậy, khi nói đến việc sử dụng Nginx để chạy các ứng dụng web Python, vì mod_wsgi của Manlio Perillo là phần mềm chết và không được khuyến nghị, các giải pháp tốt là WSGI với gunicorn hoặc uWSGI, hoặc FastCGI với Flup?
— Gulbahar
19

Tôi tin rằng điều này ngay tại đây http://flask.pocoo.org/docs/deploy/uwsgi/ là một câu trả lời tốt để làm sáng tỏ sự nhầm lẫn. Câu hỏi không hề ngớ ngẩn, xảy ra với bất kỳ ai nhìn thấy hai thuật ngữ và không có thông tin trước về cách mọi thứ hoạt động bên ngoài thế giới mod_PHP (ví dụ: không có gì chống lại php hoặc folks)

Trang web làm tốt việc giải thích bằng các thuật ngữ thực tế những gì cần thiết và sự khác biệt là gì cũng như một ví dụ triển khai tốt cho nginx.

Để thuận tiện, phần giải thích từ Flask wiki được trích dẫn tại đây:

uWSGI là một tùy chọn triển khai trên các máy chủ như nginx, lighttpd và cherokee; xem FastCGI và Vùng chứa WSGI Độc lập để biết các tùy chọn khác. Để sử dụng ứng dụng WSGI của bạn với giao thức uWSGI, trước tiên bạn sẽ cần một máy chủ uWSGI. uWSGI vừa là một giao thức vừa là một máy chủ ứng dụng; máy chủ ứng dụng có thể phục vụ các giao thức uWSGI, FastCGI và HTTP.

Máy chủ uWSGI phổ biến nhất là uwsgi, chúng tôi sẽ sử dụng máy chủ này cho hướng dẫn này. Đảm bảo đã cài đặt nó để làm theo.

— Abhishek Dujari
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.