Posted on

Mavo!

I discovered Mavo and nothing will be the same now!
http://mavo.io

 

Posted on

NodeJS vs PHP – a quick performance comparison

NodeJS VS Php

This is not a complete analysis, but only a vision on IT services which I am responsible for my Company. So it cannot be taken as an analytical documentation, but only as an experience on my working field.

I am running many machines with MEAN stack (MongoDB+ExpressJS+AngularJS+NodeJs) on our corporate Amazon AWS cloud servers and some machines based on traditional LAMP stack (Linux+Apache+MySQL+Php). In the latest months the developing effort of the Company was basically phagocytized by NodeJS fixes, with only a very few activities made on Php. We have to consider that now the Company where I work has 6 main softwares and only 2 of them are made on Php.

Normalizing the effort-per-service and leveling their importance and complexity I could find the following differences.

Bug-fixing

Activities on Php required some hours/man or sometimes minutes to be performed; on the contrary, bugfixings and similar activities on Node required days or weeks/man to be completed.

Improvements

Building new simple functionalities costed some hours/man on Php, and days/man on Node.

Server performances

Comparing two very similar servers where I run services that should perform in the same way, I could find the following differences. NodeJS server compared with Php server (same type of machine and same amount of average requests per 5 minutes) with installed 2 similar softwares (in terms of activities: DB connections; data elaboration; size of outputs):
The Php machine stays always under 1% of CPU
The NodeJS machine has many peaks over the 5% and sometimes reaches 15% of CPU.

See the attached images

NodeJS machine CPU performances
NodeJS machine CPU performances

 

Php Machine CPU performances
Php Machine CPU performances

Conclusions

I can conclude only what I suspected for years now: Node is still a technology that is not optimized and is still CPU consuming (and “man” consuming!).

It still needs much more maintenance than monolithic stacks, and also the dispersion of packages (npm modules) and the sometimes useless complications make the work on it much more complicated than on Php.

But this is the direction the World is moving on now, so we need to accept this evil that would be completely unnecessary, but that is growing so fast that you cannot avoid using it. And I have to say: unfortunately!

 

 

Posted on

Bye Bye Flash… again?

Bye Bye Flash… again? Yes, but this time seriously!

It was a long time ago when we heard about “the end of Flash” on our browsers.

But it simply never happened. Chrome and Firefox continued to support this technology.
Then Firefox stopped it last year (also if nobody cared about!).

 

Now it looks like the real end is finally arriving: the reason? It’s called “the power of Google Chrome“.
When they decide it, it’s gone.

 

So it is arrived, the so dreamt/feared end of native support for Flash on Chrome.

From version 55, Chrome starts to block Flash by default: if you want it, you need to enable it from the Chrome “flags” (chrome://flags/).

What does it mean for a common browser user that never opened the chrome flags? Simple: the death of Flash based technologies such as some video players or many web games or some (hopefully!) websites.

 

Farewell Flash

You were a good friend.

 

REF. http://www.securityweek.com/chrome-55-patches-36-flaws-blocks-flash-default

Posted on

Should we use Node.JS for enterprise solutions? No, never!

I have many reasons why to avoid the use of Node.JS for enterprise solutions (webservices, websites, etc.), but I think that the following one is definitive:

  • Each error within a single script will make the whole application crash and will require a command-line restart

Let’s see the following example scenario:

Our Node.JS application (myapp) is a simple web app (it doesn’t matter which framework we use) that responds to the following 2 URIs: /myapp/test1/ and /myapp/test2/.
Those URIs are managed by two specific controllers: controller1.js and controller2.js.

Only controller2.js is bugged and so when /myapp/test2/ is requested by the browser it causes a fatal error.

Where’s the problem? Every web application works like that.
Yes, it is. But no other “old” application such as Php would crash within the single script error!
Let’s understand that also the other URL (/myapp/test1/) that contained the not bugged code will be unavailable within the node server crash. Unlike Php applications that will continue to correctly work if there is a single script with a fatal error.

I have many other reasons for thinking that Node.JS is just a toy, and not a professional tool, but I think this issue is one of the worst behaviours I could have ever found in a modern programming language.

Some interesting articles on the equivalence between node.JS and EVIL: