【前言】
前面几篇文章讲述了rabbitmq消息存储的相关原理，也提到了有些参数可以进行配置。这些配置参数的微调在不同的场景中会有不同的效果。本文对其中一些参数进行说明，同时以实测数据结合性能分析工具进行剖析。
【相关参数说明】
queue_index_embed_msgs_below
控制消息的存储位置。是独立存储到msg_store中，还是嵌入消息的索引一并存储。默认值是4096（字节），即小于4KB的消息会嵌入到消息索引中一并存储。
注：4KB包括消息内容以及消息的属性等元数据信息，其中消息的元数据信息占用至少300字节。
queue_index_max_journal_entries
索引文件写磁盘之前能缓存的最大日志条数。默认值为32768，即消息的publish、delivery、ack操作数达到32768次后，会将日志文件journal.jif中的内容写到对应的索引文件（*.idx）中。索引文件的存储细节戳这里。
注：该值是针对队列的，并非全局设置的值。
msg_store_io_batch_size
对于非lazy队列，触发paging时，内部Q1，Q2，delta，Q3，Q4之间每次消息挪动的最大值。默认值为4096，即Q1->Q2每次最多移动4096*2=8192条消息，同样Q2->delta、Q4->Q3、Q3->delta每次最多移动8192条消息。
credit_flow_default_credit
流控的信用配置，作用于 reader->channel->queue之间。
默认值为{400,200}。
msg_store_credit_disc_bound
msg_store方式的消息存储的流控信用配置，即作用于queue->msg_store之间。默认值为{4000,800}。
【参数调优】
queue_index_max_journal_entries
先来看一组测试数据
测试场景是这样的：
16个生产者分别向64个持久化队列不间断发送消息，队列设置为lazy模式；每条消息大小为4KB，属性设置为持久化；
queue_index_embed_msgs_below设置为10240，即消息会嵌入索引一并存储；
数据整体存储在SSD上；
queue_index_max_journal_entries的值分别设置为1024、2048、4096、8192、32768。
在只有生产者场景下与同时有生产者消费者场景下（每个队列1个消费者，收到消息不做任何处理）的测试情况：
生产速度表示仅有生产者场景下，16个生产者累计的生产速度。
生产消费速度表示同时有生产者消费者场景下，16个生产者累计的生产速度（消费速度与生产速度几乎持平，即生产速度和消费速度均为图中数据所示）
通过eprof分析队列进程函数调用与耗时如下图所示：
从上面实测性能与eprof的分析可以得出一个结论：随着值得变大，每次sync的耗时也在逐渐变大，因为每次需要写入的数据量变大了，因此相应的吞吐量也就下降了。
但这里有一个奇怪的地方：设置为32768时，为什么sync的耗时不多，但吞吐量也不高呢？
我们仔细看下eprof分析的数据：
发现虽然sync的耗时不长，但累计sync的次数明显多了。理论上收到43078条消息，理论上触发写idx的次数应该是43078/32768=1次，每次写32768/16384=2个idx文件，因此也就是2次sync操作。然而实际上却有371次sync，根据源码分析应该是队列一段时间内没收到任何消息后的定时器超时，触发了将journal.jif文件同步到磁盘上。实际上eprof给出的数据也确实是如此，timeout的调用次数为367次，基本能对上。
那为何又会出现这种情况呢？再次测试，分别在不同的时间段使用eprof进行分析，发现一开始sync的耗时非常大，然后逐步下降并稳定在一个范围内。在这个过程中，生产速度也是逐步下降，同时生产者对应通道进程的缓存中开始出现消息堆积，最终维持在一个水平线上下。
因此前面随着配置值得变大，每次sync的耗时也逐步变大的结论是没有问题的。但出现上面的现象推测一方面与流控有关，一方面与通道进程的消息堆积有关（堆积后，每次GC会有一定的耗时）。
credit_flow_default_credit
测试场景与前面一样，credit_flow_default_credit的值分别设置为{400,200}、{800,200}、{1000,200}、{2000,200}下的测试情况如下所示：
eprof的分析与web上观察通道进程mailbox、gen_server2 buffer的堆积情况如下表所示：
从上面两幅图可以看出，信用流控配置值越大，整体吞吐量反而下降，但下降不明显。另外sync的耗时差别不算大，但通道进程gen_server2 buffer堆积的数量在逐步增加，并且通道进程GC的耗时也在逐渐增加。因此可推测，信用流控配置设置越大，通道进程堆积会越多，GC耗时也就越大，这样整体吞吐量也就会下降。
【总结】
本文总结了几个调优相关的参数，也在特定场景下对其进行了测试说明。但性能不仅仅和这两个参数有关，队列个数、消息大小、消息属性、内存水位、队列是否使用lazy模式、机械盘还是SSD进行存储，等等都会有一定的影响。此外，erlang层面还会有一些参数可以微调，因此不同场景下还需要结合实际需要进行参数的调优。
