Akamai Diversity
Home > Matt Ringel

Recently by Matt Ringel

Pitch. Presentation. Proposal.

Getting people to say they're interested in an idea is easy.

Getting people to commit to an idea is hard.

Let's talk about the difference between a Pitch, a Presentation, and a Proposal.

You Must Try, and then You Must Ask

I like working with grownups.

Here's an example:

When I was a wee little New Hire at my current employer, one of the things that came up a lot was the "15 minute rule." That is, if you're stuck on a problem, take a solid 15 minutes to bash your brain against it in whatever manner you see fit. However, if you still don't have an answer after 15 minutes, you must ask someone. I shorten this down to "You must try, and then you must ask." It's a simply-worded rule, which works something like this:

  1. If you've hit the point of giving up, you have to push yourself for another 15 minutes. The pressure is now off. You know that in 15 minutes, you'll be able to take what you found and talk to another person about it and get their help. For right now, all you have to do is step back and look at the whole problem from the top. Maybe you'll find the solution that was sitting there all along. Maybe you'll convince yourself it's completely unsolvable. Whatever you end up doing, those next 15 minutes are where you look at the problem one more time.

  2. During those 15 minutes, you must document everything you're doing so that you can tell someone else. So, what does "look at the problem one more time" mean? It means taking notes. Lots of them. I'm a big fan of using a paper notebook with an excruciatingly fine-point pen, because I don't need to move windows out of the way to keep writing in it, and I can fit a lot of words on a single page. Use what you like, but keep writing. Write down all the steps, all the assumptions, everything you tried, and anythingyou can do to reproduce the problem. More likely than not, you've now probably figured out at least one other way to solve the problem, just by getting it out of your head and onto paper.

  3. After that, you must ask someone for help. Okay, you've decided you need help, and you've spent another 15 minutes looking at the problem again (and again (and again)),and you've documented your approach.

    Now, stop.
    Stop trying to solve the problem, if only for a moment.

    Call for help. Even if you think that you almost have it, stop. Even if you think that an incarnation of the wisdom of the masters is perched on your shoulder whispering the answer in your ear, stop. Write that email or walk over to the office/cube/etc. or cast the appropriate summoning spell, but make sure that someone else knows that you need help. Request assistance, state the problem, and show your work. You may not get help right away, but now you've employed at least one other brain in helping you, and now they have a great head-start, courtesy of you.

So, that's the 15 Minute Rule in 3 easy steps.

Here's why it's important:

  1. Your paid hours are costing someone money. You can be in a Professional Services Organization, an internal IT organization, or an independent contractor, but it all works out to the same thing; someone is paying for your skills. While it may feel good to figure out the answer on your own, there's no medal for wasting 3 hours worth of money on a problem that doesn't merit that kind of time. In a sneaky way, this also helps you value your own time, if only by making you ask yourself "Is this problem worth this much of my time?"

  2. Your colleagues will help you because they're playing by the same rules. This means they're used to asking and listening to informed questions, and they'll be expecting the same from their peers. Needless to say, use your common sense... find someone that isn't heads-down in a problem of their own; no one likes to have their flow interrupted. That being said, your colleagues will know that if you come over to ask for help, you'll already have taken time to look it over and documented your findings so they can help you figure out the problem faster or point you in the right direction. It's possible you'll end up Rubber Duck Debugging the problem, and the act of talking through the problem will help you solve it.

  3. Last but certainly not least, You have to interact with your colleagues because they have the answers you need. Building and maintaining an enterprise software platform (to choose something of appropriately fiendish complexity) is not a solo sport. Your colleagues have different ways of understanding problems and different ways of using the knowledge they have. This goes for many definitions of colleague and many definitions of knowledge.

This eventually turns into a virtuous cycle. People value each others' time and their own, so they do their own homework before asking a question. In turn, people are more likely to answer questions because they know the person asking will give them the interesting part of the problem to solve.

Put another way: by explicitly taking enough time, everyone saves time.

Matt Ringel is Enterprise Architect in Akamai's Professional Services team

Why should I care about Rendering Engines?

The following is a guest post from Enterprise Architect Matt Ringel, Senior Enterprise Architect Joseph Morrissey and Enterprise Architect Manuel Alvarez.


This is a follow up post to the Boston Web Performance Meetup presentation by the Professional Services team - The Render Chain and You.


There are many factors that affect your site performance and one of the less discussed ones is the Rendering Engine.  There are a lot of smart people developing browsers, why should you care about how your page renders?  The reason is simple: the rendering engine is using rules to paint your site and if you do not follow them, it will penalize you by slowing you down.


The Rendering Engine is a component of the browser in charge of displaying the requested content.  The most common rendering engines, Gecko (Mozilla), WebKit (Safari), old versions of Chrome, and newer versions of Opera) and Trident (IE), follow a similar flow:


PS Blog.png

Figure 1 Rendering engine flow


At a high level, as soon as the HTML has been retrieved it is sent in chunks to the Rendering Engine.  The Rendering Engine will parse the HTML and create the DOM, every element of the HTML will have a corresponding entry in the DOM.  Styling information from the CSS along with the visual attributes defined for the elements in the HTML are combined to create the render tree.  The render tree is then parsed and the exact coordinates/location of each element in the window is calculated.  The render tree is traversed and each element is then painted onto the screen. 


The process is not as straightforward as it seems.  The Rendering Engine follows defined rules to support the dynamic and evolving nature of websites; for example, an script adding stylesheets causes the page to re-flow as coordinates might need to be adjusted.  Another example is that if a <SCRIPT> tag is encountered, parsing of the HTML may pause while the script executed.  If the script is external, then parsing pauses until the script is pulled from the network. 


Matt Ringel and Joseph Morrissey discussed these rules at the Boston Web Performance Meetup in August and they have summarized them here for you: 


The One Rule of Rendering

Anything that introduces uncertainty into how the page should be rendered will block rendering until it's resolved.


If the Rendering Engine does not know how the page will be rendered (CSS), it is waiting for an asset (long load time), or suspect that the render tree might change (Javascript) then it will not render the page.

 

Rule #1: Scripts Block Parsing 

  • Posit: JavaScript is a single-threaded environment¹, and JS files have the potential to change the DOM.
  • Consequence: The render chain blocks because there's uncertainty in how the page is rendered.
  • Result: If you have a large amount of JS to parse, the browser will sit there parsing it all without putting a pixel to the screen.
  • Conclusion: Don't do that.  Use async/defer where you can.


Rule #2: Style Sheets Block Rendering

  • Posit: Anything that can force a re-flow of content (font changes, different margins for certain elements, etc.) will introduce uncertainty.
  • Consequence: Browsers will block rendering a Web page until all external style sheets have been downloaded².  (cf. The One Rule).
  • Result: If you have style sheets interspersed with content or inline in your document, rendering will stop until they're integrated with the DOM.
  • Conclusion:  Pare down the amount of CSS you have to what you're using, and put it all in the <head> of the document.


Rule #3: Less Caching, More Problems.

  • Posit: The fastest load time is when the browser already has the data.
  • Consequence: Origin hits cost time and is distance-based.
  • Result: Non-cacheable content creates high variability in page load time.
  • Conclusion: Cache browser-side if possible and consider using a CDN.

During the Boston Web Performance Meetup event, our speakers took a look at the top five rendering issues affecting e-Commerce sites by using these rules.  You can watch their findings  or download the presentation here.


¹ HTML5 JavaScript Workers change this a bit

² CSS "print" styles or non-matching media selectors will not block because they're not immediately applicable


Is Your Infrastructure Thinking Too Hard? (Part 1)

Akamai's Enterprise Architects regularly perform site assessments for customers to help maximize performance in terms of speed, scalability and reliability for their Akamai setup and their origin infrastructure. 

The first step in this process is what we call discovery, where we dig deep into the customer's web architecture and website. This allows us to understand the whole story of how the website functions, along with business goals and design decisions.

Out of all of the questions and answers during discovery, there's one particular question that consistently generates a large amount of conversation and high-value ideas. In fact, this question can be the launching point for a number of critical operational exercises like designing a new application, migrating to a new platform, troubleshooting or simply auditing: "How much of your infrastructure do you use when you serve a request?"

That is, how many of your databases, application servers, internal caches, load balancers and front-end servers have to spend time thinking about how to output the requested web page?

The answer varies depending on the request, but the important metric is "origin think time" or how long the origin (your servers) must think about a request once the request is made. If the page is cacheable and can be served directly by (say) Akamai at the edge of the network, the think time will be slim to nil. If it's not cacheable, like dynamic or uniquely-personalized content, your servers will spend a measurable amount of time processing the request.   

I recommend sitting down with a diagram of your web infrastructure and a spreadsheet, and asking the following questions:

•    What are the typical types of requests for non-cacheable data browsers make to my website? In a lot of cases, there might be only 5-6 general types of web pages on a typical site.
•    For each of those types, which and how many of my servers/processes need to process that request? e.g. 1 database server, 1 app server, 1 auth process (on app server).
•    How much wall-clock time does it take for my servers to process the request? Typically measured in seconds, and get numbers for both cold and warm browser caches, averaging multiple requests.
•    If you have the metrics, include a column for how many times a user might access that type of page during a typical session.

Here's an example of what a typical e-commerce site's think-time chart might look like:

Ringel Blog Image.png

This chart will be a good first step in identifying hot-spots in your infrastructure, and give you the insight you need to start doing triage on think-time issues.

In Part 2 of this article, I'll talk about some approaches you can use in your own web infrastructure to reduce origin think time.  

Matt Ringel is Enterprise Architect in Akamai's Professional Services team