|By Sam Pullara||
|February 20, 2002 12:00 AM EST||
Application server performance. Database performance. Hardware performance. These are numbers measured in the popular press, although in most situations they have little to do with your application's real-world performance. The number one way to increase performance, the thing that gives you the biggest boost, is caching. Caching in every tier is becoming more and more prevalent. On the front end, we have caching proxy servers like Squid and AOL. On the back end, we have databases and file systems that are caching our data. This month, I'm going to talk about caching in the Web application layer of the middle tier, where your application meets the Internet.
In WebLogic Server 5.1, the JSP cache tag was introduced for caching in the Web application tier. This tag allows you to cache both input (values of variables) and output (typically, the generated HTML). Ideally, these tags can be used so you have what I call "exact caching." In other words, even though caching was introduced, no change in the functionality of the application was made because the data in the cache is always the same as the real data. This is similar to how caches are used on CPUs, databases, and file systems. Just because something is cached, it doesn't mean that it's out of date. This isn't the only way to architect your caching layer. It's also possible to analyze the system and find places where you'd rather have an out-of-date answer right now, rather than an up-to-date answer after blocking the user for a time.
Here's an example of "exact caching." On my Web site I built a DVD check-out service for the people who live in my loft building. At the time, I was experimenting with XML and wanted to use it to store all the information about the registered users and the DVDs. Since I was just using the file system, parsing the XML all the time was time consuming. However, since I knew when the application was updating the XML files, I could use the cache tag to store the results of the parse and only flush the cache when they changed. This led to an order-of-magnitude increase in speed, with no loss of functionality. Voila, "exact caching."
Similarly, in the first application of the cache tag in production, a customer used the tag to cache the content from their content management system. Since they could cache based on variables in the page, they were able to only query the update time of the document in question on each request, instead of pulling the whole document over to the file system each time. This also garnered them an order-of-magnitude improvement in performance for the affected operations.
Much more difficult to architect properly is timeout-based caching. This is the normal caching that your browser and proxy servers do. When you get a Web page back from a Web site, a time stamp is returned that tells you when the page might be out of date; it's stored in the "Expires" header. If you request the page before that time, your browser will first go to its local cache for the contents (unless you force it to return to the Web site). Obviously, this method assumes that all content on the page expires at the same time and that your primary concern is reducing the bandwidth load on the server. For many application server deployments, the primary concern isn't bandwidth, but reducing the load on the servers themselves. That's where caching in the middle-tier has its sweet spot. Timeout-based caches assume that the application developer has special knowledge about the time sensitivity of the data that is being used to generate the Web page. For instance, you might be offering 20-minute delayed stock quotes and you might decide that the most popular stocks should be cached so that when users request a quote they are given the same one as everyone else who asks within some specified period of time. Determining that period is the important part of the exercise. Let's say you decide that you're only going to update the cache every 5 seconds; the quotes are already 20 minutes old anyway. If you're getting 10 requests per second for a particular ticker, that means you get 50 requests in 5 seconds, so you're doing 50 times less work to get each quote minus the cache overhead! Quite a savings for very little loss in functionality.
As you can see, caching can tremendously improve the performance of your Web applications. Using cache tags and cache filters (new in 7.0), you can build very robust, performant, scalable applications with only a bit more careful investment in design and architecture. We have only touched the surface of what you can do with caches in the Web application layer in this article; you can find out much more about caching using these tools on my Web site at www.sampullara.com/caching.
|wesnur 03/24/10 05:28:00 AM EDT|
I agreed that caching is the best way to increase the performance of the app as it reduces expensive data trips to the data base by reducing the performance bottle neck. It’s the arena of distributed caching now as concept of local caching has become a bit old. You can’t achieve desired results if you have local cache especially if your data is distributed over many servers. There many distributed caching solution are available now days but NCache and MS Velocity being the most famous ones.
Sep. 1, 2015 03:00 PM EDT Reads: 443
Sep. 1, 2015 02:45 PM EDT Reads: 140
Sep. 1, 2015 01:00 PM EDT
Sep. 1, 2015 12:45 PM EDT Reads: 482
Sep. 1, 2015 12:30 PM EDT Reads: 914
Sep. 1, 2015 12:15 PM EDT Reads: 253
Sep. 1, 2015 11:45 AM EDT Reads: 679
Sep. 1, 2015 11:45 AM EDT Reads: 327
Sep. 1, 2015 11:15 AM EDT Reads: 299
Sep. 1, 2015 09:45 AM EDT Reads: 246
Sep. 1, 2015 09:00 AM EDT
Sep. 1, 2015 08:00 AM EDT
Sep. 1, 2015 08:00 AM EDT Reads: 172
Sep. 1, 2015 08:00 AM EDT Reads: 184
Sep. 1, 2015 03:00 AM EDT Reads: 470
Aug. 31, 2015 09:00 PM EDT Reads: 385
Aug. 31, 2015 02:30 PM EDT Reads: 432
Aug. 26, 2015 07:00 AM EDT Reads: 208
Aug. 2, 2015 11:15 AM EDT Reads: 563
Aug. 1, 2015 10:00 AM EDT Reads: 496