Windows Azure中的Node.js可伸缩性问题

Question

For an academic essay I'm comparing Asp.Net and Node.Js web application deployed in windows azure.

I'm testing and measuring a request that calls a rest service that just hold for 7 seconds and response the request after it. The idea is measure how Node.Js and Asp.Net will behave in this situation.

node.js is very fast in load tests with 250 users when I test in my own computer. The average of time response is around of 7 seconds, just the time of rest call response. Asp.Net is around 1-2 seconds slower.

When I do the same test with these app deployed in Azure, the results change a lot. While Asp.Net keep almost same results, Node.JS takes more than 100 seconds to respond with the same test, and it doesn't matter the size of cloud service.

here is the function that calls the URL that hold for 7 seconds:

function sleep(response, request) {
    var currentQuery = url.parse(request.url).query;
    var time = querystring.parse(currentQuery).time;

    var options = {
        host: 'whatever.cloudapp.net',
        port: 80,
        path: '/?sleep=' + time,
        method: 'GET'
    };

    http.request(options, function () {
        response.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' });
        response.write('response ok.');
        response.end();
    }).end();

Anyone knows whats is happening? Why node.js seems to be not scalable with I/O bounds when deployed in windows azure?

Thanks in advanced

Answer 1

The performance difference between CS and WA is not normal, not with these numbers you refer to. But it is very hard to give the exact answer why it happens. It may be "noisy neighborhood", may be the long time to run for a first time (that may be solved for WA with Always On in settings, and with Cloud Services a little longer, but it can be solved), because there is the idle timeout, and CS WebRole, for example, will recycle after, as far as i remember, 20 minutes of idle.

The simplest way to eliminate the possibility that it can be the intermittent issue is to redeploy the CS to the different region using the large VM in the beginning.

I suspect that the performance difference reason may be in the different nature of CS and WA - CS is more like a VM that will spin out when you deploy the solution, and WA likely not.

If you have the opportunity, you may analyze what is going on, using the official performance CS guidance .

And i would try to test the new Service Fabric offering instead of the classic CS, as that may gives some interesting insights into the cloud offerings.