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
-- Roberto Spadim SPAEmpresarial Eng. Automação e Controle