Putting Fusion Drive’s Performance in Perspective

Benchmarking Fusion Drive is a bit of a challenge since it prioritizes the SSD for all incoming writes. If you don’t fill the Fusion Drive up, you can write tons of data to the drive and it’ll all hit the SSD. If you do fill the drive up and test with a dataset < 4GB, then you’ll once again just measure SSD performance.

In trying to come up with a use case that spanned both drives I stumbled upon a relatively simple one. By now my Fusion Drive was over 70% full, which meant the SSD was running as close to capacity as possible (save its 4GB buffer). I took my iPhoto library with 703 photos and simply exported all photos as TIFFs. The resulting files were big enough that by the time I hit photo 297, the 4GB write buffer on the SSD was full and all subsequent exported photos were directed to the HDD instead. I timed the process, then compared it to results from a HDD partition on the iMac as well as compared to a Samsung PM830 SSD connected via USB 3.0 to simulate a pure SSD configuration. The results are a bit biased in favor of the HDD-only configuration since the writes are mostly sequential:

iPhoto Library Export to TIFFs

The breakdown accurately sums up my Fusion Drive experience: nearly half-way between a hard drive and a pure SSD configuration. In this particular test the gains don't appear all that dramatic, but again that's mostly because we're looking at relatively low queue depth sequential transfers. The FD/HDD gap would grow for less sequential workloads. Unfortunately, I couldn't find a good application use case to generate 4GB+ of pseudo-random data in a repeatable enough fashion to benchmark.

If I hammered on the Fusion Drive enough, with constant very large sequential writes (up to 260GB for a single file) I could back the drive into a corner where it would no longer migrate data to the SSD without a reboot (woohoo, I sort of broke it!). I suspect this is a bug that isn't triggered through normal automated testing (for obvious reasons), but it did create an interesting situation that I could exploit for testing purposes.

Although launching any of the iMac's pre-installed applications frequently used by me proved that they were still located on the SSD, this wasn't true for some of the late comers. In particular, Photoshop CS6 remained partially on the SSD and partially on the HDD. It ended up being a good benchmark for pseudo-random read performance on Fusion Drive where the workload is too big (or in this case, artificially divided) to fit on the SSD partition alone. I measured Photoshop launch time on the Fusion Drive, a HDD-only partition and on a PM830 connected via USB 3.0. The results, once again, mirrored my experience with the setup:

Photoshop CS6 Launch Time (Not Fully Cached)

Fusion Drive delivers a noticeable improvement over the HDD-only configuration, speeding up launch time by around 40%. A SSD-only configuration however cuts launch time in more than half. Note that if Photoshop were among the most frequently used applications, it would get moved over to the SSD exclusively and deliver performance indistinguishable from a pure SSD configuration. In this case, it hadn't because my 1.1TB Fusion Drive was nearly 80% full, which brings me to a point I made earlier:

The Practical Limits of Fusion Drive

Apple's Fusion Drive is very aggressive at writing to the SSD, however the more data you have the more conservative the algorithm seems to become. This isn't really shocking, but it's worth pointing out that at a lower total drive utilization the SSD became home to virtually everything I needed, but as soon as my application needs outgrew what FD could easily accommodate the platform became a lot pickier about what would get moved onto the SSD. This is very important to keep in mind. If 128GB of storage isn’t enough for all of your frequently used applications, data and OS to begin with, you’re going to have a distinctly more HDD-like experience with Fusion Drive. To simulate/prove this I took my 200GB+ MacBook Pro image and moved it over to the iMac. Note that most of this 200GB was applications and data that I actually used regularly.

By the end of my testing experience, I was firmly in the category where I needed more solid state storage. Spotlight searches took longer than on a pure SSD configuration, not all application launches were instant, adding photos to iPhoto from Safari took longer, etc... Fusion Drive may be good, but it's not magic. If you realistically need more than 128GB of solid state storage, Fusion Drive isn't for you.

The Application Experience Final Words
Comments Locked

127 Comments

View All Comments

  • EnzoFX - Saturday, January 19, 2013 - link

    Yes, exactly. This is the point of computers. It always bothers me when self-proclaimed experts come on tech sites dismissing anything of the sort. I can imagine them saying " Well just do RAID, or just manage the files yourself" and then stating that such a solution as this as unnecessary, when they clearly don't understand the point. They only work to slow such efforts down.
  • name99 - Saturday, January 19, 2013 - link

    If your friend has a mac, and if they can borrow enough temporary storage (to copy and hold the files while you make the change over), what I would recommend is that they stripe their 3 HDs together as a single volume. This can be done easily enough using the Disk Utility GUI.
    (Honestly they should have enough temporary storage anyway, in the form of Time Machine backup).

    This will give a single volume (less moving around from one place to another) with 3x the bandwidth (as long as each hard drive is connected to a distinct USB or FW port).

    [If the drives are of different sizes, and you don't want to waste the extra space, it is still possible to use them this way, but you will need to use the command line. Assume you have two drives, one of 300GB, one of 400GB --- the extension to more drives is obvious.
    You partition the 400GB drive as a 300GB and 100GB partition.
    You then
    (a) create a striped RAID from the 300GB drive and the 300GB partition
    (b) convert the 100GB partition to a (single-drive) concatenated RAID volume [this step is not obviously necessary but is key]
    (c) create a concatenated volume from the volume created in (a) and that created in (b).
    This will give you 600GB of striped storage, plus 100GB at the end of slower non-striped storage. Can't complain.]

    Not a perfect solution, but a substantial improvement on the situation right now.

    I don't know the state of the art for SW RAID built into Windows so I can't comment on that.
  • guidryp - Friday, January 18, 2013 - link

    Really this seems like a solution for the lazy or technically naive.

    Manually managing your SSD/HD resources allows you to speed up based exactly on your own priorities, instead of having some software guessing and making a bunch of unnecessary copies to/from the SSD/HD.

    You get faster performance of pure SSD where you want it. Less hiccups from background reorganization, and less unnecessary stressing of the SSD.

    Also it isn't exactly difficult to manage manually. Use the SSD for your main OS/Application drive and whatever else you deem important for speed up.
  • zlandar - Friday, January 18, 2013 - link

    "Really this seems like a solution for the lazy or technically naive."

    If everyone was technologically literate spam wouldn't exist and computer companies wouldn't need customer service for stupid questions.
  • jeffkibuule - Friday, January 18, 2013 - link

    Aren't a lot of solutions built for the technologically naive?
  • NCM - Friday, January 18, 2013 - link

    Apple's principal market, especially for the iMac, is to home and small business users. Once again dragging out the familiar, but still applicable, automotive metaphor, I'll point out that most people don't want to work on their cars. They just want to drive reliably to wherever they're going. That's the need that Apple's FD addresses, and it seems to do so rather well.

    Sure, the price adder is a bit higher than one might hope, but probably not so much that it'll frighten away prospective buyers.

    Interestingly though, it lost our sale. I was ready to order another iMac with a 256GB SSD and a 1TB HD for the office. We keep most of the files on the server, but a 128GB SSD application/boot drive is a bit tight. However a 256GB SSD is just right, allowing plenty of free space to maintain SSD performance. The additional 1TB HD is then repurposed for local Time machine backup.

    But that's not an option for the new iMac, which offers only HD or FD. And I'm not about to make a risky and warranty busting expedition into its innards in order to roll my own SSD solution (although my own MacBook Pro has a self-installed 512GB SSD).

    Instead I ordered up a 256GB SSD Mac mini, plus what turned out to be a very nice 24" 16:10 IPS monitor from HP. Although I would have preferred the all-in-one iMac solution for a cleaner installation without gratuitously trailing cables, the Mac mini with SSD, i7 and 8GB RAM options is fast and effective.
  • ThreeDee912 - Friday, January 18, 2013 - link

    Wasn't this the kind of thing said about virtual memory in the 60's and 70's? Some people back then thought manually managing the location of everything in memory would make things more efficient, until some guys at IBM (or was it Bell Labs?) showed you saved heck of a lot more time letting the machine do it instead of trying to move things around yourself.

    This Fusion Drive really does reminds me of virtual memory. RAM and HDD mapped in a way so it appears as a single type of memory. Most stuff gets placed into RAM first, some stuff spills over onto the HDD, and stuff gets copied back and forth depending on how frequently it's used. The fast RAM is first priority, but there's the HDD as kind of a backup.

    It's a bit different from a caching setup, where the computer has to "guess" a bit more about what should really be on the SSD. It's like the HDD is priority here, while the SSD is secondary.

    And just like with virtual memory, none of this would matter if you had a huge amount of RAM or a very large SSD.
  • web2dot0 - Saturday, January 19, 2013 - link

    Great comment ThreeDee9. Someone with a rational mind.

    To all those "experts" who claim that it's better to manage it yourself, you can also write every program in ASM. It'll be fast and small, but I'll be done with the project in 1/10 the time. The point is .... the product is not meant to provide "absolutely the best possible configuration". It's meant to be best all around solution.

    If you guys still don't get it. Well, I guess all these years in the education didn't really help you because logical people think rationally.
  • psyq321 - Monday, January 21, 2013 - link

    Hmm... is it just me who finds it slightly disturbing that we are comparing memory management (and, in some posts later, C vs. assembly coding) with the decision on how to organize documents/files?

    I would say that the intellectual investment is not really to compare.

    Which does not mean that I have anything against SSD caching solutions - on the contrary, I see nothing wrong with ability to transparently manage the optimal location for the content.
  • TrackSmart - Friday, January 18, 2013 - link

    A month ago, I would have said the same thing, but see my other post to understand why more people need this than you think. The proportion of people who can handle manually segregating their files is much, much smaller than most of us realize. I have three systems setup with both an SSD and a HDD and have no troubles. But we are a tiny, tiny minority of users.

Log in

Don't have an account? Sign up now