[Warszawa-pm] WebNano

[piotr pogorzelski]

> 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