[Warszawa-pm] WebNano

[Zbigniew Lukasiak]

No dobra - takie zabawy to fajne sa - ale porzucając je na chwile  i
wracajac do tematu frejmworkow (moze ktos zna jakies spolszczenie?) to
wydaje mi się, że Catalyst przechodzi teraz w faze stagnacji, jest już
za duży i za skomplikowany i już w sumie za bardzo nie będzie się
rozwijał.  W grudniu zapłacono mi za zrobienie Application-Context
split czyli rozdzielenie kontekstu ktory powstaje od nowa przy kazdym
requescie i aplikacji ktora trwa.  Miala to byc rutynowa i krotka
robotka i mialem dostac za to 100$, poniewaz i tak nie mialem co robic
i w sumie ciekawilo mnie co tam w środku Catalysta jest to sie
zgodzilem, oczywiscie trwalo to w  koncu 2 tygodnie i i tak to co
napisalem chyba trzeba bedzie powtarzac - no ale sobie obejrzalem te
wnetrznosc (a zaplate mi wkoncu podwojono).  W kazdym razie to co
zrobilem sobie tam siedzi, podobno jest to jedena z najwazniejszych
zmian potrzebnych Catalystowi - ale jakos nie ma komu moje zmiany
przeniesc do 'trunka', bo to jest ogromna robota.  Catalyst ma swoj
stack, dispatching itp - moim zdaniem to jest to zupelny balagan i ta
funkcjonalnosc ktora daje mozna by osiagnac duzo mniejszym narzutem
kodu.  Dlatego mam nadzieje na rozwoj Placka ktory otwiera rozne nowe
mozliwosci.

Z.

2010/5/7 piotr pogorzelski <pp w webtel.pl>:
>
>> A to nie wiem, ale miyagawa kiedys gdzies publikowal calkiem niezle
>> wyniki Placka przy serwowaniu statycznych plikow - byly calkiem
>> zblizone do golego apacha.  Moze to zalezy z jakim serwerem?
>> Probowales Starmana?  Na githubie widzialem jeszcze jakies inne jak
>> http://github.com/stash/Feersum - ktory ma tez byc podobno bardzo
>> szybki.
>>
>
> starman,starlet - podobnie. light/fastcgi jest od nich szybszy
> mimo, ze jest przejscie przez fastcgi to lifht
> na tyle szybko serwuje request, ze zarabia nawet na
> obluge fastcgi (starlet/starman to perl, czyli serwer i kod
> zwracajacy strng "hello world" jest w jednym interperterze perla)
>
> takie juz zupelnie "raw" fastcgi z perlem
>
> czyli skrypt perla fcgi na sockecie
>
> ---------
> use FCGI;
>
> my $socket = FCGI::OpenSocket( "/tmp/perl.socket", 5 );
> my $request = FCGI::Request( \*STDIN, \*STDOUT, \*STDERR,
>    \%ENV, $socket );
>
> my $count;
> while( $request->Accept() >= 0 ) {
> print STDERR "request\n";
>    print "Content-type: text/html\r\n\r\n";
>    print "hello perlFCGI world\n";
> }
>
> FCGI::CloseSocket( $socket );
> -------------
> i lighttpd jako front-end (ta sama instancja co php)
> daje
>
> ab -n 1000  http://localhost/perl/
> 0.477 ms/req (2098 req/sek)   uff, czyli da sie szybciej niz php (1500
> req/sek)
>
>
> po wylczeniu socketu sam light jest w stanie wygenerowac 4000 req/sek z
> odpowiedzia 503 - Service Not Available
>
>
> ale 2000 raw fcgi vs 750 placka
> trzeba pamietac, ze rawcgi jeszcze musialby parsowac parametry
> plack to pewnie robi przy tworzeniu requestu
> czy php to robi przy takiej prostej stronie, nie wiem
> moze dopiero przy pierwszym odwolaniu do parametrow?
>
> no i takie testy, to zadne testy, ot sprawdzenie jaki jest narzut
> technologi/frameworku i szacowanie co sie dzieje,
> co daje plack w stosunku do reszty dostepnych narzedzi
>
> dodanie do tego "raw" fastcgi parsowania argumentow przez CGI
> ----
> use FCGI;
> use CGI;
>
> my $socket = FCGI::OpenSocket( "/tmp/perl.socket", 5 );
> my $request = FCGI::Request( \*STDIN, \*STDOUT, \*STDERR,
>    \%ENV, $socket );
>
> my $count;
> while( $request->Accept() >= 0 ) {
> my $q=CGI->new;
> print STDERR "request\n";
>    print "Content-type: text/html\r\n\r\n";
>    print "hello perlFCGI world\n ". $q->param('hello') . "\n";
> }
>
> FCGI::CloseSocket( $socket );
>
> ----
>  daje
> ab -n 1000  http://localhost/perl/
> 0.750 ms/req (1332.83 req/sek)
>
>
> CGI tyle zjada
> ale nadal zjada mniej niz Plack :(
>
>
> gdy czytalem o PSGI nie spodobal mi sie fragment,
> gdzie napisali, ze decyzje odnosnie protokolu pdejmowali
> tak aby bylo latwo napisac drajwer do frameworkow.
>
> aby latwo przejsc z CGI na PSGI, echhh
> no i pisali drajwery w godzine
> a potem latami tracisz polowe wydajnosci serwera
>
> teraz czas zobaczyc alternatywne moduly CGI
>
> albo znalezc/napisac  cos co zamieni FCGI
> na request ala plack czy apache request object, cgi object
>
> i wtedy jest sie w tym samym miejscu co plack,
> tylko, ze z wydajnoscia x2 w stosunku do placka
>
> a fcgi jest uniwersalne, niezaleznie od serwera http
>
>
>
> --
> pp
> _______________________________________________
> Warszawa-pm mailing list
> Warszawa-pm w pm.org
> http://mail.pm.org/mailman/listinfo/warszawa-pm
>



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/