binaryfactory.ca

In an attempt to see if it was worth it to switch to Google’s DNS, I made a quick performance comparison.

Using DNS Performance Test (DPT) , a tool that uses a random list of domain names, I tested performance over 500 (502 to be precise) queries. First, to my ISP’s servers, then to 8.8.8.8 (Google’s).

This test is far from scientific as I ran both test back to back, didn’t try multiple periods in the day, etc. But whatever, it’s fun !

ISP / Google

Worst Query time: 1166ms /  880ms

Average query time: 167ms / 145ms

Timeouts: 8 / 4

So it would seem that for now Google is slightly faster. However, this is probably nowhere near enough to convince me to give Google some even more logs to profile me, no matter what the privacy policy says..

Here is a small test I did on DFS Performance.

Setup:

1 Virtual machine running 2003 sp1 as a DC+File server

1 Virtual Machine running 2003 sp1 as a member server

1 Other Windows 2003 sp1 machine that will act as a second DFS host later on 

DFS Root and target folder located on the DC. It shares a folder that contains about 5600 sub folders, but no files for our test.

 

Locally on the DC/DFS box:

Removing an ACE from the ACL at the top takes about 3seconds. Forcing it to re-apply on all subfolders took about 30seconds.

 

From the member server, using the non-DFS path (The path is the link target of the DFS)

Adding an ACE and saving the ACL took approximately  210 seconds.

Removing the same ACE and saving took exact 202 seconds (I had the patience to really watch it until it was done this time!)

 

From the member server, using the DFS path

Adding an ACE and saving the ACL took approximately 225 seconds.

Removing the same ACE and saving took 208 seconds

 

From the member server, using the DFS path, after we add a second DFS server to host the content with FRS enabled (making sure my Active link is the same box as earlier)

Adding an ACE and saving the ACL took exactly 498 seconds!

Removing the same ACE and saving took 492 seconds !

 

From the member server, using a totally separate share on the server, which is not part of DFS at all

Adding an ACE and saving the ACL took approximately 119 seconds

Removing the same ACE and saving took approximately 90 seconds

 

Table of Results

Conclusion

Obviously, setting ACLs locally on the file server is about 67 times faster in my case. Not really a surprise.

 

On a brand new, best-of-worlds system, setting ACLs through a DFS path is not much longer than with the direct SMB Path of the target. The differences in my test are too small to say there is even a difference, as this is not a 100% controlled environment.

However, setting the same ACLs on a share that is not part of DFS is close to twice as fast.

 

Notes

If you’re using Windows 2003 with no SP or Windows XP sp1, download this .

My test was done on 2003 sp1 servers, since this is what I had installed right now for compatibility with a client’s system. However, DFS was much improved in 2003 R2, especially regarding DFS replication VS FRS. I would expect performance to be better on an R2 system, and I will run the test when I get the chance to ! Maybe the difference will  be smaller..who knows!