apache camel_Apache Camel的性能调整思路

apache camel

时不时地，我会以Camel速度较慢的观点来询问有关优化Camel应用程序的问题。骆驼只是连接不同系统的粘合剂，路由引擎全部在内存中，并且不需要任何持久状态。 因此，在99％的情况下，性能问题是由于其他系统的瓶颈所致 ，或者是在没有性能考虑的情况下完成了应用程序设计。如果真是这样，那么进一步调整Camel并没有太大的作用，您必须回到绘图板上。

BoI5lo8IgAAOFHd 但是有时候，从您的骆驼路线中挤出几毫秒可能是值得的。调整每个应用程序非常具体，并且取决于技术和用例。这里有一些关于调整基于骆驼的系统的想法，这些想法可能适用于您（或不适用）。

端点调整

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 (#, #)?batch=true");}
};

对模板的使用 -如果你必须使用模板组件作为路由的一部分，尝试在现有的模板引擎（FreeMarker的，速度，SpringTeplate，小胡子，组块）与一个小的测试为以下一个和衡量哪一个性能更好。克里斯蒂安·穆勒（Christian Mueller）在题为《骆驼的性能优化》中做了一个精彩的演讲，其中的源代码支持了这一发现。从这些测量中，我们可以看到 FreeMarker的性能通常比Velocity和SprintTemplates好。
使用Web服务 –每当需要使用Web终结点时，Web容器本身（必须分别进行调整。从Camel终结点的角度来看，如果不需要Java对象，则可以通过跳过解组来进一步优化一点，并使用异步处理。
concurrentConsumers -有多个组件（塞达，VM，JMS，RabbitMQ的，分裂器，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应用程序的性能时要考虑的可能领域的扩展。无需寻找神奇的配方或通过检查清单，而要进行测量支持的小幅增量更改，直到达到所需状态为止。与其关注微优化和黑客，不如对系统进行整体了解，正确设计并开始从主机系统调优到JVM，CamelContext，路由元素，端点和数据本身。

使用众所周知的模式，原理和实践，着重于简单和可扩展的设计是一个好的开始。祝好运。