六安火车站网站,怎样在绍兴e网做网站,wordpress外贸发布接口,桂林楼盘网大多数性能问题可以通过几种不同的方式解决。 多数人都容易理解和应用许多适用的解决方案。 一些解决方案#xff0c;例如从JVM管理的堆中删除某些数据结构#xff0c;则更为复杂。 因此#xff0c;如果您不熟悉此概念#xff0c;我建议您继续学习我们最近如何减少应用程序… 大多数性能问题可以通过几种不同的方式解决。 多数人都容易理解和应用许多适用的解决方案。 一些解决方案例如从JVM管理的堆中删除某些数据结构则更为复杂。 因此如果您不熟悉此概念我建议您继续学习我们最近如何减少应用程序的延迟以及如何将Amazon AWS费用减少一半。 我将从解释需要解决方案的上下文开始。 如您所知 Plumbr密切关注每次用户交互。 这是使用部署在处理交互的应用程序节点旁边的代理来完成的。 这样做时Plumbr代理正在从此类节点捕获不同的事件。 所有事件都发送到中央服务器并组成我们称为事务的事务。 事务包含多个属性包括 交易的开始和结束时间戳 执行交易的用户的身份 执行的操作将项目添加到购物车创建新发票等 该操作所属的应用程序 在我们面临的特定问题的背景下重要的是概述仅将对实际值的引用存储为事务的属性。 例如不是存储用户的实际身份例如电子邮件用户名或社会保险号而是在交易本身旁边存储对此类身份的引用。 因此事务本身可能如下所示 ID 开始 结束 应用 运作方式 用户 1 12:03:40 12:05:25 11 222 3333 2 12:04:10 12:06:00 11 223 3334 这些参考与对应的人类可读值对应。 通过这种方式可以维护每个属性的键值映射以便将ID为3333和3334的用户分别解析为John Smith和Jane Doe。 这些映射在运行时期间使用当访问事务的查询将用人类可读的参考数据替换参考时 ID 开始 结束 应用 运作方式 用户 1 12:03:40 12:05:25 www.example.com /登录 约翰·史密斯 2 12:04:10 12:06:00 www.example.com /购买 简·多伊 天真的解决方案 我敢打赌我们的读者中的任何人都可以在不睁眼的情况下针对这种要求提出简单的解决方案。 选择一个喜欢的java.util.Map实现将键值对加载到Map并在查询期间查找引用的值。 当我们发现我们选择的基础架构具有存储在Kafka主题中的查找数据的Druid存储已经通过Kafka查找开箱即用地支持此类Maps时感觉容易的事情变得微不足道。 问题 幼稚的方法为我们服务了一段时间。 一段时间后随着查找映射的大小增加需要查找值的查询开始花费越来越多的时间。 我们在吃自己的狗粮并使用Plumbr监视Plumbr本身时注意到了这一点。 我们开始看到在Druid Historical节点上GC暂停越来越频繁而且更长服务于查询并解决了查询。 显然一些最有问题的查询必须从地图中查找超过100,000个不同的值。 这样做时查询被GC启动打断并超出了以前的100ms以下查询的持续时间超过了10秒钟。 在寻找根本原因的同时我们让Plumbr从此类有问题的节点公开了堆快照确认长时间的GC暂停后大约70的已用堆已被查找表完全消耗了。 同样明显的是该问题还需要考虑另一个方面。 我们的存储层基于节点集群集群中为查询提供服务的每台计算机都运行多个JVM进程而每个进程都需要相同的参考数据。 现在考虑到所讨论的JVM具有16G堆并有效地复制了整个查找映射因此这也成为容量规划中的一个问题。 支持越来越大的堆所需的实例大小开始在我们的EC2账单中付出了代价。 因此我们不得不提出一种不同的解决方案既减轻了垃圾收集的负担又找到了降低Amazon AWS成本的方法。 解决方案编年史地图 我们实施的解决方案基于Chronicle Map构建。 编年史地图在内存键值存储区中处于堆外状态。 正如我们的测试所示存储的延迟时间也非常长。 但是我们选择编年史地图的主要优点是它能够跨多个流程共享数据。 因此除了将查找值加载到每个JVM堆之外我们只能使用集群中不同节点访问的映射的一个副本 在进入细节之前让我为您提供编年史地图功能的高级概述我们发现它特别有用。 在编年史地图中数据可以保存到文件系统中然后由任何并发进程以“查看”模式访问。 因此我们的目标是创建一个具有“编写者”角色的微服务这意味着它将将所有必需的数据实时地持久存储到文件系统中并作为“读取器”的角色即我们的Druid数据存储。 由于Druid不支持现成的Chronicle Map因此我们实现了自己的Druid扩展 该扩展能够读取已经保存的Chronicle数据文件并在查询期间用人类可读的名称替换标识符。 以下代码提供了一个示例说明如何初始化编年史地图 ChronicleMap.of(String.class, String.class)
.averageValueSize(lookup.averageValueSize)
.averageKeySize(lookup.averageKeySize)
.entries(entrySize)
.createOrRecoverPersistedTo(chronicleDataFile); 在初始化阶段需要此配置以确保Chronicle Map根据您预测的限制分配虚拟内存。 虚拟内存预分配不是唯一的优化如果像我们一样将数据持久化到文件系统中您会注意到创建的Chronicle数据文件实际上是稀疏文件 。 但这将是一个完全不同的帖子的故事所以我不会深入探讨这些。 在配置中您需要为尝试创建的编年史地图指定键和值类型。 在我们的例子中所有参考数据都是文本格式因此我们为键和值都指定了String类型。 在指定键和值的类型之后Chronicle Map初始化还有更多有趣的部分是独特的。 正如方法名称所暗示的 averageValueSize和averageKeySize都要求程序员指定期望存储在Chronicle Map实例中的平均键和值大小。 使用方法条目您可以为Chronicle Map提供可以存储在实例中的预期数据总数。 也许有人会怀疑如果随着时间的推移记录数量超过预定义的大小会发生什么 显然如果超过了配置的限制则在最后输入的查询上性能可能会下降。 当超出预定义的条目大小时还要考虑的另一件事是如果不更新条目大小则无法从Chronicle Map文件中恢复数据。 由于Chronicle Map在初始化期间会预先计算数据文件所需的内存因此如果条目大小保持不变并且实际上文件中包含的内容比如说多4倍的条目则数据将无法容纳到预计算的内存中因此Chronicle Map初始化将失败。 如果要在重启后正常运行请务必牢记这一点。 例如在我们的场景中当重新启动持久化来自Kafka主题的数据的微服务时在初始化Chronicle Map实例之前它会根据Kafka主题中的消息数量动态计算数量条目。 这使我们能够在任何给定时间重新启动微服务并使用更新的配置恢复已持久保存的Chronicle Map文件。 带走 使Chronicle Map实例能够在微秒内读写数据的各种优化立即开始产生良好的效果。在发布基于Chronicle Map的数据查询后几天我们已经看到了性能改进 此外从每个JVM堆中删除查找映射的冗余副本可以显着减少存储节点的实例大小从而在我们的Amazon AWS账单中产生明显的凹痕。 翻译自: https://www.javacodegeeks.com/2017/02/going-off-heap-improve-latency-reduce-aws-bill.html
