[Asterisk-Users] 2 4-port T1 cards

[Brancaleoni Matteo]

Just my 2 cent here...

I noticed that mysql need to be fine tuned for the work it must
do. We have a mysql server that's a backend for a ecommerce
website, a backend for user tracking, backed for an ads engine,
backend for snort, backend for other 6 sites running with
phpnuke. 2 of these sites gets 2000+ unique visitors/day.
The banner engine provides 'about 70k impressions/day (the ads
db grows 250 megs/week, more or less).
All running on a dual P3 733 , raid-5 scsi , 1.2Gb ram .

First times , under the peaks of web traffic, we experienced
some probs with mysql slowering down the server a lot.
But with some patience, tests and fine tuning into my.cnf
we now have a very stable and reliable system that runs
with no probs.

what I mean is that the default install is not always a
good thing to choose. tweak it down, and you're done.

Matteo.

Il mer, 2003-05-28 alle 23:12, Steven Critchfield ha scritto:
> On Wed, 2003-05-28 at 15:09, Jon Pounder wrote:
> > I'll save my typing fingers somewhat on this one - you are doing great 
> > arguing about all the crappiness of mysql and actually backing it up with 
> > real examples. It is nice to see that for a change in comparison to all the 
> > mysql lovers that love it just "because" but have no basis to compare it to 
> > something with "heavy" load. I, like you don't consider massive amounts of 
> > selects heavy at all.
> > 
> > My example of heavy load where mysql could not even begin to handle the 
> > situation was a project with real time stock market data streamed in as 
> > bids and offers and trades happened, statistics computed from that in real 
> > time, database kept in sync live, and charts and graphs plotted in real 
> > time for users on the site. Now that situation had more than its share of 
> > inserts and updates, and a massive wad of historical data being kept just 
> > to add to the fun.
> > 
> > Might I add for record that postgres did just fine.
> 
> While I'm on the postgres bandwagon for now, I wouldn't want it in the
> middle of a phone system doing heavy call loads either. Postgres also
> has some downsides too. As I understand it, postgres doesn't understand
> prepared statements, or at least it doesn't via the perl DBI. Regardless
> I've seen our postgres database eat +2600 updates in under 2 seconds
> from a remote host on the same exact hardware that mysql choked on and
> not cause any degredation of access times for any other user.