Comment by bbbbbbbbb | Hacker News Reader

Comment by bbbbbbbbb | Hacker News Reader

Parent Full thread

> That said, a doc patch is always welcome - on github fork or via RT.

I would like to but I need to understand how this works to provide any patch whatsoever. What about porting a CGI::Fast application into the PSGI stack then?

while (my $req = CGI::Fast->new) { myApp->run($req); }

Is there a handler/wrapper for that?

I've read all the articles but it did not help much. WebGUI discovered FastCGI via a PSGI implementation but it's FastCGI who brought the speed, not PSGI per se. So it brings me back to my point...

> think Apache + FastCGI + CGI::Fast is the best thing in the world and you absolutely need nothing else

I think FastCGI was there to solve indeed a problem and did quite well at doing so. It could be Apache/Nginx/IIS + FastCGI&CGI::Fast, it would work too (Apache/IIS is from experience but Nginx is just an educated guess).

I've decided a long time ago that I will never go the mod_perl way (or at least, will not use their low level access API) then switched to FastCGI and been happy since then.

I still don't get it but perhaps one day it will hit me. I guess when somebody will bring a "Middleware" that will meet a need.

In the meantime, I will try to play with it on my spare time. I guess it will be the easiest way to discover what I might be missing...

If DotCloud does not offer this infrastructure(Nginx+FastCGI), it's ok, I still can use our actual providers and it will work (exactly the WebGUI article example for cheap providers!)

Thank you for your time!

> while (my $req = CGI::Fast->new) { myApp->run($req); } > Is there a handler/wrapper for that?

Assuming that while loop is in your bootstrap FastCGI script, you can instead have an app.psgi (or whatever named) file with the content:

    use CGI::PSGI;
    my $app = sub { my $req = CGI::PSGI->new(shift); myApp->run_psgi($req) };

Now your new `run_psgi()` method should return the [ $status, $headers, $body ] array reference, instead of printing them to the STDOUT. And then the app.psgi can be run from CGI, FastCGI, mod_perl, Starman, Twiggy or whatever PSGI supported web servers.

For most web frameworks, the change should be minimal and straightforward: for example, CGI::Application needed less than 10 lines of code to implement this. http://search.cpan.org/~markstos/CGI-Application-PSGI-1.00/

(I implemented the original code, and markstos, the maintainer of CGI.pm and CGIApp now took it over. As you can see there's a small hack to capture the output - they're working on removing this hack by implementing the PSGI natively inside the CGIApp codebase)

> WebGUI discovered FastCGI via a PSGI implementation but it's FastCGI who brought the speed,

No, they got a performance boost with our preforking standalone HTTP server, which is currently called Starman, not just FastCGI.

Speaking of FastCGI, although Plack has a FCGI.pm-based FastCGI handler, i've been working on another FastCGI based preforking PSGI server called fastpass. https://github.com/miyagawa/fastpass

It is XS dependency free (unlike FCGI.pm and CGI::Fast) and the performance is still the same with FCGI.pm, roughly like 4000 requests per second on my laptop, with a simple HelloWorld app via an nginx frontend. I guess we could do even better by doing optional XS parsing with pure perl fallback as well.

FWIW for a comparison, with Starman I get 7k and Feersum gets 9k requests per second on the same machine. (Of course the number is not that significant since in the real world, your application does more IOs, templating stuff and database handling, and the qps would be much smaller)

Again, the nice thing about all of these things is that your code, and everyone else's code, don't need any line of code change to support this new server, once you get PSGI.

> In the meantime, I will try to play with it on my spare time. I guess it will be the easiest way to discover what I might be missing...

I'm pretty sure you will :)

> Assuming that while loop is in your bootstrap FastCGI script

Yes it is.

> For most web frameworks, the change should be minimal and straightforward

Indeed, it seems so.I'll try it out.

>No, they got a performance boost with our preforking standalone HTTP server,

I was talking about these lines in the article, where Starman is not used at all:

--------

I’ve codenamed the project “PlebGUI“, which I think aptly describes the way it makes it possible for the little people to run WebGUI on low-cost shared hosting.

And it actually works. Take for instance plebgui.patspam.com, a demo PlebGUI site site running in FastCGI mode on HostMonster (the prototypical low-cost shared webhost).

---------

Even though, the application did have even better performance via Starman but it is more a server matter than a PSGI related matter.

>fastpass [...] is XS dependency free (unlike FCGI.pm and CGI::Fast) and the performance is still the same with FCGI.pm, roughly like 4000 requests per second on my laptop, with a simple HelloWorld app via an nginx frontend. I guess we could do even better by doing optional XS parsing with pure perl fallback as well.

THIS is interesting.

I've read the entire advent for plack and started to port my app.

- Why send back an array ref instead of using the CGI way? What is the advantage it brings?

If I want my app to run in a simple FastCGI environment (with the CGI protocol), this will not be possible anymore so I will be dependent on the Plack suite or create 2 versions: PSCI enabled and not PSGI enabled (this will not be much but still, 2 is worst than 1).

- Are all the $ENV variables available? (SCRIPT_NAME for example?)

- All the plack Middleware sounds much like externalized Catalyst modules. I don't really see what advantages it will bring to framework like Mojolicious for example (they will certainly never ever used any Middleware stuff from the Plack namespace as this is at the heart of their policy so they will just get access to the servers that implements this spec instead of using the normal CGI protocol) If you put them all back together, you get Catalyst.

So if you start to build a new framework from scratch, yeah, this might be nice. Everything has been done, you just pick what you want but else...

> - Why send back an array ref instead of using the CGI way? What is the advantage it brings?

If you design a fibonacci() function, would you make it print the result to STDOUT, or return the result as a return value?

If the specification is to print to STDOUT, a web server needs to make a trick to capture the output using tie, PerlIO or anything else, just like FCGI.pm does, and that's inefficient.

> - Are all the $ENV variables available? (SCRIPT_NAME for example?)

http://search.cpan.org/~miyagawa/PSGI-1.03/PSGI.pod#The_Envi...

> I don't really see what advantages it will bring to framework like Mojolicious for example (they will certainly never ever used any Middleware stuff from the Plack namespace as this is at the heart of their policy

See this post by the Mojolicious author, how to use Plack middleware for ANY Mojolicious based apps http://blog.kraih.com/mojolicious-and-plack

Also for Dancer: http://advent.perldancer.org/2010/22

> If the specification is to print to STDOUT, a web server needs to make a trick to capture the output using tie, PerlIO or anything else, just like FCGI.pm does, and that's inefficient.

I see. That's a valid point. So when I asked if by design the protocol would offer better performance, the answer is yes?

Is this inefficiency so bad that changing it to an array ref brings THAT much improvement though?

It was easy to change the output but I will have to create a thin wrapper around FastCGI/PSGI to make it transparent. something like this detection done in Mojo becomes necessary:

# PSGI (Plack only for now) return 'psgi' if defined $ENV{PLACK_ENV};

  # CGI
  return 'cgi' if defined $ENV{PATH_INFO} || defined $ENV{GATEWAY_INTERFACE};

well, that's not much work...

I'll continue porting the app and see how it behaves.

Thank you for your time.

Reply on news.ycombinator.com