Hash algorithms

Either Murmur2 or FNV-1a would be a good fit, according to the answer on StackExchange.

Syn Attack Protection

In a performance test, a bug was reported: a web application cannot handle clients' requests.

Server side:

• more than 10k TIME_WAIT;
• no error - no entry in Event Log or log files;
• performance is OK (by measuring CPU, MEM, DISK, etc. using performance counter)
• except the counts of received requests and processed requests are under expected
• the count goes to 0 from certain time for certain clients in the order of test load (the most heavy working client gets blocked first)
• the firewall is disabled
  

Client sides: all clients are running the same tests using the same test tool, except for the test data and test load

• for certain client, if it fails, it fails forever
• generates the following exception: System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
  

There seems no obvious errors in source code, both server side and client side.

Finally, I figure out it could possibly be the Syn Attack Protection problem, which is enabled by default and cannot be changed since Windows Vista.
In our case it's not like a typical syn flood attack, but based on the Cause analysis of the "General Network Error" of BizTalk, it could possibly be a Syn Attack, and protected by Windows 2008 SP1.

Other resources:
Next Generation TCP/IP Stack (and especially the changes to registry)
WinNT TCP/IP May Reuse TIME-WAIT Connections Prior to 2MSL

Too many TIME_WAIT:
System.Diagnostics.Stopwatch/QueryPerformanceCounter not working on Amazon AWS, other symptoms, and the solution
The cost on server side

The socket also ties up that particular src/dst IP address and port so it cannot be reused for the duration of the TIME_WAIT interval. (This is the intended purpose of the TIME_WAIT state.) Tying up the port is not usually an issue unless you need to reconnect a with the same port pair. Most often one side will use an ephemeral port, with only one side anchored to a well known port. However, a very large number of TIME_WAIT sockets can exhaust the ephemeral port space if you are repeatedly and frequently connecting between the same two IP addresses. Note this only affects this particular IP address pair, and will not affect establishment of connections with other hosts.

HttpWebRequest related
Howto keep connection live
Timing out after awhile;

Worth a read
Avoiding TCP/IP Port Exhaustion: only the Cause section
A short explanation on TIME_WAIT
TIME_WAIT Effects on Busy Servers: maybe outdated, and tested on SunOS
64k ephemeral port limit is per IP address, not per machine

Outdated
Configure the max limit for concurrent TCP connections
How to harden the TCP/IP stack against denial of service attacks in Windows Server 2003
Registry Settings that can be Modified to Improve Network Performance
Exhaustion of the ephemeral ports
Problems when you make Web service requests from ASP.NET applications
TCP settings that can impact BizTalk Server
MaxUserPort and TcpTimedWaitDelay

Byte order fallacy and optimization

In Rob Pike's The byte order fallacy, he advocates portability and simplicity, but failed to address the performance issue (wrong to modern processors).
"byte order doesn't matter" - for you local machine; but, should be taken care when handling IO.

The optimization is more interesting: that code block could be optimized by CLang, but not GCC.

Comments from Chris Lattner:

In general, optimizing the original code to a single 32-bit load on little endian targets is not safe: the pointer may not be aligned. However, even after marking the pointer aligned, clang still misses the optimization.

Clang can successfully forward loads and stores when the accessed object is known.
Finally, Clang also optimizes the opposite: turning this code into a "bswapl" on x86.

You won't missing ntohl/htonl, right?
And there is network types support!

WOW64

Some time ago, I happened to know WOW64 is short for "Win 32 On Win 64" - WOW!

This time for a bug, I looked deeper.

• Changes to file system are more visible

File System Redirector
only system32 and most sub-folders are taken care of;
"Program Files" is not covered here, but by using environment variables;
for 32-bit and 64-bit programs, they use their own copies - redirected to different folders; the shared are bit regardless, like logfiles, hosts are plain text files;

• Changes to Registry are more error prone

Registry Reflection - it was used, now deprecated; using the share model;
Registry Redirector - copy model, in most recently versions of OSs
Registry Keys Affected by WOW64 - finally, copy model and share model co-exist

And even worse, Wow6432Node could generate recursive path; regedit handles this correctly;

But, most of us developers are not going to learn all this, or read the Best Practices for WOW64. We'd rather write our own functions, like check the OS's version, and make up the file/registry path by hand, instead of OS APIs, like IsWow64Process(), or environment variables.

Time related issues

* NTP was not designed to run inside of a virtual machine
* For long running applications, using 32-bit for timing could overflow; but, 64-bit could fail in another way

My calculation on Yahoo's job cutting

Yahoo! Statement

Yahoo! expects to realize approximately $375 million of annualized savings upon completion of all employee transitions. The company currently expects to recognize the majority of an estimated $125 to $145 million pretax cash charge relating to employee severance...

Based on these numbers:
* Average yearly salary: 375*1000/2000 = 187.5 K$/year (so an average employee, to be cut, gets half of that in hand or paid - 93.75K$/year?).
* Average years in Yahoo: (375/145, 375/125) = (2.586206896551724, 3.0) Year, if all/most of them get a n+1 compensation.

The first average number maybe meaningless;
The second average number might be the common evaluation of employees from a company's business view.

As mentioned here (in Chinese): Yahoo has 14000 employees in total.
Then, this is a 14% cut off, and most of employees are serving Yahoo less than 2 years.
So, Yahoo has/had pretty much fresh blood?

两个估算——雅虎将裁员2000人

雅虎将裁员2000人，每年节省3.75亿美元，裁员成本约为1.25亿至1.45亿美元。

据此估算：

• 平均年薪：3.75*10000/2000 = 18.75万 USD。
• 平均工龄：(3.75/1.45, 3.75/1.25) = (2.586206896551724, 3.0) Year。
• 员工分布：至少14%的员工，加入雅虎不超过2年。
  

第一个估算值，意义不大。
第二个估算值，如果高管也是按照 n+1 赔偿，还是有点参考意义——工龄对公司的意义，至少是财务上的。
第三个估算值，也没什么意义。或者说，雅虎（曾经）"生机勃勃"，有很多新员工可裁？