Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Won't you end up with something pretty similar to lighttpd + FastCGI?
    • Not really.

      Say you want to build an app - you don't want to fuss about deployment just yet. With this you can just download it, and run "./axkit" and start building your app. No downloading extra httpds and configuring them.

      When you want to deploy, you can either deploy standalone like this without an extra httpd, or you can stick lighttpd or apache up front, giving you whatever extra features you might need from those (e.g. SSL).

      All this is easier to debug than FastCGI, and can utilise proxy caching at the
      • I have read the original article and I think he's full of it. FastCGI's protocol is too hard to understand, so let's write an HTTP server? It doesn't make any sense. Writing a good network server is much harder than figuring out how to debug FastCGI hiccups.

        It sounds to me like you're solving a different problem -- how to have a quick dev server. Most projects are doing this with HTTP::Server::Simple. I personally think it's a bad idea to develop on a server that isn't identical to what you deploy on,
        • It's not just about hiccups with FastCGI. I don't know about all the ins and outs of that protocol, but can you make the frontend cache the results with FastCGI if you send the right http headers? If not then that's a huge reason right there.

          I also wanted a server that can scale decently if you need it to. I don't believe HTTP::Server::Simple (or anything currently on CPAN, with the possible exception of Perlbal but that doesn't do dynamic content) is scalable.
          • The caching issue is probably dependent on the FastCGI implementation. With apache 2 and the new caching stuff, it should be possible. Not sure about lighttpd.

            HTTP::Server::Simple doesn't scale at all. It's just a quick dev server.

            The main difficulty in using a single-threaded server for dynamic content generation is how you handle slow things that are hard to split up, like database queries. I talked to a couple of people at OSCON (Stas Bekman, Artur Bergman) about this and they were both following the
            • by Matts (1087) on 2006.07.31 12:39 (#49112) Journal
              It seemed very similar to a lighttpd/FastCGI model ultimately.

              Sort of - except there's a reason smart people are going down this single-threaded server route - even if you have some bits hanging off as other daemons, ultimately your scalability is still better. And with all the AJAX stuff going on now, high parallelism is becoming even more of a big deal.