Nano Hash - криптовалюты, майнинг, программирование

Не могли бы вы более подробно объяснить различия между mod_wsgi и werkzeug? (SOS новички)

Как я уже сказал в заголовке, в настоящее время я чувствую себя довольно некомфортно в их базовом понимании.

Насколько я знаю, mod_wsgi реализует спецификацию WSGI, которую можно запускать под веб-сервером Apache.

Он был закодирован на языке Си.

Еще один, werkzeug — это своего рода набор инструментов, в котором есть полезные утилиты. Я также рассмотрел, что werkzeug может запускать простой сервис, который реализован в его исходных кодах (make_server в serve.py). Я знаю, что у werkzeug есть полезные функции и простая серверная функция.

Что я хочу знать это ниже.

Что именно делает mod_wsgi при использовании инфраструктуры, подобной Flask, на основе werkzeug под веб-сервером Apache?

werkzeug также имеет базовые функции http-сервера, которые не нуждаются в поддержке mod_wsgi.

Кто-нибудь может объяснить разницу между mod_wsgi и werkzeug?

mod_wsgi и werkzeug дублируют функции с точки зрения веб-сервера.


  • Django не основан на werkzeug, вы имеете в виду Flask? 02.10.2012
  • О, извините, не хватает моих знаний. Любой фреймворк на основе werkzeug. Флакон тоже. Я буду редактировать. Благодарность 02.10.2012
  • Я думаю, что, как и django, они рекомендуют использовать runserver или что-то еще только в среде разработки, а не в производственной среде... на большинстве хостов вы не можете запускать длительные процессы, поэтому вы используете mod_wsgi или пассажира для размещения 02.10.2012

Ответы:


1

WSGI означает интерфейс шлюза веб-сервера, (в основном) определенный PEP 333 по адресу http://www.python.org/dev/peps/pep-0333/ .

Сообщество Python пытается создать стандартный механизм взаимодействия веб-серверов с приложениями Python.

Теоретически любой совместимый с wsgi сервер (или расширение существующего веб-сервера) должен иметь возможность загружать и запускать любое совместимое с wsgi приложение.

werkzeug – это инфраструктура веб-приложений, которая может работать на совместимом с WSGI сервере, таком как Apache+mod_wsgi. Он также содержит встроенный сервер разработки, который вы можете использовать для разработки.


Поначалу WSGI может быть очень запутанным, но на самом деле он довольно прост. Спецификация WSGI требует, чтобы ваше приложение Python выполняло следующие действия:

  1. определить вызываемый объект с именем application
  2. указанный вызываемый объект должен принимать 2 параметра: (environ, start_response)
  3. environ — это словарь переменных окружения.
  4. start_response - это вызываемый объект, который необходимо вызвать, чтобы начать ответ

После вызова application он обрабатывает запрос, формирует вывод и:

  1. звонит start_response('200 OK', Headers)
  2. return [content]

Простое приложение WSGI может выглядеть так:

def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'

    response_headers = [('Content-type', 'text/plain'),
                    ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]

Настоятельно рекомендуется использовать существующую инфраструктуру WSGI, так как существует множество деталей, связанных с разбором HTTP-запросов, обработкой загрузки файлов, кодированием символов и т. д.

Взгляните на Bottle, Flask, werkzeug, AppStruct и т. д.

02.10.2012
  • Спасибо за ваше подробное объяснение. Я могу нарисовать основные понятия. Я попытаюсь погрузиться во фреймворки. 02.10.2012
  • Итак, werkzeug — эталонная реализация WSGI? 24.12.2016

  • 2

    mod_wsgi — это модуль Python, совместимый с wsgi, который объединяет Python и Apache. он позволяет запускать приложения, закодированные в соответствии со спецификацией wsgi, под apache.

    werkzeug — это служебная библиотека wsgi, используемая для создания приложений, совместимых с wsgi. он поставляется с сервером разработки.

    существует несколько фреймворков веб-приложений Python: Pyramid/Pylons, Flask, Bottle, Django, CherryPy и т. д. Все они реализуют спецификацию WSGI, которая является стандартом де-факто для создания веб-приложений на Python ( http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface )

    Большинство фреймворков веб-приложений поставляются с веб-сервером, предназначенным только для отладки или для работы в рабочей среде. Когда у вас есть приложение WSGI, вы можете обслуживать через приложение библиотеки, через Apache через mod_wsgi или с помощью «чистого» сервера wsgi, такого как uWSGI, gunicorn, fapws или twisted.

    Большинство людей, которых я знаю, развертывают приложение wsgi следующим образом:

    • легкий сервер, например nginx, слушает порт 80
    • облегченный сервер сам обслуживает статические файлы
    • облегченный сервер проксирует запросы uWSGI на другой сервер, который часто является uWSGI, но иногда apache + mod_wsgi или другим. в зависимости от настройки прокси-сервер может быть либо HTTP-прокси, либо подключением к серверу uWSGI напрямую или через сокет.

    при этом, чтобы конкретно ответить на ваш вопрос, прочитайте первый абзац этой страницы документации - http://werkzeug.pocoo.org/docs/serving/ :

    Есть много способов обслуживать приложение WSGI. Пока вы его разрабатываете, вы обычно не хотите иметь полноценный веб-сервер, такой как Apache, и работать, а вместо этого иметь простой автономный сервер. Поэтому Werkzeug поставляется со встроенным сервером разработки.

    По причинам разработки или на сайте с очень низким трафиком вы можете просто использовать сервер Werkzeug. Если вы развертываете приложение, которое будет получать разумный объем трафика, вам понадобится что-то более надежное.

    mod_wsgi или uWSGI дублируют функции обслуживания Werkzeug , но они делают это, потому что могут делать это значительно лучше - более быстрое время отклика, меньший объем памяти, лучший параллелизм, более стабильный и т. д. и т. д. сервер Werkzeug «достаточно хорош» для многих применений. , но это не «лучший способ» обслуживать приложение, совместимое с wsgi.

    02.10.2012
  • Немного путаницы с uWSGI здесь. Пакет называется uWSGI (исправлено). Внутренний протокол, который uWSGI использует для связи между веб-сервером (nginx или Apache), называется uwsgi (нижний регистр). Хотя в названии протокола есть «wsgi», на самом деле он не имеет ничего общего со спецификацией WSGI и на самом деле является проводным протоколом, очень похожим на протокол SCGI. Кроме того, uWSGI даже не является «чистым» сервером WSGI. На самом деле вы используете плагин Python для uWSGI, где пакет uWSGI фактически поддерживает другие языки, используя адаптеры, отличные от WSGI. Плохой выбор имен со всех сторон. 02.10.2012
  • +1 ко всему, что сказал Грэм. Извините, если я создал некоторую путаницу по этому поводу - непреднамеренно. 02.10.2012
  • Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..