OneSQL :: 对PostgreSQL定制版本的进一步测试,优化、优化、再优化!

最近这两周一直游离在MySQL & PostgreSQL代码中间,一开始是向PostgreSQL移植类线程池机制,后来是借签一点点PostgreSQL的代码思路到,然后又是从MySQL代码中得到一点灵感要增加到PostgreSQL中。经历几个来回后,现在觉得比较成熟了,做了一个综合的OneSQL for PostgreSQL的性能测试,针对以下几个测试场景:

  • sysbench的update_non_index脚本,20个表,每个表200000条记录。
  • sysbench的oltp脚本,20个表,每个表200000条记录。
  • pgbench的simple模式,scale为50,自带的脚本。
  • pgbench的extended模式,scale为50,自带的脚本。
  • pgbench的prepared模式,scale为50,自带的脚本。

测试程序和数据库服务在不同的服务器上,通过千兆局域网进行连接,数据库服务器为单颗E5 2680 v3,12核,32GB内存 。分别使用256、512、768个并发进行测试。在256并发下,源生的稍好一点点,基本上看不出区别来,测试结果如下:

onepgsql_thread_pool_256

将并发连接数增加到512时,OneSQL for PostgreSQL开始胜出一点,并发控制机制开始生效,测试结果如下:

onepgsql_thread_pool_512

继续加大并发到768个会话,OneSQL的优势就完全体现出来了,测试结果如下图:

onepgsql_thread_pool_768

对OneSQL持续加大并发度到2048时,大约总体的TPS,相比256个并发时,会下降30%的样子,而源生版本就非常难看了。下面再来看一张sysbench的update non index场景,将表的数量缩为1张,记录数变为10条,模拟锁冲突严重的情况,OneSQL的优势就充分展示出来了,测试结果如下:

onepgsql_thread_pool_hotrow

OneSQL在低并发时,基本上没有损耗,到高并发时具有明显的优势。过去的半年多时间里,接到不少用户询问pgbouncer、pg pool、OneProxy for PostgreSQL的,相比较而言OneSQL对应用完全透明,没有任何限制,是非常好的并发解决方案。