2008-10-23 107 views

回答

8

先让它工作,然后让它快速。如果你不需要缓存,不要实现它。

+0

同意。性能不会是一个问题,直到它成为一个问题... – 2008-10-28 16:47:57

2

我对Hibernate的使用一直存在于另一个框架(例如Spring)的上下文中,其中启用缓存几乎是微不足道的。一些这些项目已经通过ehcache对一些关键的域类使用缓存。

话虽如此,这是我们必须在资源之间进行权衡的另一个领域 - 平衡检索性能和内存使用。没有测量的优化一再被证明是不好的练习。

收集有关应用程序性能的度量标准。然后决定如何解决慢点。缓存可能是您最担心的问题。

3

在我所使用的应用程序中,数据库在多个应用程序之间共享,其中一些应用程序根本不是Java。因此,在这些情况下,二级缓存不适合我,因为我永远不知道其他应用何时可以更新数据库。

1

如果你做正确的事情(小心的选择N + 1等),性能应该是可以接受的,而不绝大多数情况下

1

的二级缓存,我们首先尝试没有,只有使用它的时候的表现下跌降落。

0

引用着名的Donald Knuth的话:“程序员浪费大量时间思考或担心程序中非关键部分的速度,而这些效率的尝试实际上在调试和维护时会产生强烈的负面影响我们应该忘记小效率,大约97%的时间:不成熟的优化是万恶的根源,但我们不应该把这个关键的3%放在一边。“

如果您看到性能问题,只有这样您才能开始优化。如果需要的话,你应该只优化最大的瓶颈,并按照你的方式进行工作。

但是,在大多数情况下,在NHibernate中实现这种优化对调试和维护的影响可以忽略不计,而且通常可以通过非常少的代码添加来实现。

如果您广泛依赖延迟加载,只读表,不必担心与不使用NHibernate的应用程序并发,性能是一个问题,并且您对如何使用二级缓存进行优化(这意味着您已经知道这个问题的答案),那么你应该使用二级缓存。

0

现在有一个与hibernate相关的特定问题。臭名昭着的LazyInitializationException。基本上,您需要初始化所有惰性关联,而实体则附加到持久性上下文。两种方法:

  1. 手动访问关系以强制加载它们。
  2. 使用指定联合抓取的查询。

这两种方法会导致完全不同的代码段,因此将一个代码移植到另一个代码段可能是一项相当不错的工作。问题在于方法1。在不使用二级缓存时会导致大量查询,因此人们可以决定使用方法2,这会导致发烧查询。但是,稍后您打开第二级缓存时,方法2中的查询不会从缓存中加载数据,但会将结果实体放入缓存中,从而使查询执行速度比没有缓存时慢。这会导致复杂的事情,比如不得不使用查询缓存。

因为,它似乎更好的方法,我(在这种特殊情况下)在第一次为所有实体,通常是微不足道的,以使高速缓存,然后禁用它的实体,你不需要它作为开发流程的上。

相关问题