[
https://issues.apache.org/jira/browse/KYLIN-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16649722#comment-16649722
]
Ma Gang commented on KYLIN-3601:
--------------------------------
Looks weird, and should not happen theoretically. [~kofiori] what performance
test tool you use to do the test? Is one concurrent client only send the next
request after it get response for the previous request?
And you should increase the concurrency time by time to do the test, for
example: 1, 5, 10, 20, 50, 100 concurrent clients, and check the issue happens
in which concurrency level.
For borrow fail case, you may add some log after throw NoSuchElementException
when borrow prepareContext from pool.
Also the bottleneck may happen in Hbase side or even in tomcat, could you check
the query log for the timeout query, what makes the query slow? you may dump
some stacktrace randomly when lots of query failed.
> The max connection number generated by the PreparedContextPool is
> inconsistent with the configuration.
> ------------------------------------------------------------------------------------------------------
>
> Key: KYLIN-3601
> URL: https://issues.apache.org/jira/browse/KYLIN-3601
> Project: Kylin
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: v2.5.0
> Reporter: huaicui
> Priority: Major
> Attachments: FirstResponseDistribute.jpg,
> SixthResponseDistribute.jpg, image-2018-09-28-15-14-00-288.png, image.png
>
>
> 因为并发性能不够，使用了magang提供的PrepareStatement方法进行测试。性能有所有提高，但随着测试次数的增加，吞吐率会越来越低而且数据超时也越来越多。经过修改代码在queryAndUpdateCache最后返回前加入日志打印：logger.debug("BorrowedCount:"+preparedContextPool.getBorrowedCount()
> +",DestroyedCount:"+preparedContextPool.getDestroyedCount()
> +",CreatedCount:"+preparedContextPool.getCreatedCount()
> +",ReturnedCount:"+preparedContextPool.getReturnedCount()
> 同时配置文件加入该配置：
> kylin.query.statement-cache-max-num-per-key=200
>
>
> 日志显示，当同一sql并发一段时间后，PreparedContextPool创建了越来越多PrepareStatement，并没有进行阻塞后续来的请求。
> !image-2018-09-28-15-14-00-288.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
