LINUX.ORG.RU

Аналог режима PHP для Python/Ruby


0

2

Знаю, на ЛОРе не любят PHP (я собственно его тоже не люблю), но у него есть классная фишка - отсутсвие необходимости перезагружать сервер. То есть отредактированный файл тут же подхватывается - никакой задержки ни при разработке, ни пре деплоее.

Вообще лучше всего из скриптовых языков я знаю Python, но вообще можно и Ruby - есть ли для них такой же механизм работы?

Я сейчас использую bottle.py - у него есть ощутимая (хотя и не долгая) задержка при перезагрузке сервера. Может у других фреймворков с этим лучше?

★★★

Ответ на: комментарий от xpahos

Эта хрень, как я понял, апач рестартит. Это уже совсем жестоко - лучше уж как в bottle.py - только питон перезагружать, но это все равно не то - т.к. есть пауза (для меня ощутимая) пока сервер недоступен.

theos ★★★ ()
Ответ на: комментарий от theos

То есть bottle.py сам детектит изменения в py файлах и рестартится - но в этом случаи есть задержка. А хочется, чтобы никакой задержки не было - чтобы все приходящие реквесты сервились бы старым кодом пока новый полноценно не загрузится, и только после полной загрузки новый код начинал бы сервить новые реквесты. Ну и время загрузки конечно хочет меньше секунды.

theos ★★★ ()
Ответ на: комментарий от xpahos

Да дело не в хуках к системе контроля версии, я вот хочу это, в частности, у себя на девелоперской версии - просто что бы сразу видеть изменения которые я сделал. Хуки то поставить дело не сложное, а в том что бы не было задержки между изменением файла - подхватыванием этого изменения сервером.

theos ★★★ ()

погугли как-то так - fcgi gracefully restart

Bers ()
Ответ на: комментарий от theos

ну у Django/Pylons standalone сервер быстро перезапускается. Хотя я в Eclipse не использую ничего из этого. Сначала контроллер пишу, потом вьюв делаю, а потом только перегружаю и тестю.

xpahos ★★★★★ ()
Ответ на: комментарий от xpahos

Django/Pylons standalone сервер быстро перезапускается.

У меня где-то секунд 4, для меня это долго, особенно когдя я штото фикшу, тут же переключасюь проверить и получаю «сервер не доступен».

theos ★★★ ()
Ответ на: комментарий от theos

кстати, прикинь, на с вообще компилировать надо. всеж в базовой идее пхп рулит...

trashymichael ★★★ ()
Ответ на: комментарий от trashymichael

кстати, прикинь, на с вообще компилировать надо. всеж в базовой идее пхп рулит...

Я вообще-то java-разработчек (перешел с С++), так что компилировать обучен. И On-the-fly изменения кода в джаве таки в ограниченных случаях работает. Но для скриптовых язычков с говнодинамической типизацией шаг перезапуска вполне можно избежать (что и показывает PHP).

theos ★★★ ()
Ответ на: комментарий от Anatolik

http://rubygems.org/gems/shotgun

Спавнить дочерний процесс на запрос (как я понял) - это прикольно конечно %) Ты юзал - как оно в смысле производительности?

theos ★★★ ()
Ответ на: комментарий от theos

ты путаешь мухи и котлеты. представь что пхп это такой парсер который из одного текста делает другой.

ок, представь другую ситуацию. ты запускаешь пхп скрипт и сервер тоже на пхп написан, что дальше?

trashymichael ★★★ ()
Ответ на: комментарий от trashymichael

ты путаешь мухи и котлеты.

Я хочу конкретное поведение, которое повысит мою скорость разработку и облегчит безболезненные деплои.

представь что пхп это такой парсер который из одного текста делает другой

Что за поток сознания? Парсер - точно ниакакого текста не далет ;)

ок, представь другую ситуацию

Прдеставил, и?

Если что, я знаю как в php достигается этот эффект. Его можно запилить и в питоне, благо reload модулей там есть, просто я надеялся что не надо будет велосипедствовать, а можно взять конкретный фреймворк.

theos ★★★ ()
Ответ на: комментарий от theos

когда у тебя джанга в дев режиме она тоже перезапускается, да она запускается дольше чем index.php, такова реальность. у меня на виртуалке с 512 оперативки это занимает чуть-чуть больше времени чем alt-tab из редактора в браузер, и то не всегда

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

trashymichael ★★★ ()

Ты забываешь сразу про нескольку вещей:

1) Быстрый «рестарт» PHP связан с моделью выполнения — на каждый реквест, всё (всё!) окружение подымается заного. Настройка роутов, парсинг конфигов и т.д и т.д. Это лютый оверхед.

2) В сложных системах это сильная головная боль. Возникают гонки при деплое. То есть, в течение реквеста, может выполнятся как старый код, так и новый.

Как ни крути, PHP говно.

baverman ★★★ ()
Ответ на: комментарий от theos

Спавнить дочерний процесс на запрос (как я понял) - это прикольно конечно %) Ты юзал - как оно в смысле производительности?

Только в development'e. На глаз — быстро. Помимо shotgun, для Ruby еще есть https://github.com/sinatra/sinatra-contrib/blob/master/lib/sinatra/reloader.rb

Для деплоя, может быть, подойдет https://github.com/trinidad/trinidad

Anatolik ★★ ()

«Аналог режима PHP» - это «mod_python».

Оно работает по тому же принципу, т.е. не требует перезапуска сервера. Иные называют это «горячей заменой кода». Глупцы.

Скажу вам честно, не таясь - зря вы считаете это «классной фишкой»! Сервера приложений, даже такие поганые как uwsgi, нужны и полезны в нашем нелегком деле. Советаю вам пересмотреть свое к ним отношение и таки запилить скрипт-другой автоматической перегрузки сервера, быть может, даже без «простоев».

А, впрочем, вам это решать. Я ни на что не намекаю. Даже на то, что в Common Lisp`e проблем таких нет и быть не может.

anonymous ()
Ответ на: комментарий от anonymous

это же для разработки нужно, а не для продакшена

stevejobs ★★★☆☆ ()

автор, переходи на жабу, у нас так половина всего делать умеет =)

stevejobs ★★★☆☆ ()
Ответ на: комментарий от trashymichael

представь другую ситуацию. ты запускаешь пхп скрипт и сервер тоже на пхп написан, что дальше?

У меня есть сервер (понятно, что не HTTP :) ) на PHP. Каждый запрос порождает форк. Так вот, если меняешь PHP-файлы, то в форке работают уже изменённые файлы :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от stevejobs

юзай наш Live Reload

Да, у меня мак. Это не непосредественно по моей проблеме, но штука вроде прикольная, посмотрю.

автор, переходи на жабу, у нас так половина всего делать умеет =)

Да не, я как раз с жабы, горячая перезагрузка там работает только если не меняется структура класса: добавление нового метода требует таки перезагрузки.

theos ★★★ ()
Ответ на: комментарий от anonymous

Даже на то, что в Common Lisp`e проблем таких нет и быть не может.

В коммон лиспе такая штука реализуется также как и в питоне - ручками. Там же не только в перезагрузке дело, но и в готовой либе пулов соденений со всякими БД, удобная схема хранения состояния и т.д.

theos ★★★ ()
Ответ на: комментарий от baverman

всё (всё!) окружение подымается заного. Настройка роутов, парсинг конфигов и т.д и т.д. Это лютый оверхед.

Не специалист по PHP, но вообще у него с оптимизацией вроде все хорошо, а конфиги принято хранитьт у них в виде .PHP файлов - парсить нечего.

theos ★★★ ()
Ответ на: комментарий от theos

конфиги принято хранитьт у них в виде .PHP файлов - парсить нечего.

Хм. А ты точно «обучен компилировать»?

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Хм. А ты точно «обучен компилировать»?

У меня большая ненависть к динамической типизации, так что да, обучен.

Аа, я просто не дописал «принято хранить _в PHP_» (а не вообще так принято) - по карйней мере именно такую схему я обычно наблюдал, когда ставил что-нибудь написанное на PHP.

theos ★★★ ()
Ответ на: комментарий от theos

Хм. А ты точно «обучен компилировать»?

У меня большая ненависть к динамической типизации, так что да, обучен.

Причем здесь динамическая типизация? Динамические языки тоже компилируются.

я просто не дописал «принято хранить _в PHP_» (а не вообще так принято)

Я понял. Но даже если конфиг написан на PHP, его всё равно нужно парсить (и компилировать).

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Причем здесь динамическая типизация? Динамические языки тоже компилируются.

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

Но даже если конфиг написан на PHP, его всё равно нужно парсить (и компилировать).

Насколько я понял, PHP таки кэширует скомпилированный код, но с полной уверенностью не скажу.

theos ★★★ ()

AFAIK, нет такого.

Любое изменение в коде требует рестарта приложения, что можно автоматизировать. В случае с девелопментом, могу посоветовать Django, его девелопмент-сервак очень шустро рестартится, в продакшене в любом случае придется перезапускать аппликэйшн-сервер (апач, торнадо etc.)

NOX ()
Ответ на: комментарий от dotcoder

В продакшне, конечно же, не рекомендуется.

В боттле тоже такое есть, только вот оно ограничено шаблонами. Если хочется попровить опечатку в исходнике - перезапуск. Но я видимо смирюсь :)

theos ★★★ ()
Ответ на: комментарий от NOX

рестарта приложения, что можно автоматизировать.

Рестарт то автоматизирован, только оне у меня недостаточно быстрый. Я специально код инициализации и небосредственно обработки разделил по разным py файлам, можно будет попробовать написать ручками релоадер который сам сервер не перезапускает, а только модуль релоадид.

theos ★★★ ()
Ответ на: комментарий от theos

А, если изменения ограничиваются шаблонами, то tornado тоже такое умеет и джанго, кажется, тоже.

// offtopic А PHP всё-таки помедленней Ruby будет (Twitter под RoR костыли не пишет, в отличие от Facebook) =)

NOX ()
Ответ на: комментарий от theos

> можно будет попробовать написать ручками релоадер который сам сервер не перезапускает, а только модуль релоадид

У меня как-то тоже была такая идея, правда потом я получил стрелу в колено она так и осталась идеей. будет интересно, получится ли у Вас =)

NOX ()
Ответ на: комментарий от theos

а конфиги принято хранитьт у них в виде .PHP файлов - парсить нечего.

До поры до времени.

Вопрос на засыпку. Тебя не напрягает, что шарингом соединений (mysql, memcache, whatever…) занимаются расширения где-то в потрохах, а не аппсервер? И эта логика, зачастую, сделана очень топорно.

baverman ★★★ ()
Ответ на: комментарий от theos

Причем здесь динамическая типизация? Динамические языки тоже компилируются.

Просто они обычно компилируются каждый раз при запуске

Так делает разве что убогий PHP (да и то я сомневаюсь). У того же Python есть pyc-файлы.

можно будет попробовать написать ручками релоадер который сам сервер не перезапускает, а только модуль релоадид.

Всё это чревато неочевидным поведением.

tailgunner ★★★★★ ()

режим PHP

Звучит, как что-то плохое.
«Начальник ушел. Достаем пиво, включаем режим PHP.»

efe421 ()
Ответ на: комментарий от tailgunner

Так делает разве что убогий PHP (да и то я сомневаюсь)

Правильно сомневаешься. Именно этим и занимаются (обязательные на практике) PHP-акселераторы. Они кешируют компилированный байткод, так что при повторной загрузке он сразу исполняется без предварительного парсинга и повторной компиляции. Обычно получается около пятикратного ускорения на типовых несложных запросах. И PHP-фреймворки оказываются на одном уровне производительности с Django :)

http://www.alrond.com/ru/2007/jan/25/rezultaty-testirovanija-6-frameworks/ плюс последующие поправки.

KRoN73 ★★★★★ ()
Ответ на: комментарий от NOX

А PHP всё-таки помедленней Ruby будет

В роли числодробилки — да. И значительно. На практических проектах в сравнении с тем же RoR — одного уровня фигня выходит.

KRoN73 ★★★★★ ()
Ответ на: комментарий от baverman

Ага, неправильно написал =)

Ruby, а не RoR, конечно же. Хотя не знаю, насколько можно сравнивать Твиттер и Фэйсбук по нагруженности.

NOX ()
Ответ на: комментарий от KRoN73

«Тест» фреймворков полная чушь. На живых приложениях результаты сильно грустнее для PHP, так как окружение надо поднимать каждый раз.

Более того, на минимизацию и оптимизацию этого кода идет значительная часть сил при разработке нагруженных сайтов. Доходит даже до ленивой загрузки конфигов и подсистем.

baverman ★★★ ()
Ответ на: комментарий от KRoN73

Сходил по ссылке, увидел Django в топе =)

Да и тесты старенькие. Хотя, конечно же, в сложных проектах больше всего важна архитектура приложения, ИМХО.

NOX ()
Ответ на: комментарий от baverman

На живых приложениях результаты сильно грустнее для PHP, так как окружение надо поднимать каждый раз.

Именно на живых всё становится лучше. Время подъёма окружения фиксировано. И потому для простых тестов сказывается куда больше, чем для тяжёлых приложений.

Доходит даже до ленивой загрузки конфигов и подсистем.

Правильно. Тем более, что на PHP это очень просто делается :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от NOX

Сходил по ссылке, увидел Django в топе =)

Там PHP без акселераторов тестировался :) Я же сказал, что надо продолжения теста смотреть.

Хотя, конечно же, в сложных проектах больше всего важна архитектура приложения

Естественно.

KRoN73 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.