hcoelho.com

my blog

Title only : Full post

Benchmarking PHP5 x Node.js

:

Long story short: one thing we did today was thinking what would be best language/framework to build an API: it should be stable under heavy load, fast, and capable of cpu-intensive operations; we ended up with 2 alternatives: PHP5 and Node.js and decided to do a little benchmarking to find out which one would be the best.

For the first test, we set up a server with virtual machines of Apache + PHP5 and another with Express + Node.js and used Siege, a stress tester, to benchmark both servers. Siege creates several connections and produces some statistics, such as number of hits, Mb transferred, transaction rate, etc. For both servers, we used 4 combinations of settings:

  1. 1 core and 1,000 concurrent users
  2. 4 cores and 1,500 concurrent users
  3. 1 core and 1,500 concurrent users
  4. 4 cores and 1,500 concurrent users

The tests consisted in a very simple task: receive the request of the user, perform a SELECT query in a database, and return the raw results back - we tried to keep the tests as similar as possible. The database used was PostgreSQL, located in another virtual machine.

These are the source codes we used for the tests:

JavaScript

var express = require('express');
var pg = require('pg');

var config = {
  user: 'postgres',
  database: '...',
  password: '...',
  host: '...',
  max: 10,
  idleTimeoutMillis: 30000
};

var app = express();
var pool = new pg.Pool(config);

var query = 'SELECT * FROM testtable;';

function siege(req, res, next) {
    pool.connect(function (err, client, done) {
        if (err) throw err;

        client.query(query, function (err, result) {
            done();
            if (err) throw err;
            res.json(result.rows);
        });
    });
}

app.get('/siege', siege);

app.listen(3000, function () {
  console.log('Example app listening on port 3000!');
});

PHP

$connection = pg_connect("host=... dbname=... user=... password=...");
$result = pg_query($connection, "SELECT * FROM testtable");
echo $result;
pg_close($connection);

These are the results:

Result 1 core
1,000 users 1,500 users
Node.js PHP Node.js PHP*
Number of hits 39,000 4,300 2,000 -
Availability (%) 100 95 66 -
Mb. transferred 11 0.06 0.56 -
Transaction rate (t/s) 1,300 148 800 -
Concurrency 655 355 570 -
Longest transfer (s) 0.96 28.14 1.16 -
Shortest transfer (s) 0.08 0.15 0.11 -
Result 4 cores
1,000 users 1,500 users
Node.js PHP Node.js PHP*
Number of hits 55,000 5,100 14,000 -
Availability (%) 100 98 93 -
Mb. transferred 16.02 0.07 4 -
Transaction rate (t/s) 1,800 170 1,700 -
Concurrency 19.6 424 73 -
Longest transfer (s) 0.4 28.16 1 -
Shortest transfer (s) 0 0 0 -
  • Aborted (too many errors)

I really was expecting the opposite result, Node.js seems to be incredibly fast in comparison to PHP for these operations.

For the next test, we tried to focus on cpu-intensive operations by running the following algorithm that searches for the first N prime numbers (yes, they could be optimized, but the purpose of the test was to make them cpu-intensive):

JavaScript

var express = require('express');
var app = express();

app.get('/', function (req, res) {
    function isPrime(num) {
        for (var i = 2; i < num; i++) {
            if (num % i === 0) { return false; }
        }
        return true;
    }

    function display(n) {
        var count = 0;
        for (var i = 3; i < n; i += 2) {
            if (isPrime(i)) { count++; }
        }
        console.log(count);
    }
    display(70000);
    res.json({});
});

app.listen(3000, function () {
  console.log('Example app listening on port 3000!');
});

PHP

function isPrime($num) {
    for ($i = 2; $i < $num; $i++) {
        if ($num % $i === 0) { return false; }
    }
    return true;
}

function display($n) {
    $count = 0;
    for ($i = 3; $i < $n; $i += 2) {
        if (isPrime($i)) { $count++; }
    }
    echo $count;
}

display(70000);

My expectations were that PHP would perform much better for this kind of tasks. These were the results:

Result 70,000 numbers 100,000 numbers
Node.js PHP Node.js PHP
Seconds 2 26 2.5 Timed-out after ~33 seconds

I don't know what to think anymore. I guess we are not using PHP.

cdot node php 

First day at CDOT and ASP.NET on Linux

:

The first post on my blog already started wrong: this is not really my first day at CDOT - I previously worked in the ZAPP system (Z3 project) for 4 months, but it was my first day for the ENGINEERING.com project! So here I go again, starting a new blog about my adventures on CDOT.

The orientation day is not exactly very exciting if you are not here for the first time: we discussed about the project and how to set up the workstations, practiced a little bit with GitHub, and attend to a meeting that gives us relevant information about CDOT. It was a challenge, however, to make a solid plan for our workstations: I am not exactly good with Linux (any Operating System, actually), and on top of that, the existing system for our project is written with ASP.NET an "open source" (it is open source, but certainly doesn't feel like it) framework developed by Microsoft. Don't get me wrong: I actually like ASP.NET: the framework itself is great, most people would agree that it is a very solid tool, liking it or not; the problem is that it is not easy to deploy in non-Windows machines without Visual Studio.

Microsoft announced ASP.NET's open-sourceness (that's how I call it) in 2014, which I think is a great move; but even after almost 2 years, there are many good, but no excellent way of deploying it without Windows. Probably the most acceptable solution for this is Mono, which is free and open source! The drawback of Mono, however, is that it is still not able to deploy the most up-to-date versions of ASP.NET - with "most up-to-date" I mean versions from the last 4 years: the latest version of ASP.NET is 5.0, while Mono seems to only accept 4.5 projects.

Another problem, besides deployment, is the IDE: for frameworks like .NET, it is important to have an actual IDE for your project (vim will not take you very far: it is super fast if you know it well, but I don't feel like the biggest constraint in programming is our typing speed); up to now, there are no IDEs to match Visual Studio and its ASPness, unfortunately. Oh, except for an excellent, open-source, cheap (free if you are a student), lightweight, snappy and fantastic one made by JetBrains (which also has IDEs for C, C++, Java, JavaScript, Ruby, Python, PHP, iOS, and SQL - all with similar qualities): the IDE is called Rider - it is still under development, but stable enough to be used. I'm using it.

We are feeling optimistic about this project: despite Mono not being able to run the latest version of ASP.NET, it is likely that the current application wasn't built with it (we still don't have access to it). We were also successful installing Mono and Rider in our machines, meaning we can be (hopefully) very close to deploy the system in a Linux environment. Developing .NET in such an environment was an alien concept some years ago. We also downloaded an ASP.NET virtual machine from TurnKey GNU/Linux, which can come in very handy for deployment and testing.

Now we shall wait. Hopefully we will have access to the actual system soon, so we can deploy it and really start working on our project.

cdot asp.net