In this ZDNet Australia article about MySQL, it says:
Much of the very busy Yahoo! Finance portal uses MySQL as a back-end database.
I find that statement quite remarkable because it's simply not true.
Yes, Yahoo! Finance uses MySQL as a back-end database. But much of goes a bit far. Most of the Y! Finance data is served from memory, not from MySQL. Yes, there are parts that use MySQL quite a bit, but they're not in the majority.
It's official. I flew (and passed) my FAA checkride today! I'm officially a glider pilot.
Read all the details (if you care) in my flying blog.
Can someone ping this entry with a TrackBack? Let me know what (if any) error you get. A few folks have told me that my TB is broken and I seem to be getting way fewer TrackBacks that normal. I suspect it's related to my recent upgrade to MT 2.63 but am not sure where to begin debugging this yet.
I will have to search around a bit in the morning and see if this is some sort of known problem. Everything else went quite well with the upgrade from 2.21.
Update: I've patched MT. Let's see if that fixed it. Someone ping me again. :-)
Update #2: Duh. I pinged myself. It's fixed. Thanks to Phil's post in the MT support forum.
So don't expect to read anything about it here. Well, nothing beyond this.
I find that decent live concert recordings almost always sound better, more authentic, and often more energetic than the studio tracks. Yet the live stuff is almost never heard on the radio. Why is that?
I guess it's good that I have the live versions of several albums in my collection. I really don't understand the music industry sometimes. Or maybe it's the general public I don't understand. It's not like Sony or ClearChannel are going broke...
And, yes, it is my first time to NYC.
I finally got off my lazy ass and wrote up abstracts for some of my upcoming talks. Here's the scoop on the MySQL Conference and the PHP Conference (both in April). I'll hit the OSCON ones in a few days (or weeks?). So far they haven't nagged me yet, but I'm sure they will. :-)
Replication provides a great mechanism for scaling MySQL beyond a single machine and even across vast distances. It can also be used to provide a "hot spare" server which can be used in the event that the primary server fails.
In this session, we'll look at how MySQL replication works and how to configure it. How is replication in MySQL 4.0 different than in the previous releases? nnn
We'll also cover common problems and solutions. Why does replication fail? How can you monitor and detect when replication fails? What's the best way to add one more new slaves to an existing replication setup? Which replication topology makes the most sense for a given application?
Finally, we'll discuss hardware and software solutions that can be combined with replication to provide load-balancing and high-availability.
Then on Saturday (April 12th) at 4pm, I'll be giving a 2-hour talk titled "Optimizing MySQL" Here's the abstract for that one.
As the load on a MySQL server increases, its performance may degrade if it has not been properly tuned to handle the load. A default installation of MySQL performs well for many applications, but it generally will not perform efficiently under stress.
In this presentation we'll discuss many of the tunable parameters in MySQL's configuration file (my.cnf), how to read MySQL's performance counters, and various optimizations which can be used to improve the performance and efficiency of MySQL servers--often with dramatic results. We'll also examine MySQL's various table types as well as hardware solutions to performance problems.
This conference is really gonna be cool. Check out the schedule to see for yourself. The only thing that bothers me is that there are other talks that I want to attend while I'm presenting. And even when I'm not, there are some tough choices. During many of the time slots, I want to attend at least two of them.
Good for the conference. Bad for me.
At PHPCon East 2003, I'll be giving a 75 minute talk titled "PHP & MySQL Performance Tuning" Here's that abstract.
They're they dynamic duo of LAMP. Fast, easy to use, wildly popular, and extensible. But what happens when your MySQL-backed PHP application starts to slow down? Where do you look? What tools will help identify bottlenecks? What techniques can help to avoid performance problems with PHP & MySQL?
In this session, we'll take a whirlwind tour of MySQL performance viewed thru the lens of PHP (and Apache). In doing so, we'll discuss and illustrate answers to all of those questions.
That reminds me. Flight reservations. Hotel reservations. Ugh. More stuff to do.
Oh, and I should probably alert the boss to the fact that I'll be out a bit in April. Better sooner than later.
Slashdot is a lot like a car accident on the highway. You know it's gonna be really bad, but somehow you can't stop yourself from looking (or reading in this case).
It never ceases to amaze me.
The Open Source freaks can be so predictable sometimes. As expected, most folks seemed to have a 3 year old (or worse!) view of MySQL's features and limitations. And, as expected, there was a big "What about PostgreSQL?! It has more features!!!" contingent.
Reality check. It's not all about features. It's about the best tool for the job. For a lot of folks, MySQL really is that tool. Get over yourselves.
Imagine you have a blog with a couple hundred folks who read it on a semi-regular basis. Some of them are your co-workers. Further imagine that you work for one of the world's best known tech brands. Finally, suppose that you know at least two of your company's vice president's read (or have read) your blog.
Would you blog differently? Shy away from criticizing your employer? Purposely avoid work-related topics?
I hope not.
You might wonder, as I have, what would happen if your company's PR folks caught on. (Maybe they have?) Would they care? Should they care? Or is it more of a "don't ask, don't tell" situation?
What if those PR folks also knew that tech journalists were reading it, hoping to get ideas for a story about your company? (That's a funny story that I really wish I could tell.)
What about shareholders? Is that part of what being a public company in the Internet age is all about? Having employees who blog about their company from the inside. It probably won't be long before someone stands up at an annual shareholder's meeting after the CEO has made some bold claims and says, "I was reading one of your employee's weblogs. She seems to think that won't work at all, and she provided very compelling evidence." How might that CEO react? Would the blogger lose her job?
What about your competitors? Surely the smart ones are reading 'em. Aren't they?