我用尽我想在网上找到了这一项上的答案的能力。 我试图在Windows上安装mod_perl的，有许多死角。
甚至就是我在寻找的mod_perl？***
我有我的公司的本地网络，数据库和文件系统的接口中使用网络应用程序的集合。 Web服务器上运行的Apache 2.2和5.16的activeperl使用DBI ， DBD::mysql ，和CGI 。 该客户得到通过AJAX调用（它们的动态内容jQuery.getJSON ）使用CGI参数的Perl脚本。 在这里和那里的时间只有4个左右的用户，只有少数查询 - 交通极为清淡。
我遇到的问题是，延迟对这些应用程序的性质是不可接受的。 延迟通常约为400毫秒，所有的等待时间。 我已经试验了越来越简单的Perl脚本，并相信所有的延迟是Perl解释器。 我已经研究过的FastCGI但据我所知这主要涉及高流量这是不是我的问题：这是每一个低流量调用的开销。 因此，它似乎是一个Apache的嵌入式Perl解释器（我的理解mod_perl的是），将解决我的开销相关的延迟问题。
你如何安装它后兰迪科贝斯世界？
我已经找到了我的设置安装mod_perl的所有资源，包括服务器theory5x.uwinnipeg.ca以前由他跑，现在他的传球后解散。 的activeperl PPM没有内置任何的包和的mod_perl 网站显示所有构建失败列表。
这里是一个ActiveState的社区文章，解释为什么没有PPM。
我发现这个资源 ，似乎有所有缺少的部分，但对于草莓的Perl。
所以我留下来想做到这一点是从源代码安装的唯一途径，但我不知道如何做到这一点的认识。 我有零熟悉Linux和它似乎像极了这个东西朝它为目标。 更糟糕的是我有一个64位的Windows XP和Windows服务器来安装它。
掠过我脑海的另一件事是，也许我需要安装某种分布像XAMPP，而不是放在一起所有的作品我自己。 我会很紧张，现在改变航向和风险打破我的工作，但是进展缓慢的应用程序
是的mod_perl甚至我在寻找什么呢？
我希望不是。
有与问题mod_perl 。 你Apache ， mod_perl和perl需要都兼容的编译器和架构来构建，使他们都可以在运行时被链接。 将不会有一个32位的Apache与当您使用的mod_perl 64位的perl的运行。 根据我的经验mod_perl也应该反对的头文件编译为你的两个特定版本 Apache和perl 。 假设你得到这一切的秘密武器混合正确，你现在正在运行，可以通过一个写得不好的Perl脚本崩溃的Web服务器。 但光明的一面，这是比普通CGI更有效率。
经过这几年的疯狂，FastCGI的被发明。 通过运行为持续性，但自成一体的过程中，网络服务器是能够实现的mod_perl（或mod_php，并且，mod_python的或），而不需要二进制兼容性或稳定性风险的效率。 试想自由的！ 即只关心它的二进制兼容性的Apache模块是Apache的主机和可耕种了任务，Perl，Python和C或甚至Visual Basic中。 （我只是有关于试图与第四或Lisp的做Web服务的一个邪恶的念头，但这仅仅是疯了。）
运行在一个Linux发行版（或其他罐头XAMPP堆栈）可以设置而 mod_perl的维护非常简单，因为他们将在已编译他们同时提供的Apache和Perl的的包工作包其分发。 不幸的是，如果你想用一个版本的Apache或Perl的不是“官”到你的发行版上运行，准备自己动手做。 即便如此，一个发行版的包不减少在运行mod_个（语言的选择题）所固有的稳定性问题。
在任何情况下，你起来，在新的配置运行前，现有的CGI脚本将需要进行修改。 您可以选择将其改写为mod_perl的，FastCGI的，或PSGI /普拉克标准。 如果您选择重写PSGI /普拉克标准，那么你可以关心你的web服务器的当前或未来配置的具体情况要少得多。
你如何安装它后兰迪科贝斯世界？
在你的问题的最后一个环节似乎即期。 你有一个宗教或PHB基于理由，更喜欢的activeperl超过StrawberryPerl？ 最后，mod_perl的要求 ，这对你的Apache的特定版本和你的Perl的特定版本来构建。 这两种方法，一是你自己编译它，别人结束了版本的Apache的多/ perl的版本连击，或别人结束了一个版本，并要求您使用Apache的Perl和他们的首选版本。
如果你选择了mod_perl的路线，相信甚至略有该服务器的软件应保持最新（XP？真的吗？），然后准备或者推出自己还是信任你的第三方，让您及时更新。 当然，如果你是一个打了就跑的开发，很好，大大节省了您的选择...
TL-DR：
FastCGI的是你的朋友。 特别是如果你运行的是Windows，并希望保持服务器软件是最新的。
当一个负责任的发行或一个负责任的开发商是谁自如地构建它从它的源支持mod_perl的效果最好。 ...反复。
它是一个永恒的，因为我已经在Windows上安装mod_perl的，所以我不知道我可以帮你。
但是，你的理解是，FastCGI的“交易大多与高流量”是不正确的。 双方的FastCGI而mod_perl将提供非常相似的性能优势，因为两者将执行脚本一个持久的解释，消除启动Perl和对每个请求编译代码的开销。 因此，没有理由不给FastCGI的一个镜头。
你可能想看看PSGI /普拉克API，它可以让你不可知的是写代码可以在香草CGI，FastCGI的，的mod_perl，或者用PSGI感知服务器，如接龙，或uwsgi运行。 所有这些，除了香草CGI提供一个持久的环境，这将减少执行脚本的开销。
