[NiTr0]

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

 

В данный момент - код представляет из себя скорее proof of concept чем готовое решение. Однопоточный (хотя - уже подготовлен для разноса по потокам); без тайм-аута исполнения (пока); без каких-либо опций коммандной строки. Но уже умеет исполнять перловые CGI скрипты через do() вместо exec(), что на зионе L5420 дает экономию в 0.1 сек, или порядка 30% для стартовой странички личного кабинета либо диалап статистики (краткий тест: 0.27 сек против 0.37 для стартовой; 0.14 сек против 0.24 для e-mail). При этом - совместимость с обычными cgi не заломана.

 

В близкой перспективе: многопоточность, тайм-аут исполнения, использование unix сокетов, смена владельца (дабы не стартовать через sudo) и chroot. Возможно - еще что-то, что вылезет по ходу дела.

 

Репозиторий на гитхабе - вот: https://gitorious.org/perl-fpm/perl-fpm

 

Собссно - пожелания, предложения, указания на баги/проблемные места в коде, а также патчи с вкусными для всех плюшками (когда проект приобретет более законченный и пригодный к использованию вид) приветствуются.

[dolphinik]

Зачем тормошить труп?

[Ivan_83]

Делал тоже самое пару лет назад, только по проще :)

http://www.netlab.linkpc.net/wiki/ru:software:perl:fastcgi

[NiTr0]

Зачем тормошить труп?

Есть биллинг, есть желание перевести его на FastCGI, и нет желания переписывать при этом гору кода. А заодно есть желание использовать это и для других веб-проектов на перле (увы, перл пока что видится самым адекватным универсальным языком программирования для быстрой разработки - пхп сливает по возможностям и удобству, питон - весьма печален при кол-ве потоков более 1 из-за GIL, ява - монструозна). Не спорю, решение не оптимально, переписать все под полноценный FastCGI было бы правильнее, дабы не порождать кучу классов каждый запуск - но желания этим заниматься пока нет, а экономия 30-50% ресурсов - уже неплохой результат ИМХО.

 

Делал тоже самое пару лет назад, только по проще :)

Не то же самое. У вас - враппер, порождающий процессы скриптов через exec. Со всем прочим оверхидом. У меня - полноценный FastCGI (насколько это применимо к generic скриптам), исоплняющий скрипты через do :) К слову, за основу брался, похоже, тот же скрипт враппера, что и у вас... Да и PocessManager ИМХО не будет у вас прибивать повисшие скрипты, только ожидающие результата процессы прибьются :) Что чревато...

[s.lobanov]

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

 

perl годится только для одноразовых скриптов(когда нужно что-то очень быстро сделать). поддерживать перловый код слишком дорогое удовольствие(в пересчёте на человекочасы).

[dolphinik]

>питон - весьма печален при кол-ве потоков более 1 из-за GIL,

Слышал звон, да не знаю где он. А многопоточный перл - это, конечно, идеал. Питон умеет масштабироваться по ядрам и процессорам. Уже тьма библиотек для этого. Тот же Celery, который может обрабатывать задачи в кластере из десятков машин и он просто обёртка над вашим кодом. А по поводу прототипирования - проще и быстрее питона только tk и lua. И это может отрицать только человек, который остал от мэйнстрима лет на 10.

RADIUS сервер на питоне с тремя тредами внутри обслуживает по 600-700 Access Request пакетов в секунду с MSCHAP2 на весьма среднем железе. Не каждый провайдер может создать такую нагрузку.

Используйте питон и счастье будет.

Edited February 23, 2013 by dolphinik

[s.lobanov]

олдскул он такой, хватается за последний глоток воздуха. наверное лет 25 назад были такие же жаркие дискуссии на тему C vs ASM/машинный код.

[sol]

Угу. Олдскул... Человек дело сделал а вы хаять...

 

Раз сделал - значит: 1. Надо было. 2. Тас сделать оказалость проще для этого человека. Честь ему и хвала. Я вот, например, воспользуюсь.

 

У меня по сей день работает 3 мб перлового кода и есть не просит. По вашему, когда устарел/исчез suid perl я должен был всё то, что писАлось и отлаживалось более 10 лет похерить и переписать на пистоне или изменить концепцию безопасности и переписАть половину системы? Вот вам шиш. Это всё будет переписываться тогда, когда преодоление возникшего препятствия в эксплуатации этого кода станет дороже/сложнее, чем переписать этот код.

 

Один из моих бывших шефов - олдскульный программер на клипере. И его "бухгалтерия", а еще точнее, склад/бухгалтерия/заказы/счета/и вся-вся-вся работала 15 лет и умерла только с закрытием/перепрофилированием конторы. И это было удобно и максимально подходило под рабочий процесс в этой конторе. 5 мб кода на клипере. Что надо было сделать? На писать обёртку под винды? Или не приращивать к ней сканер штрихкодов? Все эти работы заняли мах 1 месяц труда одного человека и не одномоментно месяц, а по 1-2-3 часа по мере возникновения проблем. А взять 1С, которая умеет, в общем, то-же самое и переучить на неё толпу манагеров и проапгрейдить их компы и купить туда за тонны денег лицензионный софт, да хоть ту-же 1С? Зачем всё это делать, если проще оказалось написать небольшой враппер для ряда операций, суть которых изменилась за время развития от МС-ДОС 3.30 до сегодняшних дней?

[adnull]

mod_perl воткнуть не проще было?

[NiTr0]

perl годится только для одноразовых скриптов(когда нужно что-то очень быстро сделать). поддерживать перловый код слишком дорогое удовольствие(в пересчёте на человекочасы).

Все зависит от того, насколько сильно говнокодить.

 

Питон умеет масштабироваться по ядрам и процессорам. Уже тьма библиотек для этого.

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

 

А по поводу прототипирования - проще и быстрее питона только tk и lua. И это может отрицать только человек, который остал от мэйнстрима лет на 10.

Tk - имеется ввиду tcl, а не его графическая библиотека tk? Тикль убог, имею опыт. LUA - на первый взгляд еще хуже...

И да, на перле у меня к примеру реализация парсинга гугловского kml для заполнения узлами/линиями карты сети заняла несколько дней и 10 кб кода. Насчет питона - сомневаюсь, что это получилось бы таким компактным и читабельным.

 

mod_perl воткнуть не проще было?

На нгинкс? :)

[sexst]

Питон умеет масштабироваться по ядрам и процессорам. Уже тьма библиотек для этого.

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

multiprocessing GIL'у не подвержен.

[andryas]

Перл - самое то. У меня некоторые скипты более 12 лет крутятся, многое по мелочи и сейчас пописываю. Там, где требовалось быстродействие - переписал на С. Perl - красивый язык, и програмирование на нём приносит удовольствие. Практически любая задача решается быстро и крайне лаконично.

Лет 15 назад был без ума от клипера, но с умиранием файлориентированых СУБД и переходом на NT открыл для себя Perl. С тех пор большинсво нужных мне задач решается элементарно просто и крайне быстро.

[adnull]

На нгинкс? :)

 

На апач, естественно.

[Ivan_83]

Не то же самое. У вас - враппер, порождающий процессы скриптов через exec. Со всем прочим оверхидом. У меня - полноценный FastCGI (насколько это применимо к generic скриптам), исоплняющий скрипты через do :) К слову, за основу брался, похоже, тот же скрипт враппера, что и у вас... Да и PocessManager ИМХО не будет у вас прибивать повисшие скрипты, только ожидающие результата процессы прибьются :) Что чревато...

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

По наблюдениям - не течёт, может просто не висло ничего.

Там ссылки были, на два первоисточника, из которых я брал.

Вот пхп воркеры начали течь, пришлось ограничить им количество запросов за время жизни.

 

 

PS: пишу на си, скучаю по вижал бесику и асму, остальное херня.

[_INF_]

thhtpd не ?

[adnull]

да зачем вы велосипед придумываете? Мы тут под python аналогичные тесты провели - http://habrahabr.ru/post/67475/ вкратце - оверхед от апача почти не заметен.

[dolphinik]

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

Вбивая гвозди микроскопом можно ещё больше проблем себе придумать. Дело не в GIL, а в том, что он страшнее звучит, чем выглядит на самом деле. В современном мире хватает подходов и средств для решения проблем многопоточности в питоне. И поверьте, они куда более наглядные и производительнее того, что может предложить перл или PHP ;). При всём моём уважении к истории перла - его время прошло. Создавать сегодня продукты на перле - это значит оставить их через 5-10 лет без дешёвой поддержки. Вспомните cobol и его собратьев. Просто смиритесь с тем, что перл оставил после себя много хорошего, но он его время безвозвратно ушло. Выучите питон и вы поблагодарите тех людей, кто вам его посоветовали.

Edited February 23, 2013 by dolphinik

[kayot]

Не сильно понимаю к чему все это. У нас биллинг целиком на php написан, и это не 3мб а все 300 - работает, загрузка машины служащей БД и ядром сети пару процентов..

[dolphinik]

Тут просто упрекнули питон в немасштабируемости.

[NiTr0]

multiprocessing GIL'у не подвержен.

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

 

На апач, естественно.

Спасибо, накушался.

 

Мы тут под python аналогичные тесты провели - http://habrahabr.ru/post/67475/ вкратце - оверхед от апача почти не заметен.

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

 

Дело не в GIL, а в том, что он страшнее звучит, чем выглядит на самом деле. В современном мире хватает подходов и средств для решения проблем многопоточности в питоне.

Ну мне к примеру не нравится искать костыли для обхода кривого интерпретатора.

 

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

Писал уже на нем, реализацию некоего проприетарного протокола отдаленно напоминающего modbus - в целом не сильно впечатлил. Может, дело привычки. Но с ходу никаких киллер фич, выгодно отличающих его от прочих языков, не назову.

 

там и форков хватает чтобы изредка заглядывать

Не форков, обычный CGI у вас через FastCGI интерфейс враппера.

 

По наблюдениям - не течёт, может просто не висло ничего.

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

[sexst]

multiprocessing GIL'у не подвержен.

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

Оно работает. Оно позволяет синхронизировать потоки. Оно размазывается по ядрам. Оно выглядит как потоки. => Мне все равно костыль это или нет. Молоток нужен чтобы им лупить, а не спорить на тему его формы.

 

ЗЫ. Питон кошерен своими библиотеками, которые позволяют сделать очень многое за полчаса на коленке своими силами и не привлекая программеров. Но все это холиварно. Любите perl - ваше дело, СИ - пожалуйста, хоть турбо паскаль =)

[Aliech]

Любители всего_чего_угодно_акромя_перла_потому_что_он_сцук_такой_запутанный добивают. Особливо отсутсвием пруфов... Да...

 

ЗЫ. Питон кошерен своими библиотеками, которые позволяют сделать очень многое за полчаса на коленке своими силами и не привлекая программеров.

Ещё один. CPAN, ещё когда ваш Питон был только игрушкой ;)

[adnull]

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

За более чем 5 лет эксплуатации ничего такого не замечено. Да, естественно, снаружи торчит nginx. Но это, извините, уже дефолт для защиты от медленных клиентов.

Про ООМ не в кассу, т.к. если с этим есть проблемы, то их нужно решать ан уровне ДНК, а не способа публикации приложения.

[NiTr0]

Про ООМ не в кассу, т.к. если с этим есть проблемы, то их нужно решать ан уровне ДНК, а не способа публикации приложения.

Имел в свое время опыт борьбы с джумловской кривописью, жрущей сотни памяти, и апачем, на относительно нагруженном сервере. Ставить малое кол-во worker'ов - у клиентов начинаются проблемы (ибо те же жирные worker'ы отдают в т.ч. и статику). Много - периодически ООМ случается, а перед ним система уходит в глубокий своппинг. После установки нгинкса с php-fpm - проблема рассосалась сама собой, потребляемые ресурсы режутся прозрачно и без ущерба для юзабельности. О том, что потребление памяти упало раза в 2 - помолчу.

Соответственно - по результатам появилось стойкое желание выпилить индейца по возможности везде, где это возможно, а особенно - где ожидаются сколь-либо существенные нагрузки. Чем по мере переноса сервисов и занимаюсь неспешно.

[Shiva]

Подброшу на вентилятор... C# :)

 

З.Ы. Вполне себе язык на mono 3.0+