[MXS-1020] benchmark the poll-testing branch Created: 2016-11-22  Updated: 2016-11-26  Resolved: 2016-11-25

Status: Closed
Project: MariaDB MaxScale
Component/s: readconnroute
Affects Version/s: None
Fix Version/s: N/A

Type: Task Priority: Major
Reporter: Axel Schwenke Assignee: Axel Schwenke
Resolution: Done Votes: 0
Labels: None

Attachments: File maxscale_poll3.ods    

 Description   

<markusjm> Good morning. I was wondering if you had the free time to
run the maxscale performance test again on the poll-testing branch. I made some
changes to it after I found out that the design had a minor flaw. This change do
es mean that it needs some extra locking and I'm wondering how big of a performa
nce hit this is. The two commits that I'm interested in are 948c8d4e4841b6d53210
bf1566a03d1959049918 (current HEAD of poll-testing) and 3d4208ef3cb437fc085eba5
5058e04aaef6e7913 (the commit for the last benchmark). I'm mainly interested in
the 16 thread, single point select benchmark so I hope that lowers your workload
.

 Comments   
Comment by Axel Schwenke [ 2016-11-25 ]

Hi Markus,
the head of branch poll-testing is still behaving very well. In most cases it's even faster than the last poll-testing benchmark. Only in few cases - mostly for 2 MaxScale threads there is a slight degradation. Nothing serious though.

I attach the spread sheet with the summary. This new series is called "poll-testing #3" and is blue. The previous one is green.

Comment by markus makela [ 2016-11-26 ]

Thanks for the fast testing!

This seems to at least somewhat confirm my suspicions that even though locking occurs between the threads, it doesn't cause a problem as only two threads can ever attempt to acquire the same lock.

Generated at Thu Feb 08 04:03:39 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.