Thursday, March 22, 2007
Web servers supporting desktop traffic
Serving traffic on the World Wide Web used to be so easy. Long gone are the days when simple web servers process HTTP conversations, returning content requests with pages containing text, images, applets and dynamic script. Now with the Web being truly programmable, there's a lot more to think about in terms of total accessibility.
It's been a busy day at Camp Happy, but I've been taking a couple of moments in between breaking stories, thinking about architectures for desktop RIAs. Particularly, I'm thinking about scalability in the vein of how much additional traffic cross-platform desktop apps, desktop widgets and browser plugins impose on traditional web site infrastructure (a browser and server engaging in a stateless client-server transaction). They're essentially yet another venue to tap your site's resources, so now your server assumes the additional responsibility of pulling data for extra-browser devices and clients.
Ironically, emerging web technologies are pulling us further and further away from the Web as we've known it.
Unless the RIAs ship with embedded databases that in some way sync with their source (possible, but not likely) or have some snazzy means of making offline access feasible. Web services built on SOA are a good place to start - using SOAP or REST to architect and maintain servers just for devices and access points not intended for traditional web browsing.
Componentized, middle tier caching across disparate platforms and devices via properly written business objects, not just replication at the individual page level, is critical to sustaining performance and minimizing lag. Done properly, this ensures synchronization across platforms, not having modified data seen on a web page be different than that viewed seconds later on a mobile phone.
Constant consumer connectivity also worries me. Most people close their browsers when done with a web session. Even the truly hardcore exit out of the program every now and then when not actively surfing. But terminating an individual application is far more common than rebooting an entire machine. A user's desktop, being ever-resident, can mean non-stop polling for new data if a desktop RIA's running on top of it. This could result in an escalating amount of service requests or method invocations - a few users could easily tax your system without even trying, just by being connected to it.
From an app provider perspective, if you're building a desktop RIA really take the time to consider and properly use HTTP headers as a means of good data access practice, as is commonly done in well-designed RSS readers. Or, use a clever timeout setting like Digg's BigSpy, which halts incessant loading of information after a certain period of time or if the system detects dormancy. Such a pausing feature is also possible with AJAX.
Data access is changing very rapidly, and developing the APIs through which to get at information is only one part of the equation. You need to properly setup your backend to not only serve up your stuff quickly and in the right format(s), but also to facilitate a growing number of clients. And those programs living on the desktop will very soon be hitting your services with increasing - and possibly alarming - frequency.
It's been a busy day at Camp Happy, but I've been taking a couple of moments in between breaking stories, thinking about architectures for desktop RIAs. Particularly, I'm thinking about scalability in the vein of how much additional traffic cross-platform desktop apps, desktop widgets and browser plugins impose on traditional web site infrastructure (a browser and server engaging in a stateless client-server transaction). They're essentially yet another venue to tap your site's resources, so now your server assumes the additional responsibility of pulling data for extra-browser devices and clients.
Ironically, emerging web technologies are pulling us further and further away from the Web as we've known it.
Unless the RIAs ship with embedded databases that in some way sync with their source (possible, but not likely) or have some snazzy means of making offline access feasible. Web services built on SOA are a good place to start - using SOAP or REST to architect and maintain servers just for devices and access points not intended for traditional web browsing.
Componentized, middle tier caching across disparate platforms and devices via properly written business objects, not just replication at the individual page level, is critical to sustaining performance and minimizing lag. Done properly, this ensures synchronization across platforms, not having modified data seen on a web page be different than that viewed seconds later on a mobile phone.
Constant consumer connectivity also worries me. Most people close their browsers when done with a web session. Even the truly hardcore exit out of the program every now and then when not actively surfing. But terminating an individual application is far more common than rebooting an entire machine. A user's desktop, being ever-resident, can mean non-stop polling for new data if a desktop RIA's running on top of it. This could result in an escalating amount of service requests or method invocations - a few users could easily tax your system without even trying, just by being connected to it.
From an app provider perspective, if you're building a desktop RIA really take the time to consider and properly use HTTP headers as a means of good data access practice, as is commonly done in well-designed RSS readers. Or, use a clever timeout setting like Digg's BigSpy, which halts incessant loading of information after a certain period of time or if the system detects dormancy. Such a pausing feature is also possible with AJAX.
Data access is changing very rapidly, and developing the APIs through which to get at information is only one part of the equation. You need to properly setup your backend to not only serve up your stuff quickly and in the right format(s), but also to facilitate a growing number of clients. And those programs living on the desktop will very soon be hitting your services with increasing - and possibly alarming - frequency.
Comments:
Links to this post:
<< Home
Jason,
In your caching article you made note of this: "Also observe that before calling Cache.Remove, a Microsoft® Visual C# lock is placed on the Cache object, which prevents possible concurrency conflicts."
This code is from your example:
public void ResetCachedNewsStory(string storyID)
{
if(ctx.Cache[storyID] != null)
{
lock(typeof(Cache))
{
ctx.Cache.Remove(storyID);
}
}
}
Why would you want to put a lock on the type object of the Cache class? Every other class in the same application domain will have access to this object and could potentially cause a deadlock. Deadlocks are among the worst to debug - it's in all of our best interests to minimize the amount of code examples contributing to their existence :)
You can get a good example of a proper way to implement a lock on your Cache from this article on caching - On the Hour Caching
Jonah
In your caching article you made note of this: "Also observe that before calling Cache.Remove, a Microsoft® Visual C# lock is placed on the Cache object, which prevents possible concurrency conflicts."
This code is from your example:
public void ResetCachedNewsStory(string storyID)
{
if(ctx.Cache[storyID] != null)
{
lock(typeof(Cache))
{
ctx.Cache.Remove(storyID);
}
}
}
Why would you want to put a lock on the type object of the Cache class? Every other class in the same application domain will have access to this object and could potentially cause a deadlock. Deadlocks are among the worst to debug - it's in all of our best interests to minimize the amount of code examples contributing to their existence :)
You can get a good example of a proper way to implement a lock on your Cache from this article on caching - On the Hour Caching
Jonah
Links to this post:
<< Home
Subscribe to Posts [Atom]
Post a Comment