learn_forever has asked for the wisdom of the Perl Monks concerning the following question:

Hi !

I know Lot of us may just shrug this question off, as they never have to deal with this type of hosting. But I am a small time web developer, who believes in perl and does not have an expertize to call my self perl expert,

I always hear mod_perl helps performance, embperl and other technologies improve templating and all other stuff such as session management etc using right apache modules.

How a developer who is using virtually hosted domain space (where he has his own private CGI-BIN ) but does not have root access or access to apache config files to define modules at startup or configure redirects etc can take benefit of mod_perl? Most of the domain hosting ISPs of virtusl domain servers claim now a days that they have mod perl and claim that they can install any CPAN suppoted module upon request. But does a shared account can make use of it?

Is there any way the advantage of mod_perl can be taken even in the environment I described earlier or it is available to richer guys who can afford their own web servers only? In that case would perl monks suggest me that should I switch to something like php just for performance ? If not can someone show me a simple example how mod_perl can be utilised even in shared domain space?

I am not sure if this is a right question so I am ready to discuss more if someone wants details.

Thanks
  • Comment on Mod Perl Usage on Virtual hosted domains

Replies are listed 'Best First'.
•Re: Mod Perl Usage on Virtual hosted domains
by merlyn (Sage) on Oct 19, 2002 at 20:37 UTC
    The problem is that you really can't have a "shared" mod_perl if you don't trust who you are sharing it with.

    For example, I could execute the following code in my module: 

    BEGIN {
  *strict::import = sub { die "ho ho ho" }
}

    [download]
    And now your code when it loads with the nearly-required use strict will execute my trojan horse.

    There's no real way to protect against that. One shared persistent interpreter is one shared persistent interpreter.

    You can run mod_perl in the "virtual host" solutions where each user has a completely independent Apache process group, sharing only the CPU.

    But don't count on a mod_perl solution where you and others are all sharing the same Apache processes. It won't happen, for all the right reasons.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]
[d/l]

      What I've always wondered is why mod_php can be offered on shared solutions, while there is no way mod_perl could. Are the PHP folks being more clever, or just not talking about security? If they're being clever, why can't we? And if we can, why don't we do it? If mod_perl could easily be offered for virtual domain hosting solutions, it would probably put a dent in the proliferation of PHP.

      (To abate the flames, I don't mind PHP, the same way I don't mind shell scripts. But I wouldn't use either for anything complex.)

      Makeshifts last the longest.

[reply]
        Perhaps because it isn't really, or only in a limited fashion (with lots of "extensions" disabled, giving only a very lite version of php)?

        I doubt they're being more clever, it's just that their product/language is lots simpler.

        I will now quote http://archive.develooper.com/advocacy@perl.org/msg01553.html 

        Description              Perl  PHP

Namespace management     Y    N 
File-scope globals       Y    N 
Regular expressions      Y    Y 

OOP support              Y    N(2)
Run time code mutability Y    Y   
Extensive lib collection Y    Y(4)

Closures                 Y    N   
anonymous subroutines    Y    N   
automatic code creation  Y    N   

Notes:
 (2) PHP support for objects is not much different than C++ support for
 (4) Not quite extensive, but it's getting there - PEAR is only a year or
     so old.
        Since there is no way in perl to prevent a program from modifying `import' among other things, you can't share a perl process among different users.

        update:
        Also, perl's regex engine is a "beast", and there exist some race conditions (sorry, I don't got a link handy to a discussion), and PHP just uses PCRE, which is Perl Compatible RE, but not quite Perl re ( and lots of features in the current perl re engine are **experimental**)

         
        ______crazyinsomniac_____________________________
        Of all the things I've lost, I miss my mind the most.
        perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

[reply]
Re: Mod Perl Usage on Virtual hosted domains
by perrin (Chancellor) on Oct 19, 2002 at 20:56 UTC
    Most (all?) ISPs do not offer mod_perl on shared accounts. If yours does, you have to ask them these questions. No one else here is going to know how they've set it up.

    If you can't get mod_perl but you need more performance, you should look at using SpeedyCGI (now called PersistentPerl), which does not have the same issues with sharing.

[reply]

Back to Seekers of Perl Wisdom