如何正确减少 mod_perl 的冗余请求数量？

Question

在一个相当大的遗留项目中，我将几个毛茸茸的模块重构为 Moose 类。这些模块中的每一个都需要数据库访问来（惰性）获取其属性。由于这些对象的使用相当频繁，我想减少冗余请求的数量，例如针对未更改的数据。

现在，我该如何正确地做到这一点？我有几种替代方案：

1. 通过一个角色在我的 Moose 类中实现缓存，将它们存储在 memcached 中，并在 5-10 分钟内过期（可能不是太困难，但对于惰性属性来说很棘手）更新：KiokuDB 可能会在这里提供帮助，必须阅读有关属性的信息
2. 迁移到 DBIx::Class （无论如何都需要完成）并在此级别上实现缓存（DBIC 可能会花费大部分时间）痛苦本身就消失了）
3. 以某种方式让我的对象在 mod_perl 进程中持久存在（不知道如何做到这一点:(）

你会如何做到这一点以及你认为一个明智的方法是什么？在对象或 ORM 上缓存数据是首选等级？

Answer 1

对#3 的简短回答是：不要使用“my”。您可能会这样做：

 use vars qw($object);
 # OR post perl5.6:
 # our ($object); 

 # create your object if it doesn't already exist
 $object ||= create_object;

 # Maybe reload some attributes if they have expired.
 $object->check_expires;

在处理程序中像这样创建的对象将仅在每个 Apache 子进程中共享，如果您每 5-10 分钟重新加载一次数据，这很好。任何只读的模块和对象都应该加载到 PerlPostConfigRequire 脚本中，以便它们在所有子项之间共享。

Answer 2

由于无论如何您已经要进行 DBIC，因此让此更改来解决它是有意义的。自行推出然后实施 DBIC 的意义不大，当维护人员发现您使用 DBIC 但使用自行开发的缓存时，他们会犹豫不决……“出于某种原因”。

不这样做的唯一原因是 (1) 如果您现在确实需要这种性能，并且您没有时间等待 DBIC 更改，因为我认为这将是相当广泛的。或者 (2)，如果您不确定是否真的要转到 DBIC。如果您没有对其进行调查并且正在执行大量自定义 SQL 而不是基本 CRUD，那么最终的投资回报可能会非常小。