Всех приветствую форумчане, никак не могу решить вопрос с подключением к апачу, все линки в гугле старые за 2009 год и статьи для пайтона второй ветки, а мне нужно для третьей. С postgres проблем особых не было, скачал модуль, инсталлировал его и свободно с ним работаю. Подскажите пожалуйста куда смотреть по настройке апача для взаимодействия с пайтон.
Заранее благодарен, тем кто подскажет по вопросу.
Ось - шиндовс 7, апач - 2.2, пайтон 3.4.1.
Полная версия: Проблемы с apache.
А вам зачем именно к апачу? Сейчас в основном используют сервера на питоне, типа waitress или утилит из werkzeug, или что идет с фреймворком из коробки и т.п. потому что с ними легко отлаживаться, а в продашене их ставят за обратным прокси, чаще всего за нгинкс.
Насколько werkzeug лучше apache по производительности и вообще, не модуль ли это для апачи? Если можете, популярно, пожалуйста, так как сейчас перед выбором стою.
PooH
А вам зачем именно к апачу? Сейчас в основном используют сервера на питоне, типа waitress или утилит из werkzeug, или что идет с фреймворком из коробки и т.п. потому что с ними легко отлаживаться, а в продашене их ставят за обратным прокси, чаще всего за нгинкс.
Мне не для фреймворков, нужно тестировать простые скрипты на пайтоне через броузер.
Вообщем есть простой бложек написанный на коленке мною на PHP, сейчас его начал переписывать на пайтоне. Так вот нужен доступ к броузеру.
Заранее благодарен.
capable
Вообщем есть простой бложек написанный на коленке мною на PHP, сейчас его начал переписывать на пайтоне. Так вот нужен доступ к броузеру.
Возьми любой фреймворк или сервер из стандартной либы.
Узнай, что такое WSGI.
Budulianin
Не нужен мне пока что фреймворк.
Нужно настроить апач.
Не нужен мне пока что фреймворк.
Нужно настроить апач.
Isem
Насколько werkzeug лучше apache по производительности и вообще, не модуль ли это для апачи? Если можете, популярно, пожалуйста, так как сейчас перед выбором стою.
Ух, все это разжевано в интернете, но попробую собрать в одно. Если где ошибся, пусть меня поправят. Смотрите, в простейшем варианте система у нас состоит из двух частей - веб-сервер и приложение на python, веб-сервер обрабатывает подключения, вызывает приложение и отдает все это клиенту, еще веб-сервер сам отдает статику.
С приложением веб-сервер может общаться следующими способами(вообще их больше):
- CGI - сервер сохраняет входные данные запроса в переменных среды и вызывает интерпретатор python с приложением(данные POST передаются через stdin). Приложение пишет в stdout, который сервер перехватывает и отдает клиенту;
- Встроенный интерпретатор в сервере(для apache mod_python) - здесь веб-сервер загружает интерпретатор python в память своего процесса и выполняет приложение в нем, тут, благо они в одном адресном пространстве, масса вариантов обмена данными между приложением и веб-сервером, подробности в доке на mod_python, фактически можно навесить обработчик на любой этап обработки запроса веб-сервером;
- FastCGI - здесь приложение запущено отдельным долгоживущим процессом, который общается с веб-сервером через unix/tcp-сокет(в одном из вариантов через stdin/stdout) по определенному протоколу;
- WSGI - тоже что и в предыдущем случае, но протокол другой, более близкий питону - любой callable объект, принимает словарь с данными, генерирует строки ответа;
В двух последних случаях, чтобы не писать все общение с веб-сервером самому используют готовые сервера приложений flup, uWSGI, gunicorn. Причем то-же flup, например, может ваше приложение дергать через WSGI, а с веб-сервером уже общаться через FastCGI.
Отдельно стоит mod_wsgi, это модуль для apache, который вызывает ваше приложение через WSGI, но запускает его либо внутри процесса apache как mod_python, либо в отдельном процессе, опять же под управлением apache.
Что касается werkzeug, то он унифицирует для вас работу с веб-сервером, через что бы вы не запускали приложение, для вас это будет WSGI. И плюс дает вам простенький веб-сервер на python для разработки без кучи настроек. Так, что, как видите, сравнивать werkzeug и apache бессмысленно.
Теперь про nginx и apache. У них разная модель обработки подключений apache обрабатывает каждое подключение в отдельном потоке, nginx - использует очередь сообщений - один поток(на самом деле несколько, но это не важно) опрашивает подключения по очереди. Поэтому nginx может обслужить намного больше клиентов, но не любит длительные обработки. Его часто используют в качестве обратного прокси и балансировщика нагрузки - обрабатывает запросы клиентов, статику отдает сам, а долгие запросы отдает за себя, другому серверу. Это может быть, конечно, и apache. Но смотрите, nginx сейчас умеет понимать и FastCGI и WSGI, и если мы отдельно поднимаем сервер приложений на том же uWSGI, то зачем нам лишнее промежуточное звено в лице apache? Это лишняя задержка, это потраченная память.
Ну вот как-то так. На самом деле вариантов, конечно, больше.
ЗЫ: Про производительность, пока писал наткнулся на интересную заметку автора mod_python , особенно комменты
sypper-pit
Так есть же http://modpython.org
WAT? sypper-pit, Вы откуда такой умный здесь взялись? С разморозкой Вас.
mod_python уже несколько лет как устарел и его не рекомендуется использовать.
capable, опишите подробно задачу, тогда будет проще Вам помочь. Возможно у вас типичная ошибка всех PHP разработчиков, которые начинают разработку Python проекта с настройки apache. Хотя этого в общем-то не нужно до определенного момента.