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

Apple Mighty Mouse is a really great product in my opinion. Especially the ability to scroll 360 with the small ball on the mouse has been the best feature for me. However after several months, the mouse started acting up so when I scrolled down, it would not do the job.

After couple search keywords, I found some useful sites about cleaning up the mouse and I decided to clean it up. However, there was price I had to pay. The thing was that the oval shaped object was glued to the mouse body. And I took it off from the body although it was glued. When I was reassembling it, I had two choices for the oval thing. First option was that I would have to attach it back to the mouse body using super glue or something like that. And then second option was not to bother to put it back again. I went with 2nd option.

Anyways, since cleaning the ball, the scroll works like the way it did when I got it for the first time.

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.

When iPhone came out for the first time, I was amazed at how iPhone rotated safari web browser. I wondered how iPhone would rotate it and was not aware that not all iPhone applications are rotatable, but now I know how.

Let’s assume that we already have your own extended UIViewController class. UIViewController class has these two classes for the rotate feature:

1
2
3
4
5
6
7

-(BOOL)shouldAutorotateToInterfaceOrientation:
	(UIInterfaceOrientation)interfaceOrientation {
}
-(void)willRotateToInterfaceOrientation:
	(UIInterfaceOrientation)orientation
		duration:(NSTimeInterval)duration {
}

shouldAutorotateToInterfaceOrientation method. You simply just return “YES” so that the viewcontroller rotate its views automatically. The 2nd method “willRotateToInterfaceOrientation” is the one you want to implement.

Let’s say you already had one UIView object with white color background. When you rotated your iPhone or iPhone simulator to landscape orientation, the UIView would be rotated. However, the view wouldn’t fit the screen. To make the view to stretch to the all 4 edges of the screen, I would write something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13

-(void)willRotateToInterfaceOrientation:
	(UIInterfaceOrientation)orientation
		duration:(NSTimeInterval)duration {
	CGRect appFrame;
	appFrame.origin = CGPointMake(0.0f, 0.0f);
	if ((orientation == UIInterfaceOrientationLandscapeLeft) ||
			(orientation == UIInterfaceOrientationLandscapeRight))
		appFrame.size = CGSizeMake(480.0f, 300.0f);
	else
		appFrame.size = CGSizeMake(320.0f, 460.0f);
 
	[contentView setFrame:appFrame];
}

As you can see, every time view gets rotated, you would need to use setFrame method to set the new frame with a new size and new origin.

Coding was 2nd fight. The first fight that I had to deal was to set up provisioning profile correctly so that I can test my app on my iPhone device. I do not have any hair left to pull out. (j/k) Seriously it should not be this difficult to comprehend how to set it up correctly. Follow this and this if you have an error like “ApplicationVerification Failed” when compiling your project and installing your app to iphone device. Those two links give the comprehensive guides to setting up your environment for developing and testing your app on your device.

A note: In iPhone SDK 2.2 there is no “Code Signing Provisioning Profile” column in the property anymore. Instead, it’s merged into Code Signing Identity as shown in the photo.