最近在看 Interactive Computer Graphics: A Top-Down Approach with WebGL ，里面看到一个很有意思的几何问题，分享一下。

Recently, I'm doing some experiments to try to rewrite our Nodejs service in a more maintainable style. I'd like to write several posts to share my findings.

Last week we try to reproduce an incident in our production system which is caused by an eleviation of HTTPS connection creation rate. The service was flooded by more than 2000 concurrent connections per server at peak.

When writing unit tests, the most ugly & painful & stupid thing you might have to do is to expose some internal implementation of your module to the testing code so that:

• It is easier to enumerate all possible conditional branches to cover some edge cases; (although if you have a complex design, you can always achieve this by mocking things, however sometimes it's an overkill)
• It is possible to inspect side effects of your code; (accept the dark side of the reality, you cannot totally avoid side effects)
• It is easier to replace some dependencies with mocks. (although if you have a good design, you should be able to inject all dependencies, but it's not a common thing in javascript realm)

At Hulu, we use Nodejs to build a proxy or orchestration service to expose APIs to our client applications in order to provide a unified interface (in API schema) which hides the complexity to deal with our versatile backend “micro-services”.

The reason we choose Nodejs over other technologies is that its asynchronized nature perfectly fits the requirements of the service:

• Handling large number of concurrent clients;
• Requesting backend micro-services to get the data, where most of the time is spend on IO;
• Enhancing the backend response with data from other backend micro-services.

This is a typical front-tier API service that has low CPU consumption and high concurrent IO requirement.

However when you deploy the application to production, it is very likely that you would hit CPU bottleneck if you are not careful enough when writing code. Javascript is so flexible that can easily get you trapped into performance problem if you don't understand the execution engine (v8) well enough. Recently, I spent a lot of time doing profiling and investigating the performance issues of our service.

In this post, I'll list some tools and techniques I have used to profile/debug Nodejs program for daily development and production trouble-shooting as a summary of the work I've done.