3

I have exhausted my ability to find answers on the web for this one. I'm trying to install mod_perl on windows and there are many dead ends.

  1. Is mod_perl even what I'm looking for?***

    I have a collection of web apps used within my company's local network for database and file system interface. The web server runs Apache 2.2 and ActivePerl 5.16 using DBI, DBD::mysql, and CGI. The clients get their dynamic content via AJAX calls (jQuery.getJSON) to the Perl scripts using CGI parameters. The traffic is extremely light - only 4 or so users and only a few queries at a time here and there.

    The issue I'm having is that the latency is unacceptable for the nature of these apps. The delay is typically around 400ms, all waiting time. I have experimented with increasingly simplistic Perl scripts and believe all of the delay is the Perl interpreter. I've looked into FastCGI but as I understand this deals mostly with high traffic which is not my problem: it's the overhead of each low-traffic call. So it seems like an Apache-embedded Perl interpreter (as I understand mod_perl to be) would solve my overhead-related latency issues.

  2. How do you install it in a post Randy Kobes world?

    All resources I've found for installing mod_perl for my setup involve a server theory5x.uwinnipeg.ca formerly run by him and now defunct after his passing. ActivePerl ppm does not have any mod_perl built in packages and the website shows all build failed listings.

Here is an ActiveState community post explaining why there is no ppm.

I did find this resource that seems to have all the missing pieces but for Strawberry Perl.

So I'm left to think the only way to do this is to install from source, but I have no understanding of how to do this. I have zero familiarity with Linux and it seems like most of this stuff is geared toward it. Worse yet I have a 64-bit Windows XP and a Windows Server to install it on.

The other thing that crossed my mind is maybe I need to install some kind of distribution like XAMPP instead of putting together all the pieces myself. I'd be quite nervous to change course now and risk breaking my working but slow apps

robisrob
  • 940
  • 12
  • 23
  • Are you really saying that half a second is too slow for a response to a web browser? The advantage of `mod_perl` is that it keeps a Perl interpreter running continuously and calls your scripts as subroutines, removing the startup and compilation delay for each web query. If your analysis of the problem is correct then I think it (or FastCGI) is precisely what you need. [This page](https://perl.apache.org/docs/2.0/os/win32/install.html) describes how to install mod_perl – Borodin Jun 23 '15 at 20:51
  • For the nature of these apps a half second is painfully slow. For instance one of the apps presents test data - typical usage involves scrolling through entries rapidly and looking at the queried results for patterns and anomalies before approving the data. The desktop app that the web app replaces does this instantaneously using direct file access which was messy but very fast. This is a far superior solution but the latency is horrible now that we're used to the previous speed. – robisrob Jun 24 '15 at 16:40
  • Borodin the site you shared uses to the defunct server I mentioned in the question – robisrob Jun 24 '15 at 16:56
  • If you need something better than 400ms per transaction then your choice shouldn't have been a simple web app. It sounds very much like the basic design is wrong, and trying to find ways of reducing the consequences of a poor design isn't the right way to go about things. You say you're not a software developer and not in the loop on standard practice. That means it's not your job to ask this question – Borodin Jun 24 '15 at 17:10
  • Don't be so sure Borodin. We are a very small hardware company that has no foot in software development and I'm the best thing we've got. I've already advanced our capabilities significantly with my hackery and I know for certain I can get us the rest of the way there. So please save the condescension and move on if you can't help – robisrob Jun 24 '15 at 17:16
  • The more you tell me the more scary this sounds – Borodin Jun 24 '15 at 17:50
  • You should at least consider sending XHR (XMLHttpRequest) messages to avoid updating the web page every time the data changes – Borodin Jun 24 '15 at 17:59
  • I believe this is what $.getJSON is. The page is not reloaded. Otherwise the half second delay wouldn't be so noticeable. And you are right this place is scary – robisrob Jun 24 '15 at 18:10
  • @robisrob Is it really necessary to use Windows? I think it should be much easier to build Apache/mod_perl/DBD::mysql in Linux, and managing a virtual machine is no big deal. – Alex Tokarev Jun 27 '15 at 06:48

2 Answers2

6

Is mod_perl even what I'm looking for?

I hope not.

There are issues with mod_perl. Your Apache, mod_perl and perl need to all be built with compatible compilers and architectures so they can all be linked at run time. There will be no running of a 32bit Apache with a 64bit perl when you are using mod_perl. In my experience mod_perl should also be compiled against header files for your specific versions of both Apache and perl. Presuming you get all this secret sauce mixed up correctly, you are now running a web server that can be crashed by a poorly written perl script. But on the bright side, this is more efficient than common CGI.

After a few years of this madness, FastCGI was invented. By running as a persistent, but separate, process, the web server was able to achieve mod_perl (or mod_PHP, or mod_python) efficiency without the need for binary compatibility or the stability risks. Just think of the freedom! An Apache module that cares only about binary compatability with it's Apache host and can farm out tasks to Perl, Python, C or even Visual Basic. ( I just had an evil thought about trying to do web services with Forth or Lisp, but that would just be crazy.)

Running on a linux distro (or other canned XAMPP stack) can make setup and maintenance of mod_perl easier because they will distribute it in a package that has been compiled to work with the packages they supply of both Apache & perl. Unfortunately if you want to run with a version of Apache or perl that is not "official" to your distro, get ready to DIY. Even so, a distro's packages do not mitigate the stability issues inherent in running mod_(language-of-choice).

In any case, before you're up and running in your new configuration, your existing CGI scripts will need to be modified. You can choose to rewrite them to mod_perl, FastCGI, or PSGI/Plack standards. If you choose to rewrite to PSGI/Plack standards, then you can care much less about the specifics of your web server's current or future configuration.

How do you install it in a post Randy Kobes world?

The last link in your question appears to be spot on. Do you have a religious or PHB based reason to prefer ActivePerl over StrawberryPerl? In the end, mod_perl requires that it be built against your specific version of Apache and your specific version of perl. This will either involve compiling it yourself, somebody else wrapping up versions for multiple Apache/perl version combos, or somebody else wrapping up a single version and asking you to use their preferred versions of Apache & perl.

If you choose the mod_perl route and believe even slightly that server software should be kept up to date (XP? Seriously?), then be prepared to either roll your own or trust your 3rd party to keep you up to date. Of course, if you're a hit-and-run developer, well that frees up your choices considerably...

tl-dr:

FastCGI is your friend. Particularly if you are running Windows and like to keep server software up to date.

mod_perl works best when supported by a responsible distro or a responsible developer who is comfortable building it from it's source. ...repeatedly.

tjd
  • 4,064
  • 1
  • 24
  • 34
  • this is exactly the type of direction I was looking for. I think I will focus on fastCGI. I am not a software developer, I am not in the loop on what is "standard" practice, and don't have a ton of time to spend of these things which are basically ad hoc solutions for a very small company with a foot still decades in the past. While scoffing at our use of xp consider that this system replaces a foxpro database running in a DOS window that can't be used in win7. One of the apps actually replaces basic code that ran on a 1970s HP computer with a 1-line LED display – robisrob Jun 24 '15 at 16:51
  • @robisrob Please don't misunderstand my concern about the use of an OS that has been unsupported for over a year as a web server. Protecting an obsolete OS from compromise is not a trivial task. Even if you put in firewall rules to protect it from a direct connection from the big bad world, you still need to worry about the clients who are *supposed* to be running your service inviting in something unpleasant. In the end, an OS (and hardware?) upgrade will likely be less expensive. Of course this may require reeducating a 1970s era PHB. – tjd Jun 24 '15 at 17:20
1

It's been an eternity since I've installed mod_perl on Windows so I'm not sure I can help you with that.

But your understanding that FastCGI "deals mostly with high traffic" is not correct. Both FastCGI and mod_perl will offer very similar performance benefits, because both will execute your scripts with a persistent interpreter–eliminating the overhead of starting up perl and compiling your code on each request. Therefore, there is no reason not to give FastCGI a shot.

You might want to look at the PSGI/Plack API which allows you to write code agnostically that can run under vanilla CGI, FastCGI, mod_perl, or with a PSGI-aware server such as Starman, or uwsgi. All of these except for vanilla CGI offer a persistent environment that will reduce the overhead of executing your scripts.

Dondi Michael Stroma
  • 4,668
  • 18
  • 21