Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

multithreaded web application server in perl

by hackmare (Pilgrim)
on Dec 09, 2002 at 14:25 UTC ( [id://218522]=CUFP: print w/replies, xml ) Need Help??

Replies are listed 'Best First'.
•Re: multithreaded web application server in perl
by merlyn (Sage) on Dec 09, 2002 at 15:50 UTC
Re: multithreaded web application server in perl
by perrin (Chancellor) on Dec 09, 2002 at 16:23 UTC
    The main advantage is that there is no cgi interface and no dependency on Apache (as the system is up all the time, there is no compile problem and no mod_perl complication).

    Hmmm, how is not having a CGI interface an advantage? You certainly don't want to use the CGI interface for anything that has to be fast, but it's still nice to have one for legacy scripts. What is this compile problem and mod_perl complication you speak of?

    The main dissadvantage is that all the details (ssl handling, authentication, authorisation, etc) have to be worked out through the application logic or through a proxy, and that since there is no cgi interface, all queries need to structures like a branch, with only the leaf being free text and the branch nodes being predermined.

    It looks to me like you would have saved a lot of effort by using mod_perl (or FastCGI or PersistentPerl).

      When failings of Perl are enumerated as a reason not to use it, on top of the list you often find the dependency on mod_perl, and the fact that you run all the mod_perl as the same user and that all the mod_perl jobs running share the same memory space(or something like that). Of course, second is the fact that you don't use mod_perl and therefore have no state and run slowly.

      In short, while mod_perl is handy to have for binding to Apache, it is also a liability inasmuch as that it can bring down an entire website if something goes Very Wrong. And not using it is often the Kiss Of Death.

      I have never used fast_cgi, and therefore can not comment on it.

      After Perl's problems with mod_perl, the next attack on perl applications is the use of the cgi interface. As a matter of fact, the demo site above was designed to client specification that the url be path based and not cgi-like. I mean, it's so polarized that lots of us end up faking it by using Apache's mod_rewrite ore equivalent.

      There's no denying the weaknesses of building your own server from the ground up, and I am sure many people see it as blasphemy, given Apache's excellent capabilities.

      However, I have found that Apache and Perl don't support my needs for bidirectional interaction such as n-user games through the browser using SVG due to the overhead Apache imposes on the whole process. I do much better keeping everything in the base thread's context, minimizing IPC comms and DB interaction. It allows me to have player 1 see the actions of player 2 without relying on an update and 2 selects on a database, which kills performance (I typically need better than 1 connection per second per player for n-user arcade-type scenarios)

      With HTTP::Daemon, and Net::SSLeasy you can generate nice solid connections, maintain state very tightly with a minimum of third-party help from Apache, and keep everything tightly connected within a single instance. The performance is much higher than anything I've achieved with mod_perl and a database.

      And I have found that web applications are very specific in their IO and functionality requirements and very much like the idea of a stand-alone system that does not require anything other than itself to run. Simply in matters of reduced dependencies and simplified configuration, this is a huge work saver for me.

      IMHO, Maybe it is time to take a look at the important features of Java (such as the servlet) and take a lesson from them.

      And it was really not much effort. Implementing the threaded listener takes about 75 lines. The security manips take about 50 lines, and the application data take about 400 lines total. I'll pay 125 lines in headache (especially if it is always the same) to get rid of the 99% of Apache I don't need. And if I want a proxy to handle the port 80 connection then I just have to put in a handler for it. So far I think it's a good model that I can't touch with mod_perl. Althoough maybe I need to take another at fast_cgi.

      Hackmare

        All of the modern approaches to web development (Java servlets, PHP) have the same issues around possibly crashing the server that mod_perl does, because they all run the application code as part of the application server process. Even if you do write something that crashes, it only crashes the current process, not the whole server. Correct use of mod_perl involves separating the serving of static images and HTML from the dynamic mod_perl part (using a reverse proxy), so there is no possibility of breaking the non-mod_perl sections of the site.

        Using the CGI interface is a bad idea when you have the option of using something with better performance, but using path info vs. query args has nothing to do with the CGI interface. You can use path info from a CGI, even without mod_rewrite. Moreover, having support for legacy CGI in a server doesn't hurt any applications that aren't using CGI.

        You don't need to use a database to share data between mod_perl processes. You can use something like IPC::MM or MLDBM::Sync and get hundreds of read/write ops per second. I suspect it will scale better than the threaded HTTP::Daemon approach you're using. (What are you using exactly? HTTP::Daemon is not threaded.)

        "Maybe it is time to take a look at the important features of Java (such as the servlet) and take a lesson from them."

        Have you looked at POE yet? How about Wombat? (a servlet engine for Perl)

        Update: PodMaster asked me to write up something on Wombat. I have two finals this week, so i'll start next week sometime. :)

        jeffa

        L-LL-L--L-LL-L--L-LL-L--
        -R--R-RR-R--R-RR-R--R-RR
        B--B--B--B--B--B--B--B--
        H---H---H---H---H---H---
        (the triplet paradiddle with high-hat)
        
      Page didn't load the image at all. It didn't do anything except show some links. You may need to check your code, it looks broke 12-15-2002

        Thanks fot the notice.

        The page was down at the time due to a reboot. Since it's a daemon, it needs to be restarted when I reboot my box, and I dont have it set up as a service yet. So sometimes the server does not answer.

        hackmare.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: CUFP [id://218522]
Approved by diotalevi
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2024-03-28 17:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found