maria-discuss team mailing list archive
Mailing list archive
Re: Threadpool benchmarks / feature note
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...
any news/information is welcome :)
2014-01-30 Colin Charles <byte@xxxxxxxxxxx>:
> Hi XL,
> On 28 Jan 2014, at 18:20, Axel Schwenke <axel@xxxxxxxxxxx> wrote:
>> Hi Colin,
>>> XL: Can you think about doing benchmarks like Ranger has done? (http://www.mysqlperformanceblog.com/2014/01/23/percona-server-improve-scalability-percona-thread-pool/)
>> 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.
> Ranger has now responded (if he's reading this list, Hi!)
> Colin Charles, Chief Evangelist
> MariaDB | t: +6-012-204-3201 | Skype: colincharles
> Mailing list: https://launchpad.net/~maria-discuss
> Post to : maria-discuss@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-discuss
> More help : https://help.launchpad.net/ListHelp
Eng. Automação e Controle