Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

What if mod_perl is not an option?

by kiat (Vicar)
on Feb 04, 2004 at 09:14 UTC ( #326440=perlquestion: print w/ replies, xml ) Need Help??
kiat has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks,

Let's say you're developing a community site like this one that requires constant operations on the database (mysql) to insert, update and delete particular pieces of information e.g. time of login, updating of profile, etc.

You're not familiar with mod_perl and on top of that, your hosting company does not have mod_perl installed.

What options do you have? Will using the CGI/perl combination do?

I look forward to hearing your views and as usual, thanks in anticipation :)

updated: Thanks to all for sharing your views and experiences and giving advice generously. I'll go with the perl/CGI solution and will keep you posted of the outcome 8-9 months down the road after I've sufficiently tested the site.

Comment on What if mod_perl is not an option?
Re: What if mod_perl is not an option?
by borisz (Canon) on Feb 04, 2004 at 09:29 UTC
    You can use Perl/CGI and it may work for a while, but I recommend swap your ISP and consider using postgres.
    Boris
      Sorry, but I don not understand what's wrong with Perl/CGI that needs to be replaced by postgres (PostgreSQL). Perl/CGI is a way to make dynamic web-pages and postgres is a database. The one cannot replace the other, they have to work together. Or am I missing something subtle here?

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

        Perl/CGI is a way to make dynamic web-pages and postgres is a database. The one cannot replace the other, they have to work together. Or am I missing something subtle here?
        Yes, I suggest to use postgres with mod_perl. If this is really, really, really not possible, stay with CGI and mysql.
        Boris
Re: What if mod_perl is not an option?
by EvdB (Deacon) on Feb 04, 2004 at 09:32 UTC
    There is no reason that you could not use just simple CGI to do things that you can do with mod_perl. The only real difference is that mod_perl gives you a speed boost and easier access to apache's guts (rarely vital, often useful).

    I would suggest though writing your CGI apps in such a way that if you do need to move over to mod_perl, or get the chance to, you can do it easily. Essentially avoid all global variables and put as much as you can into modules. If you use CGI::Application then this is done for you to a large extent. If you don't want to use CGI::Application you can still borrow the idea of having CGI scripts that look like this:

    #!/usr/local/bin/perl use lib '/path/to/my/files/perl/'; use MyWebApp; MyWebApp->go();
    As an added advantage you give away very little to bad guys if the see the source to your CGI script as all the sensitive bits are in the module.

    As for database connections you will not be able to store them between requests but this is not likely to be a performance concern compared to other bottlenecks that exist (ie firing up perl each time) - worry about it if it becomes a problem.

    Update: Changed 'rarely needed' to 'rarely vital' in first line to be more accurate.

    --tidiness is the memory loss of environmental mnemonics

Re: What if mod_perl is not an option?
by Abigail-II (Bishop) on Feb 04, 2004 at 09:36 UTC
    What options do you have?
    Vote with your money and find a hosting company that satisfies your needs.
    Will using the CGI/perl combination do?
    Perhaps. Perhaps not. Perl can certainly deliver content using the CGI interface, that's not a problem. Resources might though.

    But if I had a site that required "constant operations" on a database, I wouldn't host it in an environment where I can't control the web server.

    Abigail

      Vote with your money and find a hosting company that satisfies your needs.

      Alas, often the developer will not have the luxury of this decision.

      There are a bunch of optimisations that can be made even if mod_perl is not an option; here are some ideas off the top of my head:

      • Streamline the design of your pages to be lightweight by relying on web standards and the bare minimum of images.
      • Consider the architecture of your application to eliminate redundant database connections, repetitive processing etc.
      • Think about generating static .html pages that are looked for first instead of dynamically outputting content on every request.

      mod_perl rules and I am not suggesting for a minute that there is an equivalent substitute but you should view your situation as an opportunity to learn about tweaking the best performance out of the resources you have.

      MB

      Update: amended `in the event that' to `even if' in my second paragraph following Abigail's (quite true) observation that my comments apply in the event that you do have mod_perl also.

        There are a bunch of optimisations that can be made in the event that mod_perl is not an option;
        Whether or not you are using these optimizations is orthonogal to whether you have mod_perl at your disposal or not. Lightweight pages are easier on both the server, the client, and the network in between regardless whether you use CGI or mod_perl. Eliminating redundant database connection is a good idea with both mod_perl and CGI. Static HTML is always faster, faster than mod_perl and faster than CGI.

        Abigail

        I just want to add my vote of reiteration on the eliminating redundant db connections. I once inherited a cgi app that took forever to load - looking at the source, I realized that part of the speed problem was that there were more than a dozen db based items, all of them run independantly of the other. And the infamous "works fine in development" didn't cut it - dev only had 3 users, vs a few hundred thousand a day in the real world.



        "I have never written bad code. There are merely unanticipated features."
Re: What if mod_perl is not an option?
by skx (Parson) on Feb 04, 2004 at 10:06 UTC

    I've put together a small site for fun, focussing upon Valentines Day - and aimed at users of LiveJournal.

    Given that the site is only going to exist from the 1st of February until the 14th I've not been too worried about performance.

    Despite that the site has profiles, selections, etc, and is all run from the CGI::Application, CGI::Session and DBI modules.

    It seems to be scaling fairly well so far.

    LiveJouranl Valentine System 2004.

    Steve
    ---
    steve.org.uk
      Would you be interested in sharing your code?

      I'm doing a lot of CGI programming lately with CGI::Application and DBI and just recently mixed in the CGI::Session stuff. I'm always looking for examples to read and learn from.

      Thanks

        Sure, the source is available for download if you want it.

        There may not be too much documentation, and stuff, but it's pretty good.

        Any questions mail me.

        Steve
        ---
        steve.org.uk
Re: What if mod_perl is not an option?
by OhReally (Monk) on Feb 04, 2004 at 11:23 UTC
    Hello.
    You could try SpeedyCGI. I've just looked at the docs and it seems possible(may not be easy though) to install it without root access.
    I have used it and it produces a great speedup and will probably help you in reusing db handles etc..
    The only other requirements is to make sure your programs are using "Use strict".
    hth.
Re: What if mod_perl is not an option?
by jdtoronto (Prior) on Feb 04, 2004 at 14:39 UTC
    For pretty obvious reasons most hosting companies will not install mod_perl on shared machines. But their are one or two specialist places that will, for example baremetal.com offers users their own Apache process with mod_perl for $30US per month. Other than that, you will be looking for a dedicated server.

    Being familiar with mod_perl means nothing. I run my own work under mod_perl, but I know nothing (well pretty much nothing!) about it. Oh I might not be getting the best performance, or the greatest flexibility, but hey, I have time to learn in the future. Don't be frightened of mod_perl.

    Well written Perl/CGI will work well, but eventually it will bog down. I have one app of around 25,000 lines written in plain old Perl/CGI. With 2,500 users and handling about 300,000 emails per day it bogs down. With about 15 hours work eliminating some globals and testing it under mod_perl it has a whole new lease on life. It used to take two servers to keep up, now it is on one mod_perl machine and has capacity to spare.

    Good luck!

    jdtoronto

Re: What if mod_perl is not an option?
by zentara (Archbishop) on Feb 04, 2004 at 16:27 UTC
    Depending on your server, you might be able to use FastCGI, FCGI

    I use it, but it takes a few changes in your apache configuration file. It works by "pre-creating" a pool of ready-to-go instances of your CGI script. I like it, and it just uses plain old CGI scripts.

Re: What if mod_perl is not an option?
by archangelq (Novice) on Feb 04, 2004 at 18:56 UTC
    As an alternate suggestion for getting mod_perl running cheaply, I'd suggest a Virtual Dedicated Server. There are a fair number of hosting places doing just that, and it means you get root access to a partition of space, generally for around $15/month to start. That's even compairable to a lot of other hosting services. I've seen both Linux and FreeBSD VDS hosting out there.
Re: What if mod_perl is not an option?
by Trimbach (Curate) on Feb 05, 2004 at 03:59 UTC
    You may be able to get decent results without resorting to mod_perl, depending on what your site does. I co-run a plain-perl/MySQL website with over 200,000 users pulling data from a (growing) 1.5 million row table. We're talking about 30,000-40,000 database hits per day and the site runs with almost no delay most of the time. Neither the database nor the code is very complicated, and the data that's accessed is very small (about 100 bytes per access) but it's survived 300% growth without any noticeable degradation in speed in this environment.

    Of course, we didn't know that when we started, and our ISP has mod_perl available in case it ever becomes an issue. Bottom line is you may not need mod_perl for what you're doing, so if you can't easily change ISP's you might still be ok.

    Gary Blackburn
    Trained Killer

Re: What if mod_perl is not an option?
by toma (Vicar) on Feb 05, 2004 at 05:55 UTC
    I suggest that you do an experiment to see how your site is going to scale. Set up test cases to exercise a database loaded with fake data, and create a dummy mock-up of your content.

    Use LWP to emulate various levels of user load on your site. Create a graph that shows page-load time versus the number of users. This is a great way to evaluate different coding approaches and modules, not just mod_perl.

    You could also create your own little network to experiment with the performance improvement that you expect to get from mod_perl.

    It's great to be able to go into a meeting and say something along the lines of, "We can serve 500 users with the CGI setup, but when we start to approach this limit, let's reconsider and evaluate a mod_perl approach, which I think will serve at least 5000 users. After all, I was able to emulate 3000 users on a P300 that I picked up at a garage sale."

    It's also fun to offer load testing services for competing approaches! I have offered this several times, and no one has ever taken me up on it.

    It should work perfectly the first time! - toma

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://326440]
Approved by EvdB
Front-paged by ysth
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2014-11-22 03:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (118 votes), past polls