Используем память разумно. Часть 2. fapws3

    В предыдущей части мы начали бороться за память на 256 мегабайтном слайсе «на скорую руку». Результат был, но не столь эффектный как тот которого я добился на этот раз.

    Я всегда догадывался, что причина всех моих неприятностей — apache. И чем больше я пытался его настраивать, тем больше в этом убеждался. Вывод? Попробовать заменить. Одно но — переход должен быть как можно более плавным, поскольку речь, ясно дело, о продакшене.

    Поскольку у меня был опыт общения с nginx, а если быть точным — опыт с проксированием, то был выбран именно этот веб-сервер. К тому же у него хорошие параметры производительности.

    Первое что я попытался сделать — собрать nginx с mod_wsgi (не путать с тем же для apache). Собрать-то получилось, а вот заставить работать — нет. Постоянно валялся с ошибкой «невозможно испортировать как модуль...». Но не суть важна, уйти от этого хода стало так же причиной некоторое затухание проекта mod_wsgi… Хотя и то что я выбрал нельзя назвать активно развивающимся и стабильным :)

    После долгих копаний и мУченья постояльцев конференции pythonua@conference.jabber.ru, был брошен взор на fapws3. Если коротко, то это веб-сервер, написанный на питоне. Теоретически, его можно использовать просто так, без nginx, но я пока не нашёл способа создания виртуальных хостов по доменам, да и со статикой nginx обращается куда лучше.

    Итак, у меня на слайсе archlinux, соответственно всё что ниже справедливо именно для него. pacman — менеджер софта, можете использовать свои apt-get etc. по выбору, разве что названия пакетов могут отличаться.

    fapws3


    В установке fapws3 нет ничего сложного. Качаем tarball, разархивируем, выполняем python setup.py install. Предварительно не забываем установить libev

    pacman -S libev

    именно на ней основан fapws.

    В архиве вы найдёте папочку examples, а в ней django. Берём run.py и кидаем в свой проект. Лучше сразу же проверить работоспособность запустив его python run.py.

    Тут скорее всего вылезит эксепшн, мол DJANGO_SETTINGS_MODULE не определён… Но это решается просто добавлением os.environ['DJANGO_SETTINGS_MODULE'] = 'kaexpert.settings' в run.py (разумеется заменяем на свой модуль).

    Так же нужно менять порты. Т.е. для каждого сайта свой порт. Я начал нумерацию с 8081 и так далее. Далее это потребуется при настройки nginx. К слову сказать порт настраивается в evwsgi.start("127.0.0.1", 8081) (для тестирования можно использовать IP 0.0.0.0, чтобы можно было проверить работоспособность без nginx, в нашем же случае кроме nginx напрямую к сайту никто не обратится… это правильней)

    nginx


    Тут тоже ничего сложного: pacman -S nginx. Далее настройки. Поскольку мне требовалась бесперебойная работа сервера, nginx я поставил на порт 8080, для этого находим в /etc/nginx/conf/nginx.conf строчку listen 80 и меняем 80 на 8080.

    Всё что требуется от nginx — проксировать динамические запросы на fapws сервера, а статику раздавать самому. Для этого делаем для каждого сайта блок server внутри http в /etc/nginx/conf/nginx.conf:
    server {
            listen       80;
            server_name  promex.su;
    	location /static  {
    		root /srv/http/promex.su/;
    	}
    	location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov) {
    		access_log   off;
    		expires      30d;
    	        root /srv/http/promex.su/;
    	}
    	location /media {
    		root /usr/lib/python2.6/site-packages/django/contrib/admin/;
    	}
    
            location / {
    	    proxy_pass http://127.0.0.1:8082;
    	    proxy_set_header X-Forwarded-Host $server_name;
    	    proxy_set_header X-Real-IP $remote_addr;
    	    proxy_set_header X-Forwarded-For $remote_addr;
    	}
    
            #error_page  404              /404.html;
    
            # redirect server error pages to the static page /50x.html
            #
            error_page   500 502 503 504  /50x.html;
            location = /50x.html {
                root   html;
            }
        }
    


    Здесь важна строчка proxy_pass, в ней нужно указать порт из run.py. В каких местах настроена статика, думаю ясно, не будем вдаваться в подробности, просто исправьте пути на свои.

    supervisord


    Поскольку fapws3 для каждого сайта — отдельный демон, нужно как-то управлять всем этим зверьём. Для этого я взял supervisord. Это что-то вроде rc.d, только написано на питоне и куда адекватней… В плане лично мне лень писать rc для каждого сайта, а потом ещё добавлять в rc.conf. С супервизорд нам требуется лишь добавить сам его в rc.d и настроить сайты в его конфигурации (очень просто). Ставится он немного сложней, через aur, но возможно в вашем дистрибутиве он есть как поддерживаемый пакет. Хотя с моим yaourt всё сводится к команде yaourt -S supervisord :) Советую всем arch юзерам воспользоваться.

    В rc.conf добавляется так: DAEMONS=(syslog-ng network netfs crond sshd supervisord).

    Конфигурация очень проста, по виду как win-ini. Для меня было достаточно добавить такой блок:
    [program:kaexpert]
    command=/srv/http/ka-expert.ru/src/run.py
    process_name=%(program_name)s
    user=http

    command — сама команда, не забудьте только сделать run.py исполняемым
    process_name — имя процесса
    user — от какого пользователя будет запускаться (тот же что и веб-сервер, а nginx у меня под http а не стандартным nginx, поскольку всё заточено именно под http, т.к. апач)

    Ну вот и всё. Разумеется такое нужно для каждого сайта. Лично я ещё раскомментировал секцию [inet_http_server], что даёт веб-интерфейс, но лично у меня он криво работает… Только информационную функцию выполняет, перезапустить процесс не получается, только через supervisorctl, и то с эксепшенами (видимо в них дело, но разбираться было лень).

    Итог


    Итого у нас освободилось более 100Мб памяти, сейчас картина выглядит так
                 total       used       free     shared    buffers     cached
    Mem:           256        113        142          0          4         32
    -/+ buffers/cache:         75        180
    Swap:          511         27        484
    

    После перезагрузки swap должен уйти в mem, но пока не заморочился — пусть uptime тикает :)

    В общем и сложном мы получили огромную экономию памяти и увеличение скорости вообще. Субъективно, страницы стали загружаться раз в 5 быстрее, тестером не мерил, меня устраивает :)

    Удачи!

    Via Retta Inc.

    P.S> Плюсики в карму не помешают — всегда есть хорошие люди которым нужен инвайт :)
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 79
    • 0
      А FastCGI не пробовали? Вроде шустро работает
      • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
          • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
              • НЛО прилетело и опубликовало эту надпись здесь
                • НЛО прилетело и опубликовало эту надпись здесь
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • –1
                        Я вам кокретно продемонстрировал разницу в расходе памяти. (конец статьи). Это по сравнению с mod_wsgi + apache. Демонов получается одинаковое количество. fastcgi как мне известно, плохой, иначе небыло бы смысла в wsgi.
                        • 0
                          Сам по себе FastCGI не плох. WSGI как стандарт взаимодействия веб-сервер/приложение был создан по другими причинам, нежели «наш ответ FastCGI».
                          • 0
                            Я о реализации. Сами стандарты в плане производительности и т.п. сравнивать смысла нет. А wsgi как мне известно был ответом на Джавовский стандарт.
                • 0
                  fapws джангу в том же mm держит, полагаю. Ну а строки в питоне immutable, т.е. в рамках одного процесса не копируются зазря.
              • +1
                > В частности, джанга построена на flup,

                Это как?

                > Лишний веб сервер посредине — это лишняя работа по прекачиванию данных из одних буферов в другие. Этот вариант не самый производительный.

                А вы знаете как flup обрабатывает бинарные потоки, которые к нему от сервера приходят? Поизучайте. Это слезы

                > По тестам проведенным мною лично и теми же разработчиками django оптимальный вариант именно работа джанги через fastcgi.

                Вполне может быть, но не с flup.

                У flup пока есть другие преимущества из-за которых иногда его оправдано использовать.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • +2
                    > // я понял что дискуссия с вами господа будет продолжаться вечно.

                    Ещё бы, если вы на наши скромные вопросы не отвечаете.

                    > оно там есть и через него работает джанга когда дружиш ее с fastcgi.

                    Так значит не джанга построена, а в ней есть механизм взаимодействия с flup. Это уж, извините, разные вещи.

                    > что именно и как вы ему скармливаете и покажите тот кусок кода который вас смущает во флапе.

                    Обидно trac флаповский сломался, а то бы ещё как показал.

                    > а теперь о трэдах:

                    Вот тут вы как раз на вопрос (заданный чуть ниже) не ответили. Как по вашему работает fapsws и flup? Причем тут nginx вообще не понятно. Видимо чтобы «объему» добавить и не сказать ничего по существу.

                    Не конструктивная позиция. А обидно, было бы очень интересно обсудить конкретный вопрос.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        >синхронный фронт

                        from www.grid.net.ru/nginx/nginx-modules.html:
                        >Главной особенностью реализации nginx, является то, что все сетевые операции ввода-вывода выполняются асинхронно относительно выполнения рабочих процессов.

                        Кто кого наёбывает? :)
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            Задержки сети куда больше, обычно, чем задержки в других местах. Веб-сервер главным образом должен работать с сетью, а не файловой системой. К тому же, если мы говорим о nginx, в связке nginx + fapws только и играет роль сетевой свящки клиента и самого приложения (больше он ничего не делает… опустим отдачу статики, да и тут он один из лидеров).

                            Вы сами уже запутались и стоите в позиции «лишь бы против». Сначала вы говорите что FastCGI рулит, а теперь говорите что nginx сосёт. У вас FastCGI в воздухе висит? Или мб апач?

                            Короче определитесь что вас не устраивает — бэкенд или фронтенд. По последнему сообщению кажется что вас уже всё не устраивает.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • 0
                                >flup в свою очередь умеет работать через fastcgi. Нахрена изобретать велосипеды?
                                Ваше слова?

                                >помойму если кого что и не устраивает то это только вас.
                                Эти слова должны быть моими :)
                        • +1
                          Пожалуйста не надо заниматься мифотворчеством. Описанная вами ситуация это когда имеется один воркер и он же отдает огрооомный файл. Но это надо чтобы звезды на небе сошлись. Обычно воркеров несколько и проблема тотальной их блокировки не стоит.

                          При всем при этом, это не мешает быть nginx'у (его воркерам) асинхронным веб-сервером с блокирующим файловым I/O (почему так сделано, вопрос к Сысоеву и разработчикам ядер *nix подобных систем). И уж тем более это не мешает fapws быть честным асинхронным сервером. Как эта асинхронность влияет на производительность, в каких случаях она дает выигрыш, а в каких нет — это уже тема совершенно другого разговора.

                          В данном конкретном случае мы оставляем на совести автора поста то, как он настаивал до сего момента свой flup и почему он у него кушал много памяти. В ситуации медленной обработки запроса правильно настроенный флап может дать прирост производительности. В случае быстрых ответов наоборот fapws может дать значительно увеличение rps при константном расходе памяти. Вот тут имеет смысл его использовать.

                          Потом, уж коли вы не знаете, как работает fapws, то пожалуйста не надо материться и другим затыкать рты, говоря, что они ничего не понимают. Как выясняется вы сами плаваете в данной теме и явно имеет некий процент каши в голове по поводу как работы nginx'а так и обсуждаемых бекэндов. Про fapws и, например, cogen советую вам поизучать материалы отдельно. Чтобы впредь вы своим воинственным невежеством не оскорбляли участников сообщества.
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • +1
                              > fapws ниразу не юзал, не отрицаю. Но в сказки что с четнием/записью файлов там полный aio я не верю.

                              Файлов? Так посмотрите и поверьте. Это не больно.

                              > в 3ем параграфе ваше ответа какаято ересь. А вы знаете как fapws будет обрабатывать медленные соединения? и за счет чего там не будет расхода памяти? я вот могу доказать что он будет. На каждое соеднение. и вполне приличен так. Особенно если ваши соединения «медленные».

                              В общем посмотрите fapws. Догадки строить все умеют.

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

                              А вы у Сысоева в рассылке материтесь? А посылаете всех направо и налево? Так вы сами создаете атмосферу сообщества. Изначально вы пришли и сюда и полили всех грязью. А на прямые вопросы стали раздражаться и давать пространные ответы. Да ещё, как выяснилось, в теме в которой вы не разбираетесь.

                              Когда будете в адекватном состоянии, то буду рад пообщаться с вами например по почте или джаберу.
                            • 0
                              Небольшое примечание: у автора топа раньше был apache2 + mod_wsgi
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • 0
                              а меня то не спросили. вы так весело сретесь, давай еще — у меня попкорн еще не закончился.
                          • 0
                            > оно там есть и через него работает джанга когда дружиш ее с fastcgi.
                            С таким же успехом в неё может быть встроен fapws, не кажется? flup для дев-сервера на сколь я понимаю.
                  • 0
                    Вообще конечно fapws не замена апачу (тем более хорошо настроенному). Он не production ready или по крайней мере об этом никто не знает. Потом все эти решения плохо масштабируются под нагрузкой. Нет умного шедулера процессов, а следовательно адаптивно форкаться или порождать новые инстансы сервера для балансировки на них не получится.

                    Кстати supervisord умеет нативно работать над FastCGI и может динамически порождать процессы в зависимости от нагрузки. Вот это уже интересно.
                    • +1
                      Неужели вы думаете что на 256 Мб будет крутится что-то сильно нагруженное? :) Впринципе целевая аудитория именно такая. Тем кому нужно распределение не будут даже бесплатно юзать 256 Мб сервера.

                      Если интересно, там 4 сайта всего с 200 униками в день каждый. С апачом это жрало всю память и 150-200 Мб swap… Не спорю, апач стоковый. После небольшой настройки ситуация немного изменилась, но не так кардинально.

                      И в моём случае стабильность системы с апачём многим меньше чем fapws3 (ну мне так кажется, пока не долго на нём сижу), т.к. каждые 5 дней использование всех ресурсов зашкаливало и слайс просто отказывал в обслуживании до хард ресета. Поэтому тут не всё так просто :)
                      • 0
                        у меня на слайсе в 256 крутится 5 сайтов суммарно с 6к уников в сутки (nginx->apache + mod_php/mod_wsgi). Все летает. Что я делаю не правильно?
                        • 0
                          nginx -> apache :)
                          Незнаю уж почему, но длинные цепочки _лично мне_ не нравятся. Выход одной цепочки из строя и всё. Пиши пропало.
                  • +2
                    Просто тогда в посте не хватает упоминания «целевой аудитории» такого решения чтобы не возникало лишних вопросов.

                    А вообще апач с embeded mod_wsgi (и даже в принципе mod_python) может очень хорошо и не прожорливо работать с минимальным расходом ресурсов. Но согласен, его в разы труднее настраивать и надо понимать чего хочешь и как этого добиться.

                    Ах да, ещё, fapws не чисто питонячий — там сердце это сишный libev для асинхронной обработки I/O.
                    • +3
                      Интересно было бы почитать про сборку апача под Django и вообще питон. С тестами.
                      • +4
                        Напишем:-)
                        • 0
                          Ждём :) Для меня это вообще нереальные дебри, я еле с модулями разобрался (пока выкидывал ненужные, сервер падал многа-многа раз), а уж сборка статичная… :)
                    • 0
                      у меня django и lighttpd общаются через flup (WSGI-совместимый FastCGI-сервер)

                      в django flup поддерживается (python manage.py runfcgi)

                      пара скриптов в init.d для запуска/остановки сервера и готово
                      • 0
                        как это настроить — описано прямо в документации django

                        так что мне непонятно, почему автор выбрал такой мудрёный вариант
                        • 0
                          flup форкается и тредится (можно конечно ему сказать maxсhildren=1, но смысл). fapws асинхронный однотредовый. Разные подходы у них.
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • +1
                                Так вы разочаровывайте аргументировано. Я только рад буду новому научиться от умных людей. Расскажите как fapws работает и как flup на самом деле, если я не прав. Пожалуйста.
                            • +2
                              Автор, видимо, в душе исследователь. И это позитивно!

                              Я долго колебался между lighttpd и nginx, но потом выбрал последний просто из-за какой-то мелочи. Джанга подключена через flup/fastcgi аналогично, как абсолютно штатный вариант.

                              Исторически сложилось, что я пускаю сервер скриптом при помощи init, так как останов не предусматривается, а рестарт получается в этом случае просто при помощи kill.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • 0
                                топик про экономию расхода памяти на VDS

                                очевидно, что делать highload-проект на VDS вряд ли кто-то станет

                                так что не понимаю, к чему ваш коммент

                                алсо, пруфлинк в студию
                                • НЛО прилетело и опубликовало эту надпись здесь
                                • +1
                                  Какой нагрузке и как валится? Очень интересно.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                    • +1
                                      Что такое хорошая нагрузка и что там валится?

                                      Глядя на фастцги и пул воркеров просто не понятно чему там валиться.
                                  • 0
                                    > Первое что я попытался сделать — собрать nginx с mod_wsgi (не путать с тем же для apache). Собрать-то получилось, а вот заставить работать — нет. Постоянно валялся с ошибкой «невозможно испортировать как модуль...».

                                    Не думаю что проблема тут в nginx или mod_wsgi под него ;) что-то не так делаете
                                    • 0
                                      Экзамплы не запускаются с той же ошибкой… Я даже не знаю что уж так :)
                                    • 0
                                      fapws как и nginx mod_wsgi годны для потестить и для вашего случая. Почитайте комменты в багтрекере lighttpd. flup действительно иногда нужно перезапускать(впрочем, не буду утверждать т.к. не уверен что он был причиной нескольких аномалий). Грамотно собраный апач с mod_wsgi наше все.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                          • +1
                                            Здесь автор блога byteflow подсчитывал производительность wsgi vs fastcgi
                                            piranha.org.ua/blog/2007/11/24/nginx-mod-wsgi-vs-fastcgi/
                                            • 0
                                              он сравнивает mod_wsgi, что совсем другое и к fapws отношения, кроме как использования одного стандарта взаимодействия с приложением, не имеет.
                                              • 0
                                                daevaorn + 1
                                                да и статейка старовата уже, имхо
                                                • 0
                                                  Вы не забывайте что fapws и прочие асинхронные сервера не зря называются асинхронными. При любом синхронном вызове блокируетя весь сервер. А посколько Django и другие используют вполне себе синхронный режим работы то для реального приложения один fapws будет практически всегда заметно медленнее чем пулл процессов или потоков.

                                                  Мы пробовали обходить это ограничение запуская 4 фапса на разных портах, и потом распределяя коннекшены между ними на lighttpd. В такой конфигурации скорость поднялась до уровня flups (разница в пределах статистической погрешности). Выигрыш есть только по памяти, а флап проверен в бою. Да и на память мы не жадные. Так что пока все проекты остались на флапсе.

                                                  PS: автор блога byteflow в нашей команде работает
                                                  • 0
                                                    Кстати вот это очень интересный момент. Долгие обработчики запроса блокируют весь асинхронный сервер. Причем, что обидно, зачастую долгие эти обработчики из-за сложных запросов в базу данным, которые конечно же синхронные. Вот тут недостающее звено явно проступает — асинхронный драйвер для базы данных и его интеграция в веб сервер для прозрачного переключения контекста обработки http запросов. Пока хорошего решения нет, кроме как проксирования запросов в базу через промежуточный http сервер, но это увеличивает сильно latency и в большинстве случаев не эффективно.
                                                    • 0
                                                      Асинхронный драйвер для базы данных требует асинхронного фреймворка. Асинхронность вообще любит под себя захавывать всю архитектуру приложения.

                                                      Twisted вполне удовлетворяет всем требованиям, но что-то не получил в вебе особого распостранения. То-ли Nevow дело, то-ли в том что синхронный код людям всё же привычней.

                                                      А относительно Django, imho, форки — это единственный кошерный способ запуска.
                                              • 0
                                                fapws3 — еще молодое…
                                                странно, что для продакшена вы не попробовали несколько решений
                                                есть еще lighttpd в качестве фронтенда и бэкенд cherrypy, интересно было бы перед выбором чего-либо пробовать разные их и не только их комбинации, ибо тема действительно насущная…

                                                в любом случае спасибо за материал для размышлений!

                                                ну а с апачем действительно пора кончать;)
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                  • 0
                                                    с каких это пор лайти только для статики? он так же умеет и реверс прокси и фронтендом для fapws3 или cherypy или flup-а быть

                                                    > fapws3 пошустрее cherrypy
                                                    не готов утверждать.
                                                    покажите пруфтесты.

                                                    fapws3 насколько помню только в декабре делаться начался, сыроват еще, не зачем скрывать…

                                                    а fapws2 не умел треды совсем: пока одна страничка не отдастся, вторую он даже не начинал отдавать…
                                                    • 0
                                                      > а fapws2 не умел треды совсем: пока одна страничка не отдастся, вторую он даже не начинал отдавать…

                                                      Так это специфика асинхронного сервера и синхронного приложения. fapws3 так же себя ведет.

                                                      Надо просто несколько инстансев иметь.
                                                      • 0
                                                        несколько сколько? 200 или 300?

                                                        у меня на продакшене 150-200 одновременно живущих конектов — обычное дело.
                                                        • 0
                                                          Ну 3-5 где-то. В зависимости от специфики проекта.

                                                          Так тут дело не в числе конектов к фронту, а в скорости ответа на запрос от бекэнда.

                                                          Тредовые сервер точно также не будет обрабытывать новый запрос, если все воркеры заняты.
                                                      • 0
                                                        www.swivel.com/data_columns/show/9570256 бенчи, но непонятные вхлам.
                                                        • 0
                                                          это проблемы джанги и медленной СУБД,

                                                          я по сабжу небольшую заметку писал slav0nic.org.ua/entry/148

                                                          если вкратце, то в джанге отсутствует pool для базы, на каждый коннект подымается отдельный поток к базе, если вы развёртываете джангу на cherrypy (я сам юзаю этот метод) то теоретическое число одновременно обрабатываемых запросов упирается в параметр threads, а в асинхронном сервере один поток, вот отсюда и ростут все ноги)

                                                          кому понравился фапс, советую взгялнуть на cogen, он полностью на питоне

                                                          НО имхо самый оптимальный вариант развёртывание приложения -… SCGI
                                                          Во-первых протокол проще чем FCGI, следотально парсить его быстрее
                                                          Во-вторых fapws3, cherrypy это веб сервера, и имеет место бестолковый (в плане процессорного времени) парсинг заголовков протокла и другие мелочи, опятьже SCGI проще

                                                          сейчас написал простенький асинхронный SCGItoWSGI сервер на базе asyncore, работает быстрее фапса В)
                                                      • 0
                                                        Я посмотрел бенчмарки, cherrypy как-то тормоз выходит. Да и мало меня интересует скорость (4 сайта по 200 уников в день каждый), волнует скорее память (всего 256 мб)
                                                      • 0
                                                        Установка fapws3


                                                        Лучше было сделать пакет, тем более что PKGBUILD очень простой выйдет.

                                                        pkgname=fapws3
                                                        pkgver=0.2
                                                        pkgrel=1
                                                        pkgdesc="Fast Asynchronous Python Web Server"
                                                        arch=('i686' 'x86_64')
                                                        url="http://github.com/william-os4y/fapws3/tree/master"
                                                        license=('GPL')
                                                        depends=('python' 'libev')
                                                        makedepends=('setuptools')
                                                        install=
                                                        source=('http://github.com/william-os4y/fapws3/tarball/v0.2')
                                                        md5sums=('5a401ee8cf74ea7d77dd46ade42bddd3')
                                                        
                                                        build() {
                                                          cd $startdir/src/william-os4y-fapws3-c7815ebc1a32d6d196d74dbcdc86bbfd39b81d61
                                                        
                                                          python setup.py install --prefix=/usr --root=$startdir/pkg
                                                        }
                                                        # vim:set ts=2 sw=2 et:
                                                        


                                                        В AUR постить не буду, т.к. сам не пользуюсь.
                                                        • 0
                                                          Да, но не все тут на архе сидят :) Но идея очень правильная, так сказать, arch way :)
                                                        • 0
                                                          у меня лично, как раз наобарот, fapws3 жрал очень много процессорного времени(про память не помню), да он быстрый, но ресурсов жрет нереально много, предпочитаю пускать джангу через nginx+fastcgi для продакшен проектов

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

                                                          Самое читаемое
                                                          Интересные публикации