Donate-large

If you like this blog, please make a little donation.

It's a secure process, and with your generosity I will be able to review more hardware and software.

Just click the "Donate" button below and follow the easy instructions, and I will thank you eternally.

Sunday, April 17, 2011

One network filesystem to rule them all, SMB vs AFP

We live in a world of Windows.

We use our pendrives with Windows filesystems, our networks are connected with the Windows network filesystem, all of that whatever we use or not the Windows operating system.

The Windows network filesystem, SMB (from Server Message Block, also called CIFS), was designed in the 80s for DOS and OS/2. It is supported on all other filesystems by the Samba package.
Windows Vista introduced a new version SMB2, that removes all the unneeded commands and simplify the needed ones, giving a huge performance overall.

Apple however always used AFP (from Apple Filing Protocol), their own network filesystem. The Windows server versions can act a server for this filesystem, as well as mostly all the UNIX systems using the netatalk package.

Unfortunately only Mac OS and Mac OS X can act as clients. And usually, aren't used so.

Because of commodity, being too vague or any other reason, in networks consisted only of Macintosh computers or in mixed environments, we tend to use always the SMB protocol.

The following benchmark demonstrate why SMB should be avoided at all, whenever its possible.

The test were done using bonnie++, over a Gigabit Ethernet network, with both a Mac OS X client and server.

Version 1.93c Sequential Output Sequential Input Random
Seeks
Concurrency Size Per Char Block Rewrite Per Char Block
K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU /sec % CPU
AFP 1 2000M 347 98 15924 7 16234 10 689 98 130749 16 1361 36

Latency 112ms 1620ms 1279ms 36316us 1169ms 221ms
SMB1 1 2000M 2 8 11416 8 4504 6 1 8 7642 5 787.2 19

Latency 6048ms 1448ms 2001ms 6385ms 565ms 402ms

In this test we can clearly see the advantages of using AFP over SMB.

Writing byte at byte, SMB gets 2 Kb/sec while AFP gets 347 Kb/sec. That's 173 times faster.
Writing sequentially, SMB gets 11,416 Kb/sec while AFP gets 15,924 Kb/sec. That's 39% faster.
Rewriting, the difference gets bigger, SMB at 4,504 Kb/sec and AFP at 16,234 Kb/sec, or 260% faster.

On reading, byte at byte, SMB gets just 1 Kb/sec and AFP gets 689 Kb/sec, of course, 689 times faster.
Reading in blocks, SMB gets 7,642 Kb/sec and AFP gets to the limits at 130,749 Kb/sec, or 1610% faster.

SMB is able to do 787.2 random seeks per second and AFP is able to do 1361, almost twice.

Also on all cases, the CPU usage is higher when using SMB.

Conclusion is clear, on all possible cases (Mac, UNIX or Linux server and Mac client) AFP is a MUST.

There are commercial solutions that make Windows computers able to act as an AFP server and client.
However my recommendation is not to use them, but directly to not use Windows computers in networked environments.

When Mac OS X Lion comes public I'll test their SMB2 implementation that should give a boost in performance.

2 comments:

  1. Hey,

    Would love to see some results using Lion and SMB 2, since I'm primarily a mac user, but putting together a HP Microserver as a NAS and may end up using Win 2008 R2 on it...

    ReplyDelete
  2. The problem comparing AFP vs SMB2 is that currently there is no way :p

    I'll explain myself.

    For the sake of an accurate benchmark, the network mount must reside on the exact same server for each protocol, that's, hardware, software, network card, filesystem, disks, etc, etc, etc.

    Test is done against a Linux server using Samba as the SMB 1.5 (CIFS) server and Netatalk as the AFP 3.2 server.

    Lion introduces the AFP 3.3 protocol (with speedups), and Vista introduced SMB 2 protocol, currently not implemented in any Linux server.

    Btw, I don't know if the Lion's SMB server is 1.5 or 2 (probably it's 1.5), and I only have one Lion machine.

    When I get another Lion machine, or the Linux software is updated to lastest protocol revisions I'll do a test. Until that, I cannot test both protocols using same testing rig, sorry.

    ReplyDelete