相关疑难解决方法(0)

我支持需要低延迟(每个消息处理<300微秒)的Java消息传递应用程序.但是,我们的分析显示Sun Java虚拟机最初运行缓慢,并且在前5,000条消息之后加速.前5,000条消息的延迟为1-4毫秒.在大约前5,000个后,后续消息的延迟约为250微秒,偶尔会有异常值.

通常理解这是Java应用程序的典型行为.但是,从业务角度来看,告诉客户他们必须等待JVM"热身"才能看到他们所要求的性能是不可接受的.在处理第一个客户消息之前,应用程序需要"预热"

JVM是Sun 1.6.0 update 4.

克服这个问题的想法:

1. JVM设置,例如-XX:CompileThreshold =
2. 添加组件以在启动时"预热"应用程序,例如通过应用程序发送"假消息".
3. 在应用程序启动时静态加载应用程序和JDK类,以便在处理客户消息时不从JAR加载类.
4. 一些实用程序或Java代理完成上述两个想法中的一个或两个,这样我就不必重新发明轮子了.

注意:显然,对于这个解决方案,我正在考虑所有因素,包括芯片拱,磁盘类型和配置以及操作系统设置.但是,对于这个问题,我想集中讨论如何优化Java应用程序并最大限度地减少"预热"时间.

我有一个高流量的网站,我使用休眠.我还使用ehcache来缓存生成页面所需的一些实体和查询.

问题是"并行缓存未命中",长期解释是,当应用程序启动并且缓存区域很冷时,每个缓存区域被不同的线程多次填充(而不是仅一次),因为该站点被许多用户击中同时.此外,当某些缓存区域无效时,由于相同的原因,它会被重新填充多次.我怎么能避免这个？

我设法通过向hibernate.cache.provider_class提供我自己的实现,将1个实体和1个查询缓存转换为BlockingCache,但BlockingCache的语义似乎不起作用.甚至最糟糕的是BlockingCache死锁(块)和应用程序完全挂起.线程转储显示在get操作上阻塞处理在BlockingCache的互斥锁上.

那么,问题是,Hibernate是否支持这种用途？

如果没有,你如何在生产中解决这个问题？

编辑:hibernate.cache.provider_class指向我的自定义缓存提供程序,它是SingletonEhCacheProvider的复制粘贴和start()方法的结尾(在第136行之后)我这样做:

Ehcache cache = manager.getEhcache("foo");
if (!(cache instanceof BlockingCache)) {
    manager.replaceCacheWithDecoratedCache(cache, new BlockingCache(cache));
}

这样在初始化时,在其他人触摸名为"foo"的缓存之前,我用BlockingCache来装饰它."foo"是查询缓存,"bar"(相同的代码但省略)是pojo的实体缓存.

编辑2:"似乎不起作用"意味着最初的问题仍然存在.由于并发性,缓存"foo"仍然使用相同的数据重新填充多次.我通过使用10个线程的JMeter强调网站来验证这一点.我希望9个线程阻塞,直到第一个请求"foo"数据完成它的工作(执行查询,在缓存中存储数据),然后直接从缓存中获取数据.

编辑3:可以看到对此问题的另一种解释https://forum.hibernate.org/viewtopic.php?f=1&t=964391&start=0但没有明确的答案.