" /> Status for Andrew DeFaria: September 2012 Archives

« August 2012 | Main | February 2013 »

September 21, 2012

Speed of network reads as opposed to network writes

I was asked to test the difference in speed between network reads and network writes. Now, of course, a lot of this is highly tuneable and depends on various things like protocol used (NFS vs SMB), whether you are writing over a LAN or a WAN, the rated speed of those links (1G vs 100M vs 10M or less), as well as the options used (for NFS things like rsize, wsize to name a few). However as currently configured the following test was done:

I created a file of some size (336M) which I will copied between local and remote file systems using a push strategy and a pull strategy. Lacking having root capability needed to mount filesystems via NFS between say San Jose and Irvine or playing around with SMB I decided to use my home directory, which is NFS mounted, and the local file system of /tmp.  By push I mean that cp copying the file from /tmp to my home directory which is NFS mounted thus over the network. By pull I mean that cp was copying the file from my NFS mounted home directory and writing it to /tmp. Therefore push = local reads with network writes and pull = network reads and local writes. Here are the results...

First I did a little loop:
Xl-irv-05:i=0; while [ $i -lt 100 ]; do
/usr/bin/time -f %E -a -o pull.csv cp ~/336megfile /tmp/336megfile
let i=i+1
done

This pulls this 336megfile 100 times from my home directory to the local /tmp directory. The GNU time command is used to capture the time each of these takes. Network conditions and system workloads can cause this to vary so I take 100 samples.

Similarly this loop does the push:
Xl-irv-05:i=0; while [ $i -lt 100 ]; do
/usr/bin/time -f %E -a -o push.csv cp /tmp/336megfile ~/336megfile
let i=i+1
done
Doing a little Excel yields:



Bottom line:

Pull Push Diff
Average 0.79 4.29 5.45
Pulling data where the writes are local took on average 0.79 seconds and is 5.45 times quicker than pushing data where the writes are over the network which took, on average, 4.29 seconds.

Moral: If you have to work over a LAN or WAN, try to make your writes local...

September 14, 2012

Shebang and script interpreters

Turns out that you cannot put a script as the interpreter for your #! line. It must be a binary. Also, many IT departments forced with supporting various Unix/Linux's often have a set of scripts that "do the right thing(tm)" to set up an environment for the target architecture then execute the architecturally appropriate binary. I did this way back with /app server.

So what do you do when you are say writing an expect script and wish to use #!/app/expect? The trick is to use something like #!/usr/bin/env /app/expect. Most people are familiar with using env(1) to print out the environment and it turns out it does - if you don't give it any other parameter. But it's real main purpose is "run a program in a modified environment". So if you wish to use an interpreter that is a script use #!/usr/bin/env /path/to/script as your shebang line.