Home » 2014 » November

Value Type vs Reference Type

It is amazing to me how few programmers understand the fundamentals of how variables work.  Not just in .NET or C# specifically, but in every language they work in.  It amazes me for two reasons.  First, I don’t think I could program if I didn’t understand what was physically happening as a result of the code I was writing.  Not knowing how the variables relate to the memory that they use would be, to me, a major limitation.  But it also amazes me because I don’t think anyone can program intelligently until they do know what is happening.

So, I’ll start from the outside and move in to what’s happening in memory.

What is A Value Type

The first question we need to qualify is, “What types in .NET are referred to as Value types?  Common value types are int, double, float, decimal, and bool.  What we ypically refer to as “primitives”.  But, there are other types that are also value types.  Enums, structs, and DateTime(because it is a struct) are also value types. Continue reading “Value Type vs Reference Type”

Raking Leaves and Writing Code

So, today I had the task of removing the leaves from my yard, which gave me a lot of time to think because it is a pretty solitary job, even if you have people helping you, because much of the time I was using a leaf blower.  It is pretty hard to hold any kind of conversation when you are using a leaf blower.

And  as I was running the leaf blower, I was thinking about what I was going to talk about today.  And then it struck me, why not just talk about cleaning up the leaves?  I mean if John Sonmez and Scott Hanselman can talk about stuff that isn’t necessarily programming related, why can’t I?

But then I realized, I could talk about cleaning up the leaves in my yard AND talk about programming at the same time.

Think about it.

Why Rake Leaves?

Why did I clean up the leaves in my yard?  It wasn’t to make my yard look better.  No one can see my yard from the road.  No one would care but my family, and they do care.  But even if they didn’t, we ultimately clean the leaves off our yards because doing that means our grass will grow better next summer by allowing it to see the sun now.  We do it because nasty critters live in leaves.  We remove the leaves from our drive ways and sidewalks so that snow removal will be easier in the winter.  In short, as hard as the work is to take care of our leaves in the fall, the work is worth it because it makes the rest of the fall and winter easier for us  in the long run.

What’s interesting about the first reason, allowing the grass to get more sun during the fall months, would mean that it would actually be better to clean up the leaves frequently during the fall rather than waiting for them to all fall and then rake them.  By the time I get to them, it is probably too late to do any real good because I wait for them to all fall before I remove them.  By that time, the sun shines less during the day and the frost has already kicked in.

How Is This Related to Code?

And that brings me to our code.  We all have code that needs “raking”.  You know you have code that is duplicated all over the place, but have you taken any time to collect all of that code into one place as a function?

How many code smells do you have.  Are your functions long?  Do you have conditional blocks nested more than one deep?  Do you have classes that do more than one thing?  Have you written code that isn’t being used because “we might need it some day”?

As I work with inexperienced programmers, the one thing I notice is that looking for places to simplify code is a skill that needs to be practiced.  It doesn’t come naturally.  Very few programmers assume that as long as the code does what it should, they are done.

And yet, leaving these code smells in place means that the next time you go in to work on the system, you will not be able to understand the code as well as you should.  Because you haven’t let the sun shine on your code, when you get to it to maintain it, you’ll be working in mud instead of nice green grass.

The Challenge

So today, your job is to find one place in your code that could be made better.  Make it less complicated.  Make it fewer lines of code (without making it hard to read).  Find two places that are doing essentially the same thing and turn that code into a function.  Find two classes that are tightly coupled (highly dependent on each other) and remove the dependencies.  Do this once a day for the next thirty days and see if you don’t find your code easier to work with than it  is today.

C# Properties Get and Set

My son is learning to program.  Last week he asked me to explain C# properties get and set and, as it turns out, it looks like many others are asking for the same.  So, I’ve decided to spend the time on this post, explaining getters and setters in about as much detail as one can expect.

So here it goes…

Continue reading “C# Properties Get and Set”

ASP.NET Server Performance Testing

loading…

This happened a couple of years ago, but it is still relevant because I know of at least one place where it is still happening even though Microsoft has fixed the issue that initially caused this hack to be put in place in the first place.

Problem In Production – Oh NO!

Here’s the problem we were seeing.  We had several large PDF files that the client wanted to put up on the site so that their customers could download them.  The problem that we were seeing is that even though the site worked fine under development and QA, the site seemed to consume a lot of memory under load.

Another symptoms we saw was that the file download took a lot of time to start, or timed out completely.  But the main issue was the memory because when the memory was consumed, the site would restart, and because it was a worker process crash that caused it, the restart took the site down.  This is not something you want to see happen when you are working with a client with world wide exposure.  A client who, if I told you the name, I’m sure you would recognize.

In fact, it was the site not responding, or crashing, that first alerted us to the problem.  So, as soon as we knew the site wasn’t responding, I’d log onto the server and fire up task manager to see what was going on.

Server Management Tip

One of the things I did early on managing the servers, is that I set up an entirely separate app pool for each of the web sites we are hosting.  This way, we can monitor the memory and CPU activity of each one independently.  For those of you who are interested, the way to make the pool name show up in task manager is to run the pool in ApplicationPoolIdentity, a setting you can get to through “Advanced Settings…”  If you are only hosting one site, you shouldn’t need to do this, but in my case, with multiple sites, this told me a lot about what was going on with the sites and ultimately helped me track down what the problem was.

By the way, you should always run each of your sites under a separate application pool so that when one site is having trouble, every site on your server doesn’t have trouble.  Imagine having an issue and not even knowing for sure which site was causing the trouble.  It’s bad enough not knowing what page is causing the problem.

It Is a Memory Issue.  Now What?

OK.  So, I could see the memory increasing as soon as the site came back up.  So, now to try to track down what was causing memory issues.

I tried various things along the way, none of them shed any light at all on the problem.  I even got dotMemory from JetBrains to see if I could find anything.  A memory leak maybe?  No, none of my code had even a small leak.

The Fix Discovered

And then I finally stumbled on the issue.  I can’t remember what it was that we installed that needed this, but what it did was change our web.config file so that it had a section in it that looks like this:

<configuration>
... lots of other configuration stuff ...
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true">

What that causes IIS to do is to run ALL of your web request through ALL of your .NET modules.  Why is this a problem you ask?  Because it even runs all of your images, css, javascript and other static content.  This isn’t normally a huge problem because most of that stuff is relatively small. But, when you try to run a be PDF through that pipeline, you’ll run out of memory because, and this is the major issue here, because the whole file has to be loaded into memory on the server before it can be sent on to the web browser to download.

Make sure that runAllManagedModulesForAllRequest is either set to false, or doesn’t exist in your web.config file.  If you need it to be turned on for some valid reason that I am not thinking of, at least put your static files on another site where this can be turned off.

Moral Of The Story

Now, the question that we should be asking now that we’ve figured it all out is, why wasn’t this caught earlier?  When a site goes up, isn’t all of the functionality, including all of the links to all of the images, files to download, and other pages on the site and off the site supposed to be tested?

Yes, of course they are, but if you haven’t at least written down where all of this is, if you don’t have a systematic way of testing EVERYTHING, you WILL end up with these kind of errors once you put the site live.  This is to say nothing of load testing along the way.  This can all be prevented.