Patent Application
20060235991
1. Technical Field
The present invention relates generally to websites and more specifically to managing a website. Even more specifically, the present invention relates to throttling all but a given number of requests directed to a website at the time the website is started up.
2. Description of Related Art
The Internet has become a cultural fixture as a source of both information and entertainment. Many businesses are creating Internet sites as an integral part of their marketing efforts, informing consumers of the products or services offered by the business or providing other information in order to engender brand loyalty. Many federal, state, and local government agencies are also employing Internet sites for informational purposes, particularly agencies that must interact with virtually all segments of society such as the Internal Revenue Service and secretaries of state. Providing informational guides and/or searchable databases of online public records may reduce operating costs. Further, the Internet is becoming increasingly popular as a medium for commercial transactions.
An inherent problem with many websites is that they fail under heavy use, often because of memory allocation problems in the Java Virtual Machine (JVM) on which the application executes. There are several common solutions to this problem, including caching commonly used objects to reduce CPU and memory overhead and using object pooling of expensive objects such as database connections. However, the use of these solutions causes a different problem when the JVM is coming up. Creating and placing objects into caches and pools is a highly memory-intensive and CPU-intensive operation, while taking the objects out of the caches and pools is not. When a JVM is starting up, its caches and pools are empty, so that the system is utilizing large amounts of memory and CPU time at start-up to fill the caches. If the JVM crashed because of a heavy load which does not abate, the application running on the JVM can experience a heavy request load at the same time it is experiencing heavy memory and CPU usage filling the caches, which can cause the JVM to crash again.
Thus, it is desirable to protect the JVM from high loads while the caches are being populated, and then allow the load to ramp up over time as the cache and pools are filled. This spreads out the CPU load and heap utilization from a spike into a plateau and improves system stability as a result.
Existing implementations of load management on the JVM are generally performed upstream of the servlet engine—they perform weighting and throttling at the router level before the request ever arrives at the servlet engine. However, this is complicated to put in place and requires that one adds additional layers of software and hardware to accomplish this throttling in a network. It would be desirable to provide protection to the JVM without requiring an additional layer of hardware and software.
The disclosed invention uses a simple filter that will intercept a request before it reaches its destination within the web server. The filter is placed on all incoming requests for dynamic content. The filter is preferably configured to be the first filter encountered and will evaluate a series of conditions to determine if the request is to be throttled. If the request will be throttled, the filter sends a message to the user that the server is busy but to try later. Requests that are not throttled are allowed to flow through to be processed normally.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
With reference now to the figures,
In the depicted example, server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 are connected to network 102. These clients 108, 110, and 112 may be, for example, personal computers or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112. Clients 108, 110, and 112 are clients to server 104. Network data processing system 100 may include additional servers, clients, and other devices not shown. In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN).
Referring to
Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI local bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to clients 108-112 in
Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI local buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, data processing system 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.
Those of ordinary skill in the art will appreciate that the hardware depicted in
The data processing system depicted in
With reference now to
Looking now at
The concept used in the throttling filter in these illustrative examples is that the load will initially be limited to a percentage of the requests received; the percentage will be gradually increased as the caches and pools are filled, until finally all requests are passed through. For example, for the first 5,000 requests, only 20% will be passed. For the next 10,000 requests, 50% are passed through and for the next 10,000, 80% are passed through. Finally, after the first 25,000 requests, 100% will be passed through.
Preferably, the throttling will be applied on only a subset of servlets and JSPs in the application. This is done by modifying the Servlet deployment descriptor (web.xml). By careful selection of the servlets and JSPs to be subjected to throttling, the designer can cause the rejection process to be directed to users who are just arriving at the website, rather than users that are deep into an existing process. For example, the choice can be made to selectively throttle users going to a domain name of ibm.com, but to allow requests directed to ibm.com/webserver, since the former is more likely to be a new arrival at the website.
With reference now to
The filter can then determine if the request falls within the desired percentage of requests to be served at this point in time. For example, a random number generator can be used to generate a number from 1 to 100 (step 514). The number generated is then compared to the probability range above (step 516). If the value of the random number falls within the probability range, the request would be passed on normally (step 524); otherwise the request would be throttled (step 518). An error page is sent to the user, informing them that the server is busy, but to try again later and then the filter chain is terminated without ever reaching the servlet (step 520). This completes the execution of the filter.
As disclosed, the innovative filter will throttle a percentage of requests during the initial period of start-up to reduce the load on the server. Once the server has had time to fill its caches and pools, the filter remains in place, but will pass all requests without throttling. This mechanism allows a server to be protected during the time that it is most vulnerable to heavy loads, yet does so by a simple mechanism, without additional layers of router hardware and software.
It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
