maria-discuss team mailing list archive
-
maria-discuss team
-
Mailing list archive
-
Message #05001
Re: MariaDB threads optimalization
-
To:
maria-discuss@xxxxxxxxxxxxxxxxxxx
-
From:
Reindl Harald <h.reindl@xxxxxxxxxxxxx>
-
Date:
Wed, 7 Feb 2018 14:27:39 +0100
-
In-reply-to:
<CADBddDF8zM3_OhBfV3RJikszbB0LL_g5p3kKaBP=4LLcaKet+Q@mail.gmail.com>
-
Organization:
the lounge interactive design
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
Am 07.02.2018 um 14:25 schrieb jocelyn fournier:
each layer brings inevitable it's own problems to the mix and if it's
only added latency for non-cacheable queries and complexer
dependencies for long-term maintainance of oyur whole application stack
I agree before adopting this kind of software, you have to check the
cacheability of your application (which is a metric displayed by the
heimdalldata dashboard BTW) because there's always a small overhead.
But I like the concept of heimdalldata where the cache is actually
hosted on each front server, instead of a potentially remote MySQL
server, hence *reducing* the latency of your application by removing the
network round-trip delay for cached queries
well, our mysqld are conencted via unix-sockets, so no TCP and no
failovers needed on that layer - HA is done by the virtualization
cluster on a deeper layer and when the whole cluster fails game over
anyways :-)
References