[development] Counterintuitive but true: Caching makes a high-traffic site slower

[Khalid B]

MyISAM is really fast compared to other engines. Only  when you are
running  a very high  traffic site does locking contention become an
issue. For small to medium sites,  it should be faster.

MyISAM is the default engine for MySQL.

The  reason of defaulting to MySQL  is  mainly historical. Until
recently ISPs  would not  support other engines, and everyone had to
use MyISAM because that is what their ISP has. This is specially true
in shared hosting.

Nowadays, even shared hosting has InnoDB,  which  is ACID, has
transaction, and row level locking.

The  future of InnoDB with  MySQL is unclear though, now that Oracle
has purchased InnoBase,  the company  that makes InnoDB. This could
mean reduced revenue for MySQL AB which sells non-GPL  versions of
MySQL+InnoDB. We have  to wait and see what happens here.

Not sure about making it the default though ...

On 12/29/05, Bèr Kessels <ber at webschuur.com> wrote:
> I am a sql-clueless person. So can someone explain me why the --- we have
> myisam there, if it performs so bad?
>
> Ber
>
> Op donderdag 29 december 2005 18:24, schreef John Handelaar:
> > In the continuing absence of anywhere to discuss these
> > performance edge-cases (more below)...
> >
> >
> > I've already mentioned recently that MyISAM is the
> > enemy of Drupal performance.  Because it requires a
> > full-table lock, if you have lots of active members
> > logged in at once, the process of posting a comment
> > causes page rendering to cease entirely for several
> > seconds.
> >
> > Onto today's point:
> >
> > The same table-level locking is *lethal* on a heavily-
> > trafficked site which has both
> >
> > a)  Content which alters regularly (like a busy forum),
> >      and
> >
> > b)  Caching turned on.
> >
> >
> > Try turning it off if your slow query log starts showing
> > cache-related things taking 90 seconds (!) or more (!!).
> >
> > And then take a backup of your database and change these
> > table types to InnoDB format.
> >
> > And then start looking at delayed inserts.
> >
> >
> > jh
> >
> >
> > PS:  Still no bigsite/performance forum.  Have we decided
> > that Drupal doesn't *need* to scale?  I missed that meeting.
>