Thursday, June 25, 2009

 

Chunked transfer and Response.Flush

I've been attending O'Reilly's Velocity Conference over the past days and I must say that I've learned quite a few things about web performance that I didn't know. One subject that came up in several talks was using "Transfer-Encoding: Chunked" to allow for sending to topmost part of the page to the client while most of the work for the page hasn't even started. Example:

If you look at this result page from Google, you'll note that the upper section of the page, with links to other Google properties, the logged-in indicator, the logo and the search box can be generated without doing the actual search. Most of the time on the server is spent looking for results matching the query, but you could create this first bit of HTML before even starting on the query. This is exactly what Google does. When your request comes in, the first send this header and only after that they start on the search query. This makes the time before the user sees any change a lot shorter and will be perceived as better performance. What's more, as the browser gets the references to external images and scripts sooner, it can start loading them earlier, resulting in a real (not just perceived) better performance.

So how could we achieve this in ASP.NET? Problem is of course that we normally do any heavy lifting required in a page during the PreRender or EventRaising phases. The actual rendering of the page, including the very first segment, happens later: during the Render phase. It depends very much on the structure of your page, but in certain situations, you could maybe do something like this: Now if you wrap the start of the page inside this control, you will render that part of your page way before the Render phase. The flushing makessure that the automatic buffering is bypassed. ASP.NET will then automatically set Transfer-Encoding: chunked.

Drawbacks:

  • You must make sure that no control or literal text comes before the Flusher or the order will get mixed up
  • Not sure how this will work with master pages
  • You cannot flush part of the HtmlForm control (this contains the hidden ViewState). Keep everything you may want to flush outside the form
  • Anyone with deeper thoughts around?

    Labels:


    Wednesday, April 22, 2009

     

    Securing my online presence

    It will become even more important than today to be able to influence what people find when they google your name. Eventually, they will find out everything you publicly wrote or said and many things you did in public places. Search engines will not only turn up the stupid questions you posted on forums 20 years ago, but also recognize you in pictures of frat parties 30 years ago.

    But then again, it's only the top 10 finds that really matter. Most people never click through to page 2, let alone page 30. So what do you want to have on top? Google just announced that using your Google Profile, you will be allowed some influence in what appears on top for your name search. Also, you can place your blog as a validated link on the profile page. As this link has no rel=nofollow attribute, I would think that it will boost the page rank.

    I also kind of like the way they make your Google Reader shared items appear.


    Friday, April 10, 2009

     

    Funda live: now as a mapplet

    A colleague pointed out that my iGoogle gadget for looking at the live search behavior on funda.nl, while cool, would be better implemented as a mapplet. I guess that this it true for most gadgets that have a map as their main UI. So this morning, while sick in bed, I looked over the docs for mapplets. Turns out to be really easy to convert a gadget to a mapplet: they basically are gadgets with a shared map to interact with. So with half an hour of playing around, I have a working mapplet version. It seems to be OK, but the title bar keeps blinking and the performance of the map seems less than in the gadget version. If anyone has any tips to improve this, please comment.

    Wednesday, March 11, 2009

     

    See searching patterns on funda.nl live

    I just finished a hobby project where I try to visualize the live searching patterns of users on our site (www.funda.nl, the premier Dutch real estate site). What I basically do is track the geographical region containing the current search results. I then plot these areas in a Google Map on iGoogle with some light animation. You can click the areas to see the actual URL used to find results in this area.

    What I really like about this gadget is that it allows me to see how people search our site in a more understandable way (to me, that is) than the statistical facts of page views and click paths.

    The data is near-live and is refreshed every 20 seconds. We display only a subset of the real searches, though; about 15%.

    Click here to try this gadget on your iGoogle homepage.


    Wednesday, December 03, 2008

     

    Microsoft's Velocity compared to memcached

    As a long time .NET platform fan, I've always found it a pity that for lightweight distributed caching, I had to rely on a command line Linux-like tool (memcached). The win32 version works really well and I am a happy user, but an installer would have been nice and maybe a control panel applet. The kind of sugar coating we like so much. Oh, and extensibility with .NET plugins would have been really cool.

    So I was really excited when I heard that MS was working on a distributed caching service of their own. So how does it compare to memcached? I must say that I haven't personally checked out the software and I'm basing my opinions on the PDC presentations on the product. But still, I'm disappointed.

    My main disappointment concerns complexity: one of the nicest things of memcached is that it is so well focused on serving key/value data fast. The FAQ is a classic: detailing mostly what functionality is not available. Velocity on the other hand is the classic Microsoft enterprise product: it can be configured in a gazillion ways. Velocity can do both replication and distribution of caches and works with centralized location tables and replication managers. Diagrams galore.

    I do believe that the Microsoft engineers are very smart people, so I trust them to have thought well about the problem at hand. We at funda.nl are the typical memcached users. We need to scale to many users and the data we want to cache is typically to much to fit in memory on one box. Memcached fits us very well. I'm sure that many scenario's exist where you would want some of the bells and whistles Velocity offers (or will offer in the future), but the complexity of the product alone would be a reason for us never to consider it.

    This page is powered by Blogger. Isn't yours?