Hiya. I', using Gentoo linux. it seems that i cannot emerge/install mod_perl with a threaded apache2 so i would like to know what's the pros and cons of using the worker module of apache2 with cgi-perl and using the prefork module of apache2 with mod_perl
what's faster? what takes less resources? security wise, is there any difference?
thanks!
IMHO, prefork+mod_per would be much faster, but asking in mod_perl mailing list would give you more exact answer
On Linux, use prefork apache w/ mod_perl. The Threaded MPM is a huge win for Win32 users, where process creation is expensive. On linux fork() is a pretty cheap call. However Mod_perl2 devs have gone through great effort to make mod_perl2 work with apache2 + threads, but the thread model in perl is a bit memory-intensive.
We develop a big mod_perl app, and if we had to recreate it today, I'd probably recommend one of the various frameworks and use FastCGI or PSGI. Using FCGI or a frame work with native PSGI/FCGI capabilities lets you have your choice of front-ends (nginx, lighttpd, apache2). You can chroot your app and lower it's privledges (it only needs a socket to talk to your front end). If you make your app use mod_perl2, your pretty much married to Apache2.
Modperl is perfect adaptor for Catalyst, just the same way as Modpython and Modwsgi are both for Django, and modphp is for Cakephp, whereas Modruby is being debated as better or worse than cgi, fcgi and (Modrails/Modpassenger/Modlocomotive) are for Rails especially while using the threaded mode (but there are Modrake and proxying Mongrel app-server as alternatives). To avoid the disadvantages and gain only advantages then always use the forked mode. I'm using referring to only mvc's of other programming languages which are rails-inspired: i.e. Catalyst, Django, Cakephp and Rails.
In my opinion, the multiforked mpm-itk-mode is best, followed by multithreaded mpm-event-mode, then comes the single forked mpm-prefork-mode, and then last comes the single threaded mpm-worker-mode.
I found that for some programming languages their respective apache2-adaptors such as mod-php and mod-tcl specifically runs only on the prefork mode and not even in the itk mode, while mod-ruby is still only in linux-apache2 and yet to make it into windows-apache2.
But, fortunately mode-perl, mod-python, and mod-ruby are more versatile enough and can be made to run in all four modes -- libapache-mpm-worker mode, libapache-mpm-prefork mode, libapache-mpm-event mode and libapache-mpm-itk mode. This is a good news for perl, python and ruby users, but of course even in case of all three's adaptors the forked mode is faster, more versatile and conflict-free than the threaded mode. And one thing is for sure: all these adaptors are designed to be run faster than cgi, and arguably as fast as fcgi (fastcgi).
I use the itk (multiforked) mode, even if it means that I will be missing some softwares which require prefork (single forked) mode.
I had always preferred the itk-mode in Ubuntu and never opted to install applications which require the prefork-mode as the prerequisite. Some distros such as Sabayon, which is Gentoo flavor, installs apache2 in the worker mode by default. But this we can always change by editing the apache system configuration file and uncomment the lines containing itk (and comment the lines for worker) followed by recompiling and restarting apache2. So, whatever applies for Sabayon should hold good for Gentoo also. Sabayon and Gentoo installs all prefork-dependent or worker-dependent softwares, but while configuring them, only those whose dependency is fulfilled by the system should run.
The one which is hit very hard are some of the php based frameworks (required for content-management-systems) which fail to run. The only php framework which can run under itk, event (and maybe worker) mode is the cake-php, which unfortunately very few use. I think that even the more well-known horde (php) framework should also work.
Another proof that threads are worse than forks is by looking at the number or conflicts which two or more webserver-adaptors have wrt each other and the system, as we see in windows.
In case of windows, apache2 configures with the worker-mode, as prefork and itk modes are not possible, but the event-mode should be very much possible. So, switching to apache2 event (multithreaded) mode should solve most of the problems. But apache2 is very flexible and customizable for modperl (and hence perl-catalyst mvc), modpython (and hence django mvc), but windows-modruby is yet to be stable, its equivalent known as modpassenger (modpassenger -- linux, modrails -- windows, locomotive -- macosx) exist in abyss-webserver or lighttpd-webserver (and hence rails mvc).
Precaution is: If the system is windows then the before installing MVCs of Perl/Python/Ruby/PHP/Tcl, make sure that everything is configured only with one single webserver only -- either apache2 or lighttpd or maybe cherokee. If you intend to use rails with abyss, modrails then make sure that the drupal/jhoomla configuration with wamp, modphp should not be present -- otherwise sometimes the windowsxp's default windows-shell may crash (you can still recover by using windowsxp with alternate-shells such as reactos-shell, emerge-desktop, sharp-enviro, bblean-blackbox, etc with alternate file-managers such as ros-explorer, cubic-explorer, ultra-explorer, etc -- provided any user don't mind adapting and using the same os with a differently looking desktop-shell and file-manager).
In windows, thus modrails conflict with modphp (until a stable modruby gets available), and that the asp based windows-desktop-shell (windows network object model environment) could hold only one at a time, whereas the alternate-shells written in codeblocks (reactos and emerge-desktop) do not crash, while those written in delphi (sharp-enviro) partially crash, but a lazarus remake of sharp-enviro should not crash.
Thus one of the reason Linux web technology is a much bigger variety and yet successful is due to the advantages of forked mode over the threaded mode. The windows web technology still revolves by and large over fewer players and some few opensource technology after doing lot of hard work.
Just some additional info, we just dumped mod_perl on Win32 and switched to PSGI using Plack. There's a compatibility layer for CGI::Application that's working very nicely for us. Catalyst is switching/has switched to PSGI as well.
