Archive
MySQL 5.5.4 looks awesome.
Been at the MySQL conference the last few days, and I have to say, I’m really blown away by MySQL 5.5.4‘s improvements. Last year I keynoted and I begged Oracle on stage to realize that MySQL and InnoDB under one roof represented opportunity. It’s clear they heard the community – this is some serious progress, and right when we needed it.
Jeremy Zawodny’s blog post covers most of the stuff I’m really excited about, and there are some great detailed technical slides here and here, but I wanted to go into a little more detail on one important improvment: We’ve been plagued by MySQL’s undo slot limits for an awfully long time. Basically, you could have 512 INSERT transactions and 512 UPDATE transactions running at once, for a grand total of 1024. If you use INSERT … ON DUPLICATE KEY UPDATE, though, it takes two of those spots, meaning you get 512 concurrent transactions. On modern hardware, it’s trivially easy to hit this limit.
I’ve had an Enterprise support ticket open for years on the issue, there’s been a MySQL bug for a long time, and there was basically no movement. In fact, I’d gotten so frustrated about this issue, I’d basically decided this year was our last year of Enterprise MySQL support. It was one of the sole reasons we paid for support for the last few years – the promise that a fix was just around the corner. I felt good about voting with my dollars, and contributing back to a core technology we depend on, but enough was enough.
Lo and behold, it’s fixed! You can now have a whopping 128K transactions in flight. Best of all, it’s far more performant than it used to be! And craziest of all? If you run 5.5.4 on a database, then roll back to some older release, the change still takes effect. Backwards bug and performance fixing – that’s a new one on me.
THANK YOU ORACLE!
Shameless plug – we’re hiring. And it’s a blast.
Nasty Bug: Safari doesn't cache stuff.
photo by: Simon Barnes
I swear I’m not making this up.
I couldn’t believe my eyes when I found it. Safari is one of our favorite browsers, and we love their work on standards compliance and speed, particularly JavaScript, but this particular bug is really driving us crazy. I’ve logged it with Apple (#5786274), and a fix is promised, but in case you’re getting hit with this and are as baffled as I was, here are the details:
- If your computer has less than 1GB of RAM, Safari fails to cache items larger than 104,857 bytes.
- If your computer has more than 1GB of RAM, Safari failes to cache items larger than 209,715 bytes.
- JPEGs, at least, are temporarily cached in RAM. Whew. But upon browser restart, you’ll see they didn’t make it to the disk cache, so you have to get them again.
- Other objects, like SWFs or videos, though, don’t even make it to the RAM cache, let alone disk. Load the same SWF back-to-back, and you’ve just transfered the bytes twice. Ugh.
Very easy to reproduce yourself from the comfort of your own home, so go for it. Just fire up HTTP Scoop or Wireshark or tail your server’s HTTP logs and start hitting stuff. Marvel at the # of excess bytes transferred across the wire that you didn’t need. 😦
Here are a couple of test URLs so you can see for yourself:
As a self-professed Apple fanboy, I can’t wait for a fix. In the meantime, we’ve had to jump through all sorts of hoops to ‘dumb down’ some of our most exciting new features. 😦
UPDATE: Yes, I’ve tried with every Cache-Control and Expires header known to man. No, it doesn’t make a difference. Try it yourself.
SmugMug's Don MacAskill 