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. _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users