Bits and a Pint

In my new role I've been working on projects that are coded with C# and I was recently asked to look into an out of memory issue.  Being new to C# and not as attuned to the way in which it handles memory I turned to Google and Stackoverflow for some research.  I found out that C# in many ways is similar to Java in how it handles memory management, however, among the differences there is one big one - the unmanaged memory partition.  The memory isn't truly "unmanaged", it's just not directly managed by the running application and is typically stored in our virtual page space.  A scenario where this comes into play is the utilization of 3rd party COM objects within your program - it is here where our OOM issue begins to take shape.

It is well known that when it comes to requests it's best to have fewer on a page for better performance.  However, what if our attempt to do this creates very large responses?  In this situation is it still a good idea to maintain this rule or should we split a request into multiple asynchronous parallel requests that return smaller responses?  That was the question that came up the other day as I was testing a site and noticed that one of our javascript libraries was starting to creep up in size even though it was minimized and gzipped.  In order to answer this we need to keep in mind several other rules that deal with receiving the smallest response we can.  In situations like this, where performance rules can collide, which ones should we give priority to?  Should we ever break the rule of fewer requests?  To answer this, let's dive into the rules...  

There is a lot of talk about what you should be looking at to determine if your page is performing optimally.  With today's front end architecture's it is generally accepted that several indicators are no longer valid - i.e. domComplete and onLoad.  We also know that reviewing the full page time is not a true indicator given that most critical functionality for page interaction may be loaded well before your page is fully loaded.  With all this in mind what are the most critical indicators that we should be looking at?

First lets clarify that in this article I'm only speaking about the page's initial load/render performance.  While I believe that each indicator has it's own place in the world of performance there are a few key indicators that we use at StubHub to track our page's performance.  We have 2 main indicators that we track against company KPI goals.  The first is time to interact (TTI) and the second is Full Page Time (FPT).  I know what your thinking, "But wait, you just said that Full Page Time is not a good indicator of performance.", while this is generally true, the FPT indicator is a good reference for keeping 3rd party and non-critical functionality in check.  Other indicators, non-company KPI goals, that we use deal with time to first byte (TTFB) and the loading of ads.

You might be asking "why don't you look at several of the other indicators, given that you've stated that each indicator is important?".  The reality is that we do utilize many of the other factors - page weight, requests count, etc...; however we utilize these as to help us set our KPI goals and to help us tune our pages.  I've found it especially useful to use these other indicators when giving the design teams a rough set of guidelines around page design and performance impact, which I might discuss in another article.

About the Memory Analyzer

What is the Memory Analyzer?

Self contained system

Benefits

Potential Issues

• Duplication - If not completely thought out you could end up with a lot of duplication of common pieces in systems.  
• Disrupts - Given the loose coupling, your mini system has to be able to handle disrupts to the flow when it does need to communicate or hand-off to another system within the overall system.
• Too many mini-systems - In such an architecture it is possible to go to the other extreme and create too many mini-systems making it a nightmare to understand and maintain.
• Dependencies - If there are core common dependencies running in many of your mini systems; what happens when you have an update to it?  You either end up with the colossal nightmare of updating all the systems or you update each as you go and pay the price of supporting multiple core common pieces in the various systems.

Conclusion

What is VisualVM

Where can I get VisualVM

Is process he real problem we think it is, or are we making a mountain out of a mole hill?.  If you work in the technology field then I'm sure you've run into the process beast at some point in your career.  It may have been that problems arose due to a lack of process, the wrong process or too much process; but at some point we've all faced it.  The real issue though isn't the problems process may create, but how we handle these problems and, more importantly, how we approach process itself.  Do we take the lazy way out and blame all our woes on the process, therefore leaving us unaccountable, or do we face it head on, acknowledge the issue and take the necessary action to fix it.  

When process fights - fight back

Just like a developer tackling a bug we shouldn't take the lazy way out.  Pointing a finger at process only prolongs the issue.  Instead we should face it head on.  To do so we need to don our problem- solving cap and determine why process has caused our issue.  In some cases it could mean a flat out removal of a specific process - especially if it's blocking and useless; for example, all changes must be approved by Joe even though Joe has no idea what he's approving.  In other cases, it could be that the process has created a time draining workflow and just requires a simple adjustment to be more effective.  There are also many times when the lack of a defined process can wreak havoc -  in these cases some process may be better than none; just remember that process should be treated like code and iterated upon as it is most likely never going to be perfect right out of the gate.  Once we know the bug in our process we should fix it immediately, testing it on our problem and other use cases to prove we've corrected it appropriately.  Using a process untested is just like pushing a bug fix into production without QA; you might think it fixes the problem, but when released into the wild it causes issues with other use cases.

Process is iterative

If we treat process as we treat code then we know it won't be perfect and instead will be in need of constant improvement.  If we accept this statement as fact then we set ourselves up to be flexible and agile, thereby reducing either the issues caused by process and/or the turn-around time to resolving a process related issue.  One might even consider process a "project," tracking issues against it just as you would a widget you were building.  If one takes this approach then we'd see the process achieve improvement as it matured vs remaining stale and having users deal with a broken process forever.  Another approach would be to review all processes periodically to determine if they are still valid and/or if there are improvements that can be made.  It doesn't matter which approach you take, so long as you remember that no process is perfect and therefore needs iteration to be effective.

In conclusion I'd say that process is rarely "The real problem", but rather our approach to it.