simple node.js module

Recently, I've been looking at node.js just to see something completely different than .NET.  In doing so, I'm building a small web application on top of express with jade.  Disclaimer: I'm not a javascript developer.  So, this for me is about both learning more about javascript and checking out alternative technologies.

I recently wanted to format a date in node.js like this: dd/MM/yyyy hh:ss.  There may be a better way to do it, but I decided to create a dateFormatter.js module so that I could see how to reuse some javascript code in node.js.

My first thought was that I needed to expose a new javascript object DateFormatter with the method format(d). Makes sense right?


So I set off by creating a file named dateFormatter.js that looked something like this:

	var DateFormatter = {
	format: function(d) {
	var d_date = d.getDate();
	var d_month = d.getMonth();
	d_month++;
	var d_year = d.getFullYear();
	var a_p = '';
	var d_hour = d.getHours();
	if (d_hour < 12)
	{
	a_p = 'AM';
	}
	else
	{
	a_p = 'PM';
	}
	if (d_hour == 0)
	{
	d_hour = 12;
	}
	if (d_hour > 12)
	{
	d_hour = d_hour - 12;
	}
	var d_min = d.getMinutes();
	d_min = d_min + '';
	if (d_min.length == 1)
	{
	d_min = '0' + d_min;
	}
	return d_date + '/' + d_month + '/' + d_year + ' ' + d_hour + ' : ' + d_min + ' ' + a_p;
	}
	}
	exports.DateFormatter = new DateFormatter();

view raw gistfile1.js hosted with ❤ by GitHub

And no, it didn't run at all.  Like I said, not great at using javascript in an OOP way!

What I didn't understand was that modules in node.js are wrapped as objects for you.

So by using the exports. I was really defining the public interface of my object.  So, I changed the code to this:

	exports.format = function (d) {
	var d_date = d.getDate();
	var d_month = d.getMonth();
	d_month++;
	var d_year = d.getFullYear();
	var a_p = '';
	var d_hour = d.getHours();
	if (d_hour < 12)
	{
	a_p = 'AM';
	}
	else
	{
	a_p = 'PM';
	}
	if (d_hour == 0)
	{
	d_hour = 12;
	}
	if (d_hour > 12)
	{
	d_hour = d_hour - 12;
	}
	var d_min = d.getMinutes();
	d_min = d_min + '';
	if (d_min.length == 1)
	{
	d_min = '0' + d_min;
	}
	return d_date + '/' + d_month + '/' + d_year + ' ' + d_hour + ':' + d_min + ' ' + a_p;
	};

view raw gistfile1.js hosted with ❤ by GitHub

And then I reference and use it like this:

	var dateFormatter = require('../utilities/dateFormatter.js');
	app.get('/page', function(req, res){
	var d = new Date();
	console.log(dateFormatter.format(d));
	// prints out 25/2/2012 1:06 AM
	...

view raw gistfile1.js hosted with ❤ by GitHub

At the moment, this works for me.

.NET Application Performance Degrades Over Time

So what do you do if your .NET application performance degrades over time and you don't know why?

There could be lot of reasons for a slow down over time. Anywhere from a slow memory leak to anti-virus. The best you can do is try to build evidence (data) about what area of the application to look first. Try not to talk it over with many devs because everyone will have a different opinion about what might be wrong. Get the data!

How to get the data:

perfmon perfmon is your friend. There are a lot of counters that you can look at (system wide as well as process specific). So you can start by profiling the big 4 (that's memory, disk usage, cpu and networking). There are a lot of posts out there about what counters are best, so I won't go into too much detail about the perf counters here.

windbg If you indeed see that memory is growing and not being collected it's time to bring in the big guns. .NET is great at abstracting memory usage away from developers, but this means we have to get underneath .NET sometimes to find out what is not allowing the Garbage Collector to do its work.windbg with the sos.dll (managed extensions) is a great tool for this. The hardest part of windbg (in my experience) is just getting the sos extensions loaded properly. You have to pay close attention to what target architecture (64 or 32) you are analysing and what CLR version you are running on.

procdump procdump by sysinternals is a great little utility to take memory snapshots from a running process. These snapshots (.dmp files) can then be analysed by windbg.

sos The sos.dll has shipped with the .NET Framework since v2. With v4, Visual Studio 2010 has integrated sos and allows you to analyse .dmp files!

The sos commands for memory leaks that I have found most useful are:

!eeheap -gc (overview of what is in each generation of each heap)

!dumpheap -min <size> (dumps out all objects and types, over a particular <size>)

!dumpheap -type <type> (dump out all objects of a specific <type>)

!gcroot <address> (prints out a stack so you can see what parent object is pinning in the GC)

!do <address> (prints out memory of a specific object)

Some other pointers:

Usually, you want to snapshot memory under load, so it would be good to have some way to simulate that from outside the system. So, it is good to get this running ahead of time and even work it into the QA process for the application.

For performance problems it is usually best to take regular snapshots over time with a running application. Then you can compare the snapshots when you analyse.

Well, that was a bit longer than I intended, but hopefully worth it!