A few years ago, I remember discussing how Web 2.0 would change the performance profile of a typical application server handling requests from browsers. It was pretty simple to see that Web 2.0 would increase the number of "service" (JAX-RS doing http/xml or http/json) requests. Other less obvious changes to the performance profile of an application server that result are documented below.
Static content goes away completely saving app server cycles.
It should already be a well known practice that html pages and images and stylesheets which people consider static shouldn't be served by an application server and instead moved to a http server or content distribution network (CDN). A full blown application server just isn't the fastest server for serving basic http requests for files that don't change.If you look at a typical Servlet/JSP (Web 1.0 server side MVC) approach, you'll see JSP pages stored on the server with substantial static content that has scriptlets or tag libs that mix in some dynamic content. If you look at a typical web page (let's say twitter for example), my guess is the static content on any dynamic pages (the html markup to organize the table containing the tweets) is like 70% of the page content, with 30% being actual dynamic data. We have spent alot of time making our app server perform well sending out this mixed static and dynamic data from our JSP engine. The output of such data includes handling dynamic includes, character set conversions, processing of tag libraries, etc. This action of outputting the JSP content is the aggregation of basically static content and true dynamic content from back end systems like databases.
Once you move to Web 2.0 and Mobile, you can treat that static content as truly static moving the static content to a web server or CDN. Now the browser can do the page aggregation leveraging AJAX calls to get only the dynamic content from the application server via JAX-RS services, static content in the form of HTML and JavaScript served from web servers or CDN's, and JavaScript libraries to combine the two sets of content. Now all that work that used to be done in the JSP engine is removed from the application server freeing up cycles for true dynamic service computing.
Sessions/Authentication change in Web Scale applications offering easier scale out.
As customers are starting to implement Mobile solutions, they are finding that the load the mobile solutions drive ends up being "Web Scale" or scalable beyond the traffic generated by browser traffic alone due to the always accessible apps offered to their customers.In SPECjEnterprise or any full blow JEE application that uses HttpSession, sessions are typically sticky with a load balancer out front redirecting the second and following web request from any client back to the server which last serviced the request based on a http session cookie that identifies the preferred server for following requests. Additionally, this session data is typically replicated across a cluster in the case the primary server for any user fails, so the user can be redirected to a server that has a copy of the stateful session data. These architectures simply assume if the session isn't loadable locally or replicated that the user must not be logged in yet.
If one wants to write an application that scales to web scale, this approach isn't sufficient. You will find most services of such web scale (Amazon S3, Twitter, etc.) force the user to login before accessing any AJAX services. In doing so they then associate a cookie based token for that browser that acts as an authorization token that each service can double check before allowing access. They can check this token against a central authority no matter which application server the user comes through. This allows the infrastructure to stay stateless and scale in ways that the clustered HttpSession/sticky load balancer doesn't allow.
This approach changes the performance profile of each request as it means each service call needs to first authenticate the token before performing the actual service work. I'm still experimenting with ways of optimizing this (using application centric data grids such as eXtreme Scale can help), but it seems like this trade-off to peak request latency for the benefit of easier horizontal scale out is to be expected in Web Scale architectures.
I think both of these changes are quite interesting when considering the performance of Web 2.0 / Mobile and Web Scale applications and aren't obvious until you start implementing such an architecture. I think both show simplifying approaches to web development that both embrace web concepts and help performance and scale of your applications.
Have you seen any other changes to your application infrastructure as you have moved to Web 2.0 and Mobile? If so, feel free to leave a comment.
