>
> > > [1 <text/plain; us-ascii (7bit)>]
> > > I don't know if any of you people have ever had this trouble, but it's
> > > been a messy one here.
> >
> > > Whenever a website of ours get lots of traffic, MySQL gets too slow to
> > > connect. Whenever it connects, the queries are fast. Since lots of our
> > > scripts relies on database connections, it has become a big problem to
> > > our website and we've been unable to answer to our costumers what is
> > > going on.
> >
> > Use connection caching, e.g. mod_perl with Apache::DBI.
>
> Based on you idea and what I have found in the MySQL manual, I decided
> to use the thread_cache_size. I put it up to 20. I also increased the
> thread_stack to 128K.
>
> Now we have solved our problems with slow connections and found a new
> one: slow queries. They have increased a lot now that our users are able
> to connect to the database and do their favorite concurrent inserts,
> concurrent updates and concurrent selects.
>
> Solved a problem. Found a new one.
Concurrent updates and mysql aren't the best of friends, yet. (Perhaps DBD
and/or that new geminii stuff can fix some of your problems? Although
geminii will probably cost you...)
A lot of the slow queries can be solved by making better tables, sometimes
even de-normalizing them if that can prevent a join, by sticking the numeric
data into seperate tables (variable length stuff kills performance), etc.
Standard procedure :)
But in the end, if you have tons of concurrent updates then you might want
to consider alternatives to MySQL.
(postgres, frontbase, etc.)
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
