web 2.0, frontend, ajax, flash, css, dhtml, php

This is old blog post by Peter Van Dijck, which he posted presentation materials regarding site performance and scalability, but it is still very good resource.

Check it out.

i searched about html5 mobile support and found this great post.

Things that I thought about were while reading the post:

1. HTML5 features for the mobile site may accelerate adaption of better mobile browser to mobile devices. For those who do not have the latest phone, sorry, but you might have more choices soon?
2. it’s not directly related to this html5 mobile support post, but voice lines may be dead soon. Instead, it will be all about data plan as voice call can be made through app. Which may trigger mobile device companies such as motorola or samsung to adapt full browsing experience for all their devices *faster*. More html5 enabled borwser penetration rate follows? who knows.
3. mobile web application doesn’t necessarily have to be complex application. Even with a simple site, using html5 new APIs, site can fully utilize all the awesome features (geolocation, etc)
4. HTML5 applications are mainly for iPhone, Android, and Palm Web OS devices. Nothing else.

I often use String.replace in JavaScript whenever I have to use JavaScript. Today was the day that I ended up with using it for my work. I know that String.replace supports regular expression to match your string, but I was not clear if I could use “capturing groups” and “quantifiers”. As I guessed, I was able to use quantifiers in the replace string like the sample below:

    var link_template = '<ol>\
        <li><label>Link 1 Title:</label><input class="text" id="relLink1title" name="relLink{1}title" value="" /></li>\
        <li><label>Link 1 URL:</label><input class="text" id="relLink1url" name="relLink{1}url" value="" /></li>\
        <li><label>Link 1 Img URL:</label><input class="text" id="rellink1imgurl" name="rellink{1}imgurl" value="" /></li>\
        <li class="btn"><span><a href="#" class="new-related-link">Add a New Link</a> | <a href="#" class="remove-related-link">Remove</a></span></li>\
        </ol>';
 
    link_template = link_template.replace(/(<label>.*?)(\d)(.*?<\/label>)/im, '$1 2 $2');

This is to bookmark to an article on how to debug JS in Internet Explorer.

Check out how

As the number of users grow, is it necessary to increase the number of servers? Well. The answer to the question really depends. Some might say to buy more hardware to support increasing visits. Some might say before buying more hardware, tune up your software by optimizing the code and squeeze any power out of the box. But in this post, I’m not going to discuss software tune ups.

I’m going to talk about cache technologies.

cache layer
I’d like to start with the concept of proxy layer. What proxy layer provides is a memory storage between frontend(FE) layer and API layer. So that the actual requests made from users do not overload API server; thus, the site performs much better. Proxy server would store returned XML data from API and when the same API request was made from FE, proxy would return the same data stored in the memory to FE removing extra calls to API. Frontend layer is a typical HTTP server while API layer is a data layer. Usually this technique is used in multi tier architecture. This is usual 3 tier architecture.

DB -> API -> FE

When we introduce proxy layer to it, 3 tier architecture becomes this:

DB -> API -> Proxy -> FE

As you can see, the major advantages of Proxy layer are:

1. It is very fast since it accesses memory instead of hard disc
2. It reduces overhead to one layer dramatically
3. It delivers content really quickly
4. It improves response time(better roundtrip numbers)
5. It provides better usability to users as content is delivered a lot faster
6. It can hold old data for specified time in case database blows

It just has all good things.

Commonly used cache technology for the cache layer is squid cache. If your organization’s web site is getting popular and needs performance tune up, it may be a good idea to invest some time and money to implement cache layer.

As I covered cache layer, let’s move to view level cache.

View Level Cache
View Level Cache is a cache technique to store your HTML markup output into memory or harddisc. This could be a whole markup for the page, markup for a partial page, or markup for several parts of the page. As the term implies the view level cache occurs on the frontend layer. Also there is another term, Module Level Cache referring to View Level Cache. For example, in my blog there are several sections in the page. Those are links, archives, and so on. Each section is a module and the final markup of those modules can be cached for 5 mins to how many minutes you like.

What’s so good about View Level Cache(Module Level Cache)
As I explained in the previous paragraph, it stores the final markup of a module. Which means you can reduce cpu load, which would have used to generate that module for the time you specified. That means also it does not have to make several requests to database like MySQL. So when your site got hit by dig users or reditt users, View Level Cache would’ve helped to ease heavy traffic much.

View Level Cache technologies
If you are using php, the common technology for the view level cache is APC. The usage of APC is relatively easy. In php, another technique you can use is a file cache. And heavy traffic’ed sites also use memcached, which is a distributed memory object caching system. I am not going to show how to use each technology in this post as each topic deserves its own post.

Do not cache all by accident
When you apply cache layer to your Frontend, be warned that caching all content is bad usually, specially if your site is dynamic. You do not want to cache user A’s name and display it when user B, C, and D visits your site. Also if one of your pages needs user specific data in a form tag with hidden input field and somewhat you caches it, the next visitor to your site will use the same data from the previous visitor, which is bad. See where I am going with this? So it will be nice if you can communicate with visual designer so that she can visually distinguish what can be cached and what not.

Results out of cache
The site that has implemented cache technique well could support 200 to 300 hits per second. That translates to 12000 to 18000 hits per second. I know this from my experience. You do not need a lot of servers to support 200 hits/sec site. All you need is one FE box if your site has 200 hits/sec.