网页制作网站,做海报推荐网站,帝国cms网站搬家,哪个网站的pc端是用vue做的apache camel时不时地#xff0c;我会以Camel速度较慢的观点来询问有关优化Camel应用程序的问题。 骆驼只是连接不同系统的粘合剂#xff0c;路由引擎全部在内存中#xff0c;并且不需要任何持久状态。 因此#xff0c;在99#xff05;的情况下#xff0c;性能问题是由于… apache camel 时不时地我会以Camel速度较慢的观点来询问有关优化Camel应用程序的问题。 骆驼只是连接不同系统的粘合剂路由引擎全部在内存中并且不需要任何持久状态。 因此在99的情况下性能问题是由于其他系统的瓶颈所致 或者是在没有性能考虑的情况下完成了应用程序设计。 如果真是这样那么进一步调整Camel并没有太大的作用您必须回到绘图板上。 但是有时候从您的骆驼路线中挤出几毫秒可能是值得的。 调整每个应用程序非常具体并且取决于技术和用例。 这里有一些关于调整基于骆驼的系统的想法这些想法可能适用于您或不适用。 端点调整 Camel中的端点是与其他系统的集成点它们的配置方式将对系统的性能产生巨大影响。 了解不同端点的工作方式并对其进行调整应该是最开始的地方之一。 以下是一些示例 消息传递 –如果您的Camel应用程序正在使用消息传递则总体性能将在很大程度上取决于消息传递系统的性能。 这里有太多因素需要考虑但主要因素有 消息代理 –网络和磁盘速度以及代理拓扑将决定代理性能。 为了给您一个想法使用ActiveMQ基于关系数据库的持久性存储将执行约50的基于文件的存储而使用代理网络进行水平扩展将花费另外30的性能。 令人惊讶的是ActiveMQ中的一项配置更改如何对消息传递系统以及Camel应用程序产生巨大影响。 必须阅读Red Hat的ActiveMQ 调优指南 其中包含许多要考虑和评估的细节。 克里斯蒂安·波斯塔 Chrisitan Posta的一个真实示例也展示了在某些情况下如何使经纪人加速25倍 。 消息客户端 –如果将性能放在首位则还可以在ActiveMQ客户端上进行一些黑客操作例如增加TCP socketBufferSize和ioBufferSize调整OpenWire协议参数使用消息压缩批处理确认 与optimizeAcknowledge异步发送与useAsyncSend调整预取极限等有克里斯蒂娜又都是一些不错的幻灯片这里老但仍然非常相关的视频由罗布·戴维斯有关调整的ActiveMQ。 所有这些资源都应该为您提供足够的想法以便从消息的角度进行实验并提高性能。 数据库写入 –尽可能使用批处理。 在执行批处理操作以与数据库例如与SQL组件进行交互之前可以使用聚合器收集大量条目。 return new RouteBuilder() {public void configure() throws Exception {from(direct:start).aggregate(header(PROD_TYPE), new SQLStrategy()).completionSize(100).completionTimeout(1000).to(sql:insert into products (price, description) values (#, #)?batchtrue);}
}; 对模板的使用 -如果你必须使用模板组件作为路由的一部分尝试在现有的模板引擎FreeMarker的速度SpringTeplate小胡子组块与一个小的测试为以下一个和衡量哪一个性能更好。 克里斯蒂安·穆勒Christian Mueller在题为《 骆驼的性能优化》中做了一个精彩的演讲其中的源代码支持了这一发现。 从这些测量中我们可以看到 FreeMarker的性能通常比Velocity和SprintTemplates好。 使用Web服务 –每当需要使用Web终结点时Web容器本身必须分别进行调整。从Camel终结点的角度来看如果不需要Java对象则可以通过跳过解组来进一步优化一点并使用异步处理。 concurrentConsumers -有多个组件塞达VMJMSRabbitMQ的分裂器AWS-SQS等的支持并行消耗。 使用端点之前请检查组件文档中的线程池或批处理功能。 为了让您有个想法请参阅如何通过这些选项改进 Amzon SQS处理。 数据类型选择 通过骆驼路线传递的数据的类型和格式也将影响性能。 为了证明这一点让我们看几个例子。 基于内容的路由器分离器过滤器是基于消息内容执行某些工作的EIP的示例。 消息的类型会影响这些元素的处理速度。 以下是克里斯蒂安·穆勒Christian Mueller的演示文稿中的图表直观地展示了基于内容的路由器如何处理各种消息 基于不同数据类型的基于内容的路由 例如如果您在Exchange中有一个大型XML文档并基于该文档执行基于内容的路由筛选等操作则这将影响路由的速度。 相反您可以从文档中提取一些关键信息并填充Exchange标头以便以后更快地访问和路由。 封送处理/取消封送处理 –与模板引擎类似不同的数据格式venvenor表现也不同。 要查看一些指标请再次检查Christian的演示文稿但也要记住 受支持的数据格式的性能在不同版本和平台之间可能会有所不同因此请针对您的用例进行衡量。 流 -骆驼流和流缓存是被低估的功能之一可用于处理大消息。 声明检查EIP –如果应用程序逻辑允许请考虑使用声明检查模式来提高性能并减少资源消耗。 多线程 Camel在许多地方提供了多线程支持。 使用这些也可以提高应用程序性能。 并行处理EIP –以下骆驼EIP实现支持并行处理–多播收件人列表拆分器延迟器窃听调节器错误处理程序。 如果您要为它们启用并行处理那么最好还提供一个针对您的用例进行了专门调整的自定义线程池而不是依赖于Camel的默认线程池配置文件。 线程DSL构造 –某些Camel终结点例如文件使用者在设计上是单线程的无法在终结点级别并行化。 对于文件使用方单个线程一次选择一个文件并通过该路径处理该文件直到到达路径末尾然后使用方线程选择下一个文件。 这是Camel Threads构造有用的时候。 如下图所示文件使用方线程可以选择一个文件并将其从Threads构造传递给线程以进行进一步处理。 然后文件使用者可以选择另一个文件而无需等待先前的Exchange完全完成处理。 并行文件消耗 Seda组件 – Seda是在骆驼中实现并行性的另一种方法。 Seda组件具有内存中列表用于累积来自生产者和并发消费者的传入消息以通过多个线程并行处理这些传入请求。 异步重新传送/重试–如果在路由过程中使用带有重新传送策略的错误处理程序则可以将其配置为异步并在单独的线程中进行重新传送。 这将使用单独的线程池进行重新交付而不会在等待时阻塞主请求处理线程。 如果您需要长时间延迟的重新交付使用ActiveMQ代理重新交付与消费者重新交付BTW不同可能是更好的方法因为重新交付将保留在消息代理上而不保存在Camel应用程序内存中。 这种机制的另一个好处是重新交付将在应用程序重新启动后继续存在并且在集群应用程序时也可以很好地播放。 我在《 骆驼设计模式》一书中描述了不同的重试模式。 其他优化 您可以采取其他一些技巧来进一步微调Camel。 记录 配置 –希望您不必在生产环境中记录每条消息及其内容。 但是如果必须请考虑使用一些异步记录器。 在高吞吐量系统上另一个选择是通过Camel吞吐量记录器记录统计信息和汇总指标。 吞吐量记录器允许以固定的间隔或基于已处理消息的数量而不是每个消息基础记录聚合统计信息。 另一个选择是使用不太流行的Camel Sampler EIP并时不时仅记录样本消息。 禁用JMX –默认情况下启用Camel JMX工具会创建很多MBean。 这不仅可以监视和管理Camel运行时而且还会降低性能并需要更多资源。 我仍然记得曾经不得不完全关闭Camel中的JMX以便在一个免费的AWS账户上使用512MB堆运行它的时候。 至少要考虑是否需要启用任何JMX如果需要则是否要使用RoutesOnly默认或扩展JMX配置文件。 消息历史记录 -骆驼实现消息历史记录EIP并默认运行它。 在开发环境中查看每个端点也都有一条消息可能会很有用但是在生产环境中您可能考虑禁用此功能。 原始邮件 –每条骆驼路线都将在原始邮件复制之前对其进行任何修改。 保留此原始消息副本以防在错误处理期间或使用onCompletion构造重新发送该消息。 如果不使用这些功能则可以禁用创建和存储每个传入消息的原始状态。 其他自定义 –几乎可以自定义CamelContext中的每个功能。 例如您可以使用lazyLoadTypeConverters来加快应用程序的启动速度或者将shutdownStrategy配置为在出现机上消息时更快地关闭或者使用执行速度更快的自定义UuidGenerator等。 应用设计 与应用程序设计和体系结构相比所有先前的调优都是微优化。 如果您的应用程序不是为实现可伸缩性和性能而设计的那么小型调整技巧迟早会达到其极限。 很有可能您正在做的事情以前已经做过而不是重新发明轮子或提出一些聪明的设计而是从其他人的经验中学习并使用众所周知的模式原理和实践。 使用来自SOA的原则微服务架构弹性原则最佳消息传递实践等。其中的一些模式例如并行管道CQRS负载均衡断路器在Camel设计模式一书中进行了介绍并有助于改善整个应用程序设计。 虚拟机 关于JVM调优的文章很多。 在这里我只想提及Red Hat的JVM配置生成应用程序。 只要您拥有Red Hat帐户无论如何对开发人员都是免费的就可以使用它。 操作系统 您只能挤压应用程序那么多。 为了执行适当的高负载处理也必须调整主机系统。 要了解各种操作系统级别选项 请查看 Jetty项目中的以下检查清单 。 结论 本文只是为了给您一些想法并向您展示当您必须改善Camel应用程序的性能时要考虑的可能领域的扩展。 无需寻找神奇的配方或通过检查清单而要进行测量支持的小幅增量更改直到达到所需状态为止。 与其关注微优化和黑客不如对系统进行整体了解正确设计并开始从主机系统调优到JVMCamelContext路由元素端点和数据本身。 使用众所周知的模式原理和实践着重于简单和可扩展的设计是一个好的开始。 祝好运。 翻译自: https://www.javacodegeeks.com/2016/01/performance-tuning-ideas-apache-camel.htmlapache camel
