On Tue, 15 Aug 2000, Don Baccus wrote:
> It's no secret that MySQL falls apart under load when there are
> inserts and updates in the mix. They do table-level locking. If you
> read various threads about "hints and tricks" in MySQL-land concerning
> performance in high-concurrency (i.e. web site) situations, there are
> all sorts of suggestions about periodically caching copies of tables
> for reading so readers don't get blocked, etc.
Here's one you might like. I am aware of a site (not one I
run, and I shouldn't give its name) which has a share feed
(or several). This means that, every 15 minutes, they have
to get a bunch of rows into a few tables in a real hurry.
MySQL's table level locking causes them such trouble that
they run two instances. No big surprises there, but here's
the fun bit: they both point at the same datafiles.
Their web code accesses a mysqld which was started with
their --readonly and --no-locking flags, so that it never
writes to the datafiles. And the share feed goes through
a separate, writable database.
Every now and then a query fails with an error like "Eek!
The table changed under us." so they modified (or wrapped -
I'm not sure) the DBI driver to retry a couple of times under
such circumstances.
The result: it works. An actually quite well (ie. a lot
better than before). I believe (hope!) that they are using
the breathing space to investigate alternative solutions.
Matthew.
