Re: [Maria-discuss] Threadpool benchmarks / feature note
Hi XL,
On 28 Jan 2014, at 18:20, Axel Schwenke axel@mariadb.com wrote:
Hi Colin,
XL: Can you think about doing benchmarks like Ranger has done? (http://www.mysqlperformanceblog.com/2014/01/23/percona-server-improve-scalab...)
I did those benchmarks for 5.5. The r/w benchmark looked much worse than what Percona has here. That's why I blogged results for readonly workload only.
But they test with much more data - that might make the difference. I agree that this benchmark should be repeated with 10.0.
http://www.mysqlperformanceblog.com/2014/01/29/percona-server-thread-pool-im...
Ranger has now responded (if he's reading this list, Hi!)
cheers, -colin
-- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles
hum... an idiot question, i didn't think it about before asking...
why not allow one server running two tcp ports, or unix socket or pipes or any other listening method? each one using a scheduler style, TP (thread pool) or OTPC (one thread per client)?
for example... i have some queries that execute nice with OTPC (and it's easy to change program to only use a tcp port in this case), but they could lock many queries if execute with TP (again it's easy to tell what scheduler is better and select the right tcp port), and some queries runs nice with any one
in this case, why not allow a tcp port for TP, and one tcp port for OTPC? ok many lock problems? maybe allow a new option at client connect function (like compress option) that allow select of what kind of schedule should be used at server side? TP or OTPC or maybe another one...
thanks guys any news/information is welcome :)
2014-01-30 Colin Charles byte@mariadb.com:
Hi XL,
On 28 Jan 2014, at 18:20, Axel Schwenke axel@mariadb.com wrote:
Hi Colin,
XL: Can you think about doing benchmarks like Ranger has done? (http://www.mysqlperformanceblog.com/2014/01/23/percona-server-improve-scalab...)
I did those benchmarks for 5.5. The r/w benchmark looked much worse than what Percona has here. That's why I blogged results for readonly workload only.
But they test with much more data - that might make the difference. I agree that this benchmark should be repeated with 10.0.
http://www.mysqlperformanceblog.com/2014/01/29/percona-server-thread-pool-im...
Ranger has now responded (if he's reading this list, Hi!)
cheers, -colin
-- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
On Thu, Jan 30, 2014 at 05:00:36AM -0200, Roberto Spadim wrote:
hum... an idiot question, i didn't think it about before asking...
why not allow one server running two tcp ports, or unix socket or pipes or any other listening method? each one using a scheduler style, TP (thread pool) or OTPC (one thread per client)?
I thought this was supported: mysqld --help --verbose prints:
--extra-max-connections=# The number of connections on extra-port --extra-port=# Extra port number to use for tcp connections in a one-thread-per-connection manner. 0 means don't use another port
for example... i have some queries that execute nice with OTPC (and it's easy to change program to only use a tcp port in this case), but they could lock many queries if execute with TP (again it's easy to tell what scheduler is better and select the right tcp port), and some queries runs nice with any one
in this case, why not allow a tcp port for TP, and one tcp port for OTPC? ok many lock problems? maybe allow a new option at client connect function (like compress option) that allow select of what kind of schedule should be used at server side? TP or OTPC or maybe another one...
BR Sergei
sorry :) thanks sergei
2014-01-30 Sergei Petrunia psergey@askmonty.org:
On Thu, Jan 30, 2014 at 05:00:36AM -0200, Roberto Spadim wrote:
hum... an idiot question, i didn't think it about before asking...
why not allow one server running two tcp ports, or unix socket or pipes or any other listening method? each one using a scheduler style, TP (thread pool) or OTPC (one thread per client)?
I thought this was supported: mysqld --help --verbose prints:
--extra-max-connections=# The number of connections on extra-port --extra-port=# Extra port number to use for tcp connections in a one-thread-per-connection manner. 0 means don't use another port
for example... i have some queries that execute nice with OTPC (and it's easy to change program to only use a tcp port in this case), but they could lock many queries if execute with TP (again it's easy to tell what scheduler is better and select the right tcp port), and some queries runs nice with any one
in this case, why not allow a tcp port for TP, and one tcp port for OTPC? ok many lock problems? maybe allow a new option at client connect function (like compress option) that allow select of what kind of schedule should be used at server side? TP or OTPC or maybe another one...
BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog
participants (3)
-
Colin Charles -
Roberto Spadim -
Sergei Petrunia