[
https://issues.apache.org/jira/browse/KYLIN-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16649744#comment-16649744
]
huaicui commented on KYLIN-3601:
--------------------------------
We use Gatling to loading test;
This is our test script:
import java.util.concurrent.TimeUnit
import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._
class KylinSimulation2 extends Simulation {
val httpConf = http
.acceptHeader("application/json")
.contentTypeHeader("application/json")
val headers_json = Map(
"Content-Type" -> "application/json",
"Authorization" -> "Basic QURNSU46S1lMSU4="
)
val scn2 = scenario("KylinServer6").during(60) { // 60 means keep sending
requests for about 60s
exec(
http("KylinQuery4")
.post("http://sap-datanode5:7070/kylin/api/query")
.headers(headers_json)
.body(StringBody("{ \"sql\":\"select CLIENTAGENT, STARTDAY, COUNT(*)
TOTAL_NUMBER from XXRPT_HGSMEETINGUSERREPORT_VIEW where SITEID = ? group by
STARTDAY, CLIENTAGENT\", \"project\":\"CCA_REPORT\",
\"params\":[{\"className\":\"java.lang.String\",\"value\":\"1000182\"}]
}")).asJSON
)
}
setUp(
scn2.inject(atOnceUsers(150)) // 150 users(threads)
).protocols(httpConf)
}
We use 150 threads to loading test, kylin.query.statement-cache-max-num-per-key
is 200; We found the number of PrepareStatement instance would be more and more
like the attaches(CreatedCount will be larger and larger); No matter how many
concurrent that will trigger this issue;
> 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)