BUILDING HIGH PERFORMANCE MAIN MEMORY WEB DATABASES
A Thesis
Presented to
The Faculty of Graduate Studies
Of
The University of Guelph
BY
MIN JIANG
In partial FuIfillment of requirements
For the degree of
Master of Science
April, 200 1
O Min Jiang, 200 L National Library Bibliothèque nationale 1+1 of Canada du Canada Acquisitions and Acquisitions et Bibliographie Services services bibliographiques 395 Weliington Street 395, nie Wellington Ottawa ON KIA ON4 Ottawa ON K1A ON4 Canada Canada Vour file Votre r6/eme
Our lire Narre re-fdr-
The author has granted a non- L'auteur a accordé une licence non exclusive licence allowing the exclusive permettant à la National Library of Canada to Bibliothèque nationale du Canada de reproduce, loan, distribute or sel1 reproduire, prêter, distribuer ou copies of this thesis in microfom, vendre des copies de cette thèse sous paper or electronic formats. la forme de microfiche/film, de reproduction sur papier ou sur format électronique.
The author retains ownership of the L'auteur conserve la propriété du copyright in this thesis. Neither the droit d'auteur qui protège cette thèse. thesis nor substantial extracts fiom it Ni la thèse ni des extraits substantiels may be printed or othenvise de celle-ci ne doivent être imprimés reproduced without the author's ou autrement reproduits sans son permission. autorisation. ABSTRACT
BUILDING HlGH PERFORMANCE MAIN MEMORY WEB DATABASES
Min Jiang Advisor: University of Guelph, 200 1 Professor Fanau Wang
Disk resident databases (DRDBs) dorninate today's Web sites. DRDBs have high costs in loading prograns and reading data from disk. which result in long response time. In this research, we study how main memory Web databases (MMDBs) can help reduce query processing time on the server side and consequently response time, which is a major indicator of Web server performance. We develop and experimenr three simulation models. The Servlet-MMDB model using Java servlets to simulate main memory Web databases; the Module-MMDB model using the server API to sirnulate main memory
Web databases; the CGI-DRDB rnodel using the CG1 protocols to simulate disk resident databases for comparison. We discuss the implementation details of each model. We quantitatively study and analyze the experimental results, and compare the two main memory database models with the disk resident database model respectively. Finally we give our recomrnendations for choosing the best irnplementation strategy. First of all. 1 would like to thmk my advisor Dr. Fangju Wang for his encouragement and guidance. which have been indispensable in cornpleting this work. I wouid also like to thank my cornmittee members: Dr. David K. Y. Chiu, Dr. Wlodek Dobosiewicz, Dr.
Michael Wirth for their valuable suggestions.
1 am indebted to my parents. 1 thank them for their love and support. Last but not the least, I thank my wife, Jing Ye, for her love. patience and support. CONTENTS
1 INTRODUCTION 1
1.1 Motivations of the Research ...... I
1.2 The Research Objectives ...... -4
1.3 ThesisOrganization ...... 6
2 BACKGROUND AND RELATED WORK 7
2.1 Network Computing ...... -7
2.2 World Wide Web (WWW) Architectures ...... 9
2.3 Web Pages and Backend Databases ...... 11
2.4 Techniques for Improving the Web Performance ...... -14
2.4.1 Caching static pages ...... 14
2.4.2 Caching dynarnic pages ...... -17
2.4.3 Clusters of servers and a DNA distributor ...... -18
2.4.4 Replication of Web servers ...... 18
2.4.5 Multicast delivery of Web pages ...... -19
2.4.6 Improving HTTP latency ...... 20
2.5 Main Memory DataBases (MMDB) ...... 22
2.5.1 Concurrency control ...... 23
2.5.2 Backup and recovery ...... 25
6 CONCLUSIONS 89
6.1 Achievements ...... -89
6.2 Future Work ...... 90
B ib liography 9 1
List of Figures
Figure 2.1 The Web architecture ...... IO
Figure 3.2 Requesting and serving a static Web page ...... 11
Figure 2.3 Requesting and serving a dynarnic Web page ...... 12
Figure 2.4 The MMDB architecture ...... 22
Figure 3.1 CG1 script ing ...... -32
Figure 3.2 An overview of the CGI-DRDB mode1 ...... 35
Figure 3.3 Execution of a CG1 script ...... 36
Figure 3.4 Process Structure with CG1 script Execution of a CG1 script ...... -37
Figure 3.5 N concurrent visits handled by the CG1 protocols ...... 37
Figure 3.6 Life cycle of a servlet ...... -39
Figure 3.7 Servkt flow of execution ...... 43
Figure 3.8 An overview of the Servlet-MMDB mode1 ...... 44
Figure 3.9 N concurrent visits handles by a servlet ...... 44
Figure 3.10 The Apache server life cycle ...... 47
Figure 3.1 1 An Overview of the Server API Module-MMDB mode1 ...... 49
Figure 3.12 N concurrent visits handled by a server API module ...... 49
Figure 4.1 Process overview of raw map data to query data sets ...... 54
Figure 4.2 The flow of database preloading process ...... 56
vii Figure 4.3 Execution Flow Web Applications ...... 58
Figure 5.1 Response time and query processing tirne of CGI-DRDB mode1 ...... -70
Figure 5.2 Response time and query processing t ime of Servlet-MMDB mode1 .....70
Figure 5.3 Response time and query processing time of Module-MMDB mode1 ...-70
Figure 5.4 Response time for the three models ...... 71
Figure 5.5 Query processing tirne for the t hree modeis ...... 71
Figure 5.6 Response time ratio ...... -74
Figure 5.7 Query processing t ime ratio ...... 74
Figure 5.8 Response time and query processing time of CGI-DRDB mode1 ...... 84
Figure 5.9 Response time and query processing time of Servlet-MMDB mode1 .....84
Figure 5.10 Response tirne and query processing t ime of Module-MMDB mode1 ....84
Figure 5.1 1 Response time for three rnodels ...... -85
Figure 5.12 Query processing t ime for three models ...... 85
Figure 5.13 Response time ratios ...... -88
Figure 5.14 Query processing t ime ratio ...... 88
... Vlll CHAPTER 1
INTRODUCTION
1.1 Motivations of the Research in the last few years, the World Wide Web (WWW or Web) has been growing exponentially and it has changed our lives drarnatically. in the early stage, the Web allowed users to publish and retrieve information easily via hypertext interfaces. What they published and retrieved were static Web pages, whic h are stored in the file systern of the mnning Web server machine. Nowadays, people are doing online shopping, banking and stock trading through the Web, which have become our daily activities.
Interactivity. fiequent updates and searching/querying are among the most attractive features of a modern Web site. These features are made possible only by the dynamic generation of Web pages with database support. To generate dynamic content, we need Web databases to organize, store and retrieve data; we also need the server-side scripting technology, which is a comrnonly used approach to interface Web databases, perform queries, retrieve data dynamically from databases and return results to the client.
When querying a remote Web database. the response time includes the time for transrnitting the request and receiving the result on the network, and the time required by the server to process the request. The server processing time mainly comprises the time for loading the semer's external program compiling it, and executing it; invoking a database application program (establishing a database connection) if the server's external program comrnunicates with a database: retrieving data, and manipulating the data.
Traditionally. the time required to transmit data was the dominant component in the response time. Currently, with the development of wide band network technologies, more and more high-speed networks have been used for the Intemet and intranets (for example giganets). Data transmission (especially on many LANs and intranets) takes less and less tirne. Therefore. of the total response tirne. the proportion of server processing time is becoming more significant. Reducing the time for invoking the server's external program, database application programs and the time for retrieving data from disks has become a key issue in improving Web database performance.
Most of the current Web databases are DRDBs (Disk Resident DataBases) in which database application programs and data reside on disks. When processing a query. a server's extension program needs to establish a connection to a database. This is a very expensive operation that involves loading the prograrn from disk and activating it. In addition, if the query invoIves a Iarge volume of data (for example, a query to a geographic information systems (GIS)), a system has to spend a considerable amount of time to transfer the data back and forth between disk and memory (including swapping).
The most comrnonly used methods for invoking Web database application programs involve creating a new process each time when a prograrn is called. Creaîing a process requires a large amount of time and system resources. In addition, on most systems, the number of active processes is limited.
The main memory database system (MMDB) technology may help reduce the server processing time. In a main memory database. application programs and data reside in the physical main mernory {RAMs). There rire no costs for loading the progrürns and reading the data from disk.
Main memory is more expensive than hard disks. Cost was the primary barrier of main memory databases. Recently with the advances of the VLSl technology, costs for large RAM have dramatically reduced. Now servers with very large sizes of RAM become both possible and affordable. The size of main memory databases was another major bmier to use main memory databases. Unlike the DRDBs, which can expand to any sizes, main memory databases are limited to the maximum amount of memory that is both addressable and configurable on a server or a collection of servers. A 32-bit system has a 32-bit address space and can support the modest main memory databases of about 2 gigabytes. A 64-bit main memory database is limited only by the amount of physical memory that is configurable on the system. The current 64-bit systerns can support main memory databases up to 64 gigabytes [TimesTen, 20011. Therefore, inexpensive RAMs and the availability of 32-bit and @-bit systems have made main memory databases a practical solut ion for improving Web database performance. However so für, little work has been done in developing main mernory Web databases. Disk resident databases dorninate We b sites, including commercial Web sites. 1.2 Research Objective
The objective of this research is to study the issues in developin,o high performance Web databases. Through the research. we try to answer the questions of:
1. Can the main mernory database technology significantly improve the performance
of Web databases when querying large volumes of data?
2. To what extents cm the main memory database technology improve Web
database performance?
3. What implementation technique of main memory Web databases may result in the
best performance? What is the suitability of the implementation techniques?
To answer the questions, we construct three models and experiment thern using real data on the Internet. They are:
the CGI-DRDB model that sirnulates disk resident Web databases for
comparison.
the Java Servlet-MMDB mode1 that simulates main rnemory databases using the
Java servlet techno logy.
the server Module-MMDB model that simulates main memory databases
working as an integrated modules in Web servers.
The CGI-DRDB model has the same features as the current disk resident Web databases. When answering a query, the server spawns a new process to invoke a CG1 program passing it the encoded information from the client. The CG1 program decodes the information. reads in data from the data resource on disk and process the request. The CG[-DRDB model is used for cornparison in evaluating the performance of main
memory databases.
A Java servlet is a pluggable extension to a Web server that enhances the server's
functionaIity. After king loaded, a semlet and related data can stay in the Web server's
process space and respond requests. Invoking a servlet does not require creating a new
process. Java servlets have become an important technique in semer-side development.
Recently, servlets have received increasing attention from Internet programmers. There is a trend that servlets may replace CG1 in many application fields because of its strengths, such as portabiiity. efficiency, etc.
Most Web server programs provide application programming interfaces (APIS) to write integrated modules to extend server's hnctionality, for example, to construct dynamic Web pages. A module can be linked directly to a server's executables. When the server starts, programs and data in the module are al1 loaded into the rnemory. So when a request for data arrives, it can be served without program loading and disk reads.
We experiment both servlets and server API modules to simulate how a Web server processes client requests when a Web database and application programs are in memory, and compare the performance of the two main memory Web databases with that of a disk resident Web database simulated by the CG1 model. 1.3 Thesis Organization
The remainder of the thesis is organized as fo llows:
Chapter 2 begins by introducing the basic concepts of network computing and the
Web architectures. And then we review the related work. The review is divided into two parts. In the frrst part, the major techniques used to irnprove Web server performance are reviewed. In the second part. the prior work done in the fields of main memory databases are discussed.
Chapter 3 presents the two main memory database models and the disk resident database model.
Chapter 4 discusses testing data, experimental environments, control parameters, performance indices and some background information about spatial range queries.
In Chapter 5, we present and analyze the experimental results. and finally give our recornmendat ions.
In Chapter 6, we summarize our achievements in the research. We list topics for future study. CHAPTER 2
BACKGROUND AND RELATED WORK
In this chapter, we fust briefly introduce the basic concepts of network computing, the
World Wide Web architectures, and the way the Web works. The background information is needed for understanding the later discussion. Then we present the related work. Since this research aims at improving Web server performance by using a main memory database at the server side, there are Iogically two parts in our literature review.
In the first part, the major techniques used to improve Web server performance are reviewed. In the second part, some important work done in the fields of main memory databases are described.
2.1 Network Computing
Over the years. there have been significant improvements of computer hardware and network technology. These irnprovements have driven the evohtions of the architectures of network computing. We have experienced the mainframe, clientlserver. and Internet comput ing.
In the 1960s, the information technology industry adopted mainfiame-based computing infrastructures. There is a singIe huge computer used by many users and every user has a comrnitted terrnina1. but the actual processing is done on the mainframe computer. One of the major problems is that as the number of users increases. mainframe becomes a bottleneck.
In the middle of 1990s. the architecture of client and server computing was very
populi^^. and was accepted as the standard architecture for enterprise computing. On the client side. there were PCs with graphical user interfaces. On the server side. high-end servers held databases, the software to share, etc. In between there were Ethernet LANs to connect the clients and servers.
Developing clientkerver application, however, is not an easy job. It is ofien int imidating and error-prone. Application developers had to define the communications protocols, write low-level network code for reliable transmitting and receiving messages, create user interfaces at the client side of the connection, write a server to listen and service incoming requests. and to transmit the results back to the client. Even simple chenthever applications may require thousands of lines of code. and the development pace was siow [Stein and Crawford, 19991.
As the advances in the Internet technology, the information technoIogy industry extends their client/server strategies to embrace the Web. The goal is to create a development piatform for applications that are cheaper and easier to develop and deploy.
More and more developers are looking to the Web mode1 as the Web has provided a simple but versatile communications protocol, a universal network client, and a set of reliable and well-written network servers [Stein and Crawford, 19991. 2.2 World Wide Web Architectures
Internet has created a wave of technology driven by low-cost. hig h-bandwidth networks
and easy-to-deploy Web technology. The introduction of Web has changed the view of
the user community to the computer network with respect to accessibility and user
friendliness. The World Wide Web began with a simple concept: linking together widely
dispersed documents. Through a web browser. people can easily access text. images.
sound and video files stored on mnning Web servers without having any knowledge
about the network. Frorn the user's perspective it does not make difference whether the
information he is looking for is on a computer in the next room or on the other side of the
world.
The WWW cornput ing architecture typically consists of multiple tiers that consist
of a presentation layer (browser). Web servers, extension programs, and backend corporate databases. Figure 2.1 shows the architecture of the Web. The first layer is the
presentation tier, which is based on a thin client. It is usually a Web browser as user
interface. In the rniddle-layer, there is the Web servers and server's extension programs.
The Web server handles inconiing requests, routes thern to the appropriate extension programs. Servers' extension programs implement the business logic required to service requests. such as query or update the corporate databases, etc. The database stores the data needed to support the Web site's operations. Extension Programs
f Web Web Browser Sener Database \ I -
Figure 2.1 The Web architecture
The advantages of this architecture include thin clients and extensible servers.
First. in the old clientherver model, clients were getting fatter. They demanded more software and hardware resources. In the Web model, "fat clients" become thin clients.
Secondly, with less software on the client side, less security problems may occur. Lastly, applications are more scalable as web servers and servers* extension programs can always be added or removed as needed to satisfy the increasing number of clients and different requirements. 2.3 Web Pages and Backend Databases
A Web page. which merely provides inforniation to users through access to files stored on a server. is known as a static web page. For example, the Web server at the site www.sumwhere.com may receive a request for a Web page specified by the Uniform
Resource Locator (URL) www.sumwhere.com~index.html. In this case, the file index-html is in the server's file system. The server maps the URL to the file and loads this file from disk and serves it out across the network to the user's Web browser. The ent ire exchange is mediated by the browser and the server that talk to each other using the
Hypertext Transfer Protocol (HTTP). The workflow is shown in the Figure 2.2.
1_) requests a document 2) looks for the document .--. ..------...------.- --- -.- ---* Machine
File System r-i
4) sends the document 3) loads the document
Figure 2.2 Requesting and serving a static Web page
The Web has become a major forrn of publication. Today, fewer and fewer Web servers contain only static HTML files because static Web pages have a serious limitation: communication with Web users is one way only. Web users want more than hyper-linked texts and graphies. Besides the static pages, they usually are more interested in interacting with Web sites. The power of Web publication cornes not simply from retrieving static HTML pages. but mainly from preparing pages dynamically and interactively. The interactivity is made possibIe by powerful software with the support of backend databases. Dynamic/interactive Web pages are created by the Web server' s extension program(s) at the time the request was received. In response to a query request, pages usually have to be tailored individually based on specific requests. Figure 2.3 shows how a Web server's extension prograrn constructs a dynamic Web page.
2) invokes the extension program and
-1) -.--requests .----..-.-.---I------.Il-- data ---. sends it parameters of the request i 1 Server Machine- &
4) sends the page 3) sends the dynamically constructed page
Figure 2.3 Requesting and serving a dynamic Web page
In the previous part, we discussed the applications of Web technology. The strengths of the Web can be sumrnarized as:
1. Web is used to present data, simplify and standardize user interface;
2. Via Web, browsers can access databases with no additional software at the
client side; 3. Web is a cornrnon interface for sharing and exchanging information of any
kinds.
With the help of databases, websites can decrease the arnount of static data embedded in HTML documents because more data cm be dynamically pulled fiom databases. Thus Web sites need less maintenance. Users may have more control over what is retrieved from the databases. for example. using a query language like SQL. The combination of Web and Database technologies rnay enhance accesses to databases, decrease maintenance of Web sites, and bring the dynamic nature to Web sites. Today, more and more Web sites are integrated with databases. 2.4 Techniques for Improving the Web Performance
With the Web becorning one of the dominant places for publishing information. traffic
has enormously grown on the local. national and international network backbones and so
have Web server hit rates- The huge traffic on the network and high hit rates at Web
servers rnay cause latency. Nevertheless, users never want to compromise the response
time and in fact they always desire the modest response time. Therefore, the issue of the
Web server performance has been well researched in the last decade. The major
approaches current ly used to irnprove Web performance include cac hing, clustering
servers, replicating Web servers. multicasting delivery of Web pages and reducing HTTP
latency.
2.4.1 Caching static pages
Web server performance can be improved by decreasing network traffic and reducing
Web servers' workload. One primary approach to achieve this goal is to install a Web caching service. Caching typically involves temporarily storing static content or content
that does not frequently change. Thus, it effectively migrates copies of popuIar documents from Web servers to somewhere closer to the Web clients. As a result, Web client users see shorter delays when requesting a page, network managers see lighter traffic and Web servers see Iower request rates. Local cache
A local cache is built into a Web browser to improve local Web performance. One rrüght notice that it may take less time to go back to a Web page that was visited previously than it was visited at the first time. The shorter response time is because the page is actually served by the local cache not the server. A Web browser's cache stores not only the documents currently displayed. but also documents requested in the past. There are two forms of client caches: persistent and nonpersistent. A persistent client cache retains its documents between invocations of the Web browser. Netscape uses a persistent cache. A nonpersistent client cache (used in Mosaic) deallocates any memory or disk used for caching when the user quits the browser [Melve, 19971.
Proxy cache
Proxy caches are ofien located near network gateways to reduce the bandwidth required over expensive dedicated Internet connections. It serves its clients with cached content from many servers. A shared proxy cache selects cache content based on the activity of the clients it serves. When a proxy cache receives a request for a Web object. it checks if the requested data are available in its cache. If so, it retums the requested object to the client without disturbing the upstrearn network connection and the Web server. If not, the proxy fetches the object for the client and also caches it for possible later retrievals. For even better performance, many proxy caches are part of cache hierarchies, in which a cache can request documents h-om neighboring caches instead of fetching them directly from the server [Chankhunthod et al., 19961. Reverse cache
Reverse cache cm be placed directly in front of a single server. to reduce the number of requests the server must handle. Most proxy caches can be used in this fashion to reflect the fact that it caches objects for many clients but usually from only one server
[Chankhunthod et al., 1996; Wessels, 19981.
In sumrnary, a Web cache has several potential advantages:
1. It reduces the overall network traffic as fewer requests and responses have to go
over the network.
2. It reduces workloads for Web servers as some of the requests cm be intercepted
and handled by the proxy cache-
3. It reduces latency as cached responses are available irnmediately.
4. It improves reliability, as some objects may be retrievable via cache even when
the original servers are not reachable.
Together, these features can make the Web less expensive and better perforrning
[Davison, 20001.
However, caching has disadvantages inc Iuding :
1. It may return a stale version of a page when the remote version has been changed
but the cache doesn't know [Davison, 20001.
2. It increases latency on requests for non-cached pages.
A more serious disadvantage is that caching is mainly used for static pages. 2.4.2 Caching dynamic content
The major critic of the caching technique described above is that it has difficulties in dealing with dynamic pages that have been involved in more and more Web queries.
To address this problem Luo et al. [?O001 proposed an enhanced proxy server. called an active proxy. to enable active query caching. Unlike the conventional cache discussed above. an active proxy derives some simple query processing power from the
Web server through a "query applet". Like the regular cache. the active proxy can answer those queries. which match the queries in the cache. What makes the active proxy unique is that it can answer queries that have no exact match in the cache. It can process those queries with the cached information.
Smith et al. [ 19991 proposed an approach for caching dynamic content at proxies.
Their approach allows Web content providers to specify result equivalence in generated documents so that a proxy can utilize the equivalence to return a cached result to a new request.
Iyengar and Challenger [1997] proposed to cache dynamic pages at the server the first time they are created. Subsequent requests for the same dynamic page can access the page in the cache instead of repeatedly invoking the same program to generate the same page. It aims at reducing CPU load on a server but not reducing network traffic. 2.4.3 Clusters of servers and a DNS distributor
Sometimes the workload of a Web site may grow exponentially. It may be beyond the capacity of any single server. A solution. proposed by Katz et al. [ 19941. was to distribute workloads across a cluster of identicaI Web servers, with each sharing the same file structure and contents, and answering to a comrnon host name. The designers employed a random rotation or round-robin DNS for distributing HTTP requests across the chster of servers. They also proposed the use of a distributed file system to solve the probkm of maintaining a synchronized, coherent set of files across the cluster. The use of large cache local to each server reduced the Iatency inherent in locating and retrieving the requested file from wit hin the DFS.
Mosedale et al. [ 19951 at the Netscape took a similar approach. Their cluster did not use identically configured machines as Katz et al. did. Their DNS distributor used a more sophisticated algorithm instead of using a random rotatiodround-robin rotation.
They believed that the round-robin rotation had a bias. In their approach, the DNS distributor polled the servers and passed on the connection to the next avaihble server.
This allowed the server cluster to balance the load between the servers based on the capacity of the individual servers.
2.4.4 Replication of Web servers
A Web server can be replicated and spatially distributed. The number and the locations of replications are deterrnined by the needs. Replication can improve both performance and reliability of the Web servers. Even though the go-first server (the closest server) fails, one of the other replicated servers can process the request. This improves the reliability.
Replication of the Web server can improve Web server performance because the workload is distributed arnong spatially distributed replicated Web servers. A request is always handled by the closest server. The server replication can be non-transparent or transparent co the Web clients. Non-transparent Web servers recjuire clients manually select a server. Mehmet Sayal et al. [1998] argued that server replication should be completely transparent to the user. They studied the criteria used for selection of replicated servers. which in turn depended on the exact notion of "proximity" metrie.
They studied several algorithms for selection of replicated HTTP servers. Their research showed that their new server selection algorithms improved the performance on the average by 55% when compared with other existing algorithms. In addition, their new algorithms improved the performance on the average by 69% when compared with the existing non-replicated Web servers. At the same time, the? new algorithms incurred only a minimal extra network overhead.
2.4.5 Multicast delivery of Web pages
Another technique that can be used in conjunction with caching and replication to improve scalability is multicast delivery. With this approach Web pages are delivered to multiple awaiting clients using one server response instance and using underlying network support for point-to-multipoint communication. The protocols for muiticast delivery are built around the IP multicast capabilities. Clients requesting the same page form a multicast group. The group is identified by a single multicast IP address and al1 clients need to explicitly join the group. Mostafa H. Ammar et al. [1998] showed the
architecture of a Web server capable of delivering pages using cyclic multicast, reliable
multicast. and reliable unicast. They categorized the requested pages of a Web site to
three groups: hot. warm and cold pages. The most frequently asked (hot) pages are served
by cycIic multicast: the moderately asked (warm) pages are served by reliable multicast;
and the seldom asked (cold) pages are served by reliable unicast transmission protocol.
They did empirical studies on a11 three transmission options for hot, warrn and cold pages. Their studies suggested that servers should integrate al1 the three delivery options to achieve the best performance and flexibility.
2.4.6 Improving HTTP latency
The HTTP protocol uses a separate TCP connection for each file requested. This adds significant overhead, especially in the number of network round trips required. To request a single HTML page from the server, it takes four network round trips to get the page. In order to reduce network latency, many researchers [Padmanabhan and Mogul, 1997;
Touch et al., 1998; Nielsen et al., 19971 suggested avoiding round trips through the network.
Researchers [Padrnanabhan and Mogul, 1997; Touch et al., 19981 proposed a solution of persistent connection. They used a single, long-lived connection for multiple
HTTP transactions. This connection was not closed at the end of an HTTP exchange.
Thus, it took two network round trips instead of four for a client to fetch an HTML page.
This avoided almost al1 per-connection overheads, and also helped avoid the TCP slow- start deiays. Also. the total number of packets was much smaller, which should lead to lower server workIoad. Finally, since the ratio of connection lifetime to the length of the
TIME-WAIT state was higher, the server had far fewer TCP connections (active or inactive) to keep track of. Nielsen et al. [1997] found that the persistent connections and pipelining reduced network use up to ten times. 2.5 Main Memory DataBases (MMDB)
In a main memory database system (MMDB), the primary copy of a database system resides permanently in physical main memory and the backup copy of the database system is on disk. In a conventional disk resident database system (DRDB), the primary copy of database system is on disk and the required data are read into memory before being accessed [Garcia-Molina and Salem, 19921.
The MMDB architecture is shown in Figure 2.4:
Stable Memory Archive Memory hgDisk WKfl AM
Figure 2.4 The MMDB architecture
A MMDB has the main memory (MM), which uses the standard RAM memory, an optional nonvolatile memory as stable memory (SM), and an archive memory (AM). The primary copy of the database resides in MM, and transaction execution is hence performed in MM. The SM is used to store log buffers, so it can avoid WO actions when transactions are committed. The AM holds a backup of the entire database afier the last checkpoint ing [Gruenwald et al. 19961, There are differences between main memory and magnetic disk as surnmarized by
Garcia-Molina and Salem [ 19931:
1. The access time for main memory is orders of magnitude less than for disk
storage.
2. Main memory is normally volatile. while disk storage is not. However, it is
possible to construct nonvolatile main memory.
3. Disks have a high, fixed cost per access to a block. When the amounts of the
requested data are srnaller than a block, the cost for accessing a block does not
depend on the amount of data. Disks are block-oriented storage devices. Main
memory is not block oriented.
4. The layout of data on a disk is much more critical than the layout of data in main
memory. Sequential access to a disk is faster than random access. Sequential
access is not as important as in main memory.
5. Main memory is directly accessible by the processor(s). This rnay make data in
main memory more vulnerable than disk resident data to software errors.
These differences have effects on almost every aspect of main memory database
management system design. Research on MMDB has been mainly focused on: concurrency control. commit processing, access met hods, and recovery.
2.5.1 Concurrency control
When several transactions execute concurrently in a database, the consistency of data may be violated. It is necessary for the systern to control the concurrent transactions.
Such control can be achieved through one of a variety of concurrency-control schemes. The findamental goal of database concurrency control is to ensure that concurrent
execution of transactions does not result in a loss of database consistency. The most
important and cornrnonly used scheme is a lock-based concurrency scheme to ensure
serializabiIity. A locking protocol is a set of niles, determining when a transaction should
Iock and unlock each of the data items in the database. In this way, the access to data
items can be done in a mutually exclusive manner. That is, while one transaction is
accessing a data item no other transaction can rnodify that data item.
When a transaction has to access a data item, it needs to hold a lock on that item.
When a lock cannot be granted, the transaction is forced to wait for the data item in
question to be uniocked. Long waiting time Ieads to longer response time. In order to
reduce response tiine. it is usually recornrnended to choose small lock granules (fields or
records) to reduce the contention for data item to be locked and response time according ly.
In main memory databases, accesses to data are much faster than in DRDBs. It takes much less time for transactions to complete. Locks will not be held as long and lock contention may not be as important as in a disk resident database. It has been suggested that very large granules are more appropriate for memory resident data. In the extreme, the lock grande couId be chosen to be the entire database [Garcia-Molina and Salem,
1992, Lehrnan and Carey. 19861. This leads to serial execut ion of transactions. Serial transaction processing is highly desirable, as we do not need any concurrency control mechanism at al1 to maintain the consistency of the database. The costs of concurrency control (setting and releasing locks, coping with deadlock) are almost compIetely eliminated [Garcia-Molina and Salem, 19921. 2.5.2 Backup and recovery
While MMDBs usually offer very high performance, they are more vulnerable to
software bugs, system failures and media failures. To protect against any kinds of failure,
it is always recomrnended to keep a backup copy of the MMDB and a log of transaction
activity [Garcia-Molina and Salem, 19921. Backup procedures may degrade performance.
In a DRDB, backup with checkpoints and data reload are handled offline. When using an
LMMDB, performance of checkpointing, backup and reload algorithrns play a major role
in maintaining adequate performance levels.
Commit processing
One of the big challenges for MMDBs comes when they "commit" transactions. Cornmit
means making a physical change in the location of the field addressed. Because memory
is more volatile than disk storage, it is mandatory to create a backup copy and to keep
logs of al1 transaction activities.
However, neither the backup nor its logs could be kept in memory. Before a
transaction commits, its activity records shouId be written to a log. Ultimately, logging
into stable log disk may degrade MMDBs performance because each transaction must wait for at least one stable write before its commit is successful [Garcia-Molina and
Salem, 19921. Several solutions have ken suggested to solve this problem. First, a srnall amount of stable memory (SM) can be used to hoid a portion of the log [Garcia-Molina and Salem, 1992; Gruenwald et al, 1996; Eich, 1987; Hagmann, 19861. A transaction is comrnitted by writing its log information into the stable memory, a relatively fast operation. A special process or processor is then responsible for copying data from the stable memory to the log disk. Although stable memory will not alleviate the log bottleneck, it can eliminate the response time problem, since transactions need never wait for disk operations [Garcia-Molina and Salem, 19921. Secondly, if the stable memory is not available. transactions can be pre-comrnitted [DeWitt et al.. 19841. Pre-committing is accomplished by releasing a transaction's locks as soon as its log record is placed in the log buffer. without waiting for the information to be propagated to the disk [Garcia-
Molina and Salem, 19921. It reduces the blocking delays and therefore the response time.
Lastly, Group commits can be used to relieve a log bottleneck [DeWitt et al.. 19841. Log records are not going to be propagated to the log disk before a transaction is comrnitted.
Instead they will stay in the log buffer and will be dumped into log disk only when the buffer page is Full. Group commits help minimize the overhead to write log records to log disk, a process required by transaction commits.
Reloading
In a MMDB, the primary copy of database resides in volatile main memory, it is more vulnerable than a DRDB to many kinds of failures. Everything in memory may be lost including the main memory database when a failure occurs. Afier losing the primary copy of database in memory. a reload is needed to bring the copy in the Archive Mernory to the main memory. It is very important to use efficient reloading algorithm. An inefficient algorithm tends to degrade the performance advantage of main memory databases. Gruenwald et al. [1996] categorized the reloading schemes as simple reloading and concurrent reloading. Simple reloading schemes block the transaction execution while bring the database system From the Archive to main memory and construct its most recent consistent state. The system does not resume transaction processing until the entire database is brought up in main memory. Concurrent reloading allows the system to resume transaction execution immediately afier a failure. Unlike the simple reloading, it perforrns the transaction executions and reIoading operation concurrently and therefore no transaction execution is blocked. Gruenwald et al. [1996] also proposed three different algorithrns to perfom concurrent MMDB reload process: ordered reload with prioritizat ion, smart reload, and frequency reload. The three algorithms are surnrnarized as:
In the ordered reload with prioritization, data are reloaded according to a pre- determined priority order and the system resumes its execution when a certain arnount
(percentage) of the database is memory-resident. The smart reload algorithm also uses a priority policy to reload the data; however, when data is not reloaded on a demand basis but on a pre-fetched basis, the block of the highest access frequency is searched and brought into MM. The frequency reload algorithm is similar to the ordered reload with prioritization except that it requires a special AM structure. In this structure, data is stored according to the order of frequency of access so that data of higher access is reloaded before data of Iower access.
Gruenwald et al. [1996f recornmended that the frequency reload yielded the best transaction response time and system throughput based on their simulation results. tevy and Silberschatz [L992] suggested a concurrent reloading scherne in which
the recovery activities were performed incrementaily. The system resumed operation
immediately after a system failure and recovers pages individually according to the demand of post-crash transactions.
2.5.3 Access methods
B-Tree is regarded as the major index structure for the block-oriented storage. Lehman and Corey [ 19861 introduced a new index structure, T-Tree, explicitly designed for main memory database. Since T-Tree has a very good overall performance, T-Tree has ken accepted as the major index structure for MMDBs. Lu et al. [2000] studied the performance of main memory database index structures, which allow concurrent accesses from multiple users. They proposed a B-linked Tree, which is a modified B-Tree. Their simulation studies suggested that the B-iinked tree outperformed the T-Tree if multiple and concurrent accesses were introduced. They disccvered that T-Tree required more locks to perform the concurrency control when multiple concurrent accesses were allowed. The overhead of concurrency control of T-Tree Ied to its poor performance.
Garcia-Molina and Salem Cl9921 suggested index structures that store only the pointers to the indexed data, rather than the data itself as random access is fast in memory and pointers cm be followed quickly. 2.5.4 Data representation
Even in hishly normalized DRDBs. there could be duplication of keys. Main memory databases can take the advantage of efficient pointers for data representation [Garcia-
Molina and Salem. 19921. In MMDBs, pointers are used to point to data values, and a set of pointers can be used to point to relational values. The use of pointers is space efficient.
When the same data appear multiple tirnes in the database, only one pointer is used for al1 the values and only one copy of the value needs to be stored. Garcia-Molina and Salem
[ 19921 suggested that pointers could simplify the handling of variable length fields since variable length data can be represented using pointers to heap elements.
2.5.5 Query processing
In DRDBs, data clustering is important in improvuig system performance. It is highly recommended to store Croups of data, which are most likely to be referenced together.
Data clustering saves the disk arm movement and therefore reduces disk access time.
In MMDBs, it is not necessary to cluster data because random data access is much faster. Query processing in main memory database will no longer take advantage of faster sequential access. Whanp and Krishmamurthy [ 19901 therefore suggested that query processors for memory resident data must focus on processing costs, whereas most conventional systems attempt to minimize disk access. CHAPTER 3
SIMULATION MODELS
In this research. we use two different techniques, Java servlets and Web server API
modules. to develop main memory Web databases. To study the performance of the two
techniques. we design two models, the Servlet-MMDB model using the Java servlet
technique and the Module-MMDB model using the Web server API technique. For
comparison, we create the CGI-DRDB model that simulates a Web DRDB.
The tliree rnodels simulate the same database, in which an application prograrn
perforrns range queries against spatial data - digital polygon maps. A range query is used
to retrieve objects on a map that are within a search rectangle (window).
3.1 CGI-DRDB Mode1
In this section, we introduce the CG1 protocok, the mechanism of the CGI, and its life cycle. Then we present Our CGI-DRDB model.
3.1.1 CG1 protocols and the Web
CG1 stands for "Cornmon Gateway Interface". It is not a progamrning language. It is a protocol that specifies the way in which user-defined scripts running at Web servers comrnunicate with browsers [Labrinidis and Roussopoulos, 20001. CG1 is an interface
that channels information between Web servers and scripts. A script performs required
processing.
CG1 is one of the first and major practical techniques for creating dynamic contents. It bridges the Web and other information resources like databases. For example, a CG1 script can be used to place a user-friendly Web frontend on top of a backend database. so that Web surfer can search the database from the Web without having to understand the database's query language, for example, SQL. Perl is the dominant scripting language in CG1 applications. However, for better performance, CG1 programs are ofien written in C/C++ and then compiled into binary executable fiIes.
3.1.2 Work flow of a CG1 application
Figure 3.1 illustrates the overall picture of CG1 scripting. CG1 scripting usually works with HTML forrns. In step 1 the client fiHs in a form and submits it. The Web server receives the request and encodes the form data. The data is encoded as a long string of name-value pairs like: "narne l=vaIue 1&narne2=value2&. ..". Step 2 shows that the Web server invokes its extension program, a CGI script in this case, and passes it the encoded form data. The CGI script implements business logic. It parses the request and decodes parameters. It accesses the data sources, reads relevant data into memory and processes the request. It, thereafier, constmcts a dynamic Web page and saves the page in the Web server's buffer in step 3. Finally the Web server sends the constructed Web pape to the client. / 1. Submit 2. Cali CG1 Web Web CG1 Browser Server PwPm
<
Figure 3.1 CG1 scripting
3.1.3 CG1 life cycle
For each request that involves calling a CG1 script, the Web server must create a new process. Creating a new process requires loading the script from disk into memory. And it consumes system resources as well. If the CG1 script is used to query a database, for example, it creates a database connection, reads data into memory. and processing the request. After finishing processing a request, the CG1 script ends its life cycle. It closes the database connection. Then the system resources allocated to the script are released.
3.1.4 Structure and workflow of the CGI-DRDB model
Our CGI-DRDB model is used to simulate the backend disk resident Web database. The
CG1 program in this model perforrns range search queries against the spatial data. It is written in C and compiled into a binary executable program. The spatial data are stored on disk.
The overview architecture and worktlow of the CGI-DRDB mode1 are shown in
Figure 3.2. First the Database Preloading Process is started (step 1). It generates the query data sets and then preloads them into the Spatial Data Pool stored on disk. (The details about the Database Preloading Process will be discussed in the next chapter.). Thereafier, the Web server is ready to answer search requests from clients. In steps 2 to 7, a client request is received and served. In processing a query request, the CG1 script accesses the
Spatial Data Pool on disk for the data needed.
Figure 3.3 shows more details about how a range search query is executed using our CG1 program. The client specifies the search window MBR (minimum bounding rectangle) in an HTML form. The Web server encodes the MBR, invokes the external
CG1 prograrn and passes the encoded MBR to the program. The CGI prograrn parses the
MBR and reads in the data required for processing the query from disk into memory. It then prepares the HTML page and sends the data to the server, which then sends to the client.
Our CGI-DRDB mode1 is analogous to the actuai architecture of the current Web databases (Figure 3.4). Each time when responding a client request that needs database access, the Web server creates a process for executing database application programs
[Ramakrishnan and Gehrke, 19981.
3.1.5 Multiple concurrent visits handled by CGIs
One of the major characrerist ics of the CG1 protocols is that it creates a heavyweight process for each request. This may drain system resources in consequence. Figure 3.5 illustrates how CG1 handles multiple concurrent requests and how system resources are consumed. When there are N simultaneous requests, the Web server needs to create N heavyweight processes. Each of the N processes contains a copy of the CG1 program and the data that are retrieved from disk. When N is large, N processes may consume a huge amount of memory. Once a process finishes. it is destroyed. CG1 processes do not persist between two invocations of the same script. When answering another request. a new process has to be created. Forking new processes may seriously affect the server performance because creat ing and starting processes take considerable amount of CPU time and consume a significant arnount of system resources (main memory). Also the heavy overhead restricts the number of CG1 scripts to run concurrently. 1 1 The Web Server Machine v I f 6)' 3 Web CG1 Semer -, program Hard Disk L / J C
Spatial Data Pool
Figure 3.2 An overview of the CGI-DRDB mode1 Browser Web Server CG1 Program
Encode form data Pleüsc. enter Sçrtrch Window MBR: form data
1 I
processi ng
Save the page in ?Create d-ynamic bu ffer LWeb page contained in the seürch window:
Spatial Data Pool le /1 ACCESS Hard Disk
Figure 3.3 Execution of a CG1 script I I / 7- - Ctt Application
7 4'< DBMS CGI Process 2 >
Figure 3.4 Process Structure with CG1 script [Rarnakrishnan and Gehrke, 19981
i 3 CG 1 script Web Browser b > < CG( script Web Bmwser , CGI- z Based > Web Browser Web E CG1 script i Server L
.a. S.. Web B- CG I script /
N Concurrent N Processes in memory Requests
Figure 3.5 N concurrent visits handled by the CG1 protocols In this section, we briefly discuss the technology of Java servlets and the mechanisrn of
servIet engines. At the end, we present our Servlet-MMDB model.
3.2.1 Java Servlets and the Web
A servlet is a Java program developed based on the Java servlet Application
Programming Interface (API) and the associated classes and methods. In addition to the
Java Servlet MI, a servlet can extend any other Java classes and impIement any interfaces.
Java HTTP servlets extend Web server capabilities by creating a frarnework for providing request and response services over the Web. When a client sends a request to a server, the server invokes a servlet and passes it the request information. The servlet performs actions for answering the request and returns result to the client. Java servlets can do almost everything CGT scripts can do. In addition, they have many good features.
3.2.2 Servlets life cycle
As shown in Figure 3.6, a Java servlet has a life cycle that defines how the servlet is loaded, initialized, executed and destroyed. A servlet is really a Java class cornpiled from source code and stored on disk. In Step 1, the sewlet engine loads the class into the Java
Virtual Machine (JVM) process and creates an instance of the servlet class the first time when the servlet is invoked, or optionally when the servlet engine is started. Then the servlet engine initializes the servlet. During the initialization process, the servlet configures itself. For example. it reads in persistent data, initializes database connection, and establishes references to system resources. Thereafter, the servlet is ready to respond to requests. As shown in Step 2, al1 the requests are processed using the same senilet instance. There is much less overhead for program invocations as the program is in memory. The servlet remains resident between requests. Step 3 shows that the servlet engine eventually destroys the servIet by calling destroy( ) when it is not needed. And the servlet engine releases the servlet and makes it eligible for parbage collection.
Load and ' Step 1 Initfalize Sewlet Servlet loaded & initialized once 1 Servlet ready to process requests v Sewlet Process Client Requests Step 2 I *
Servlet life cycle ends
Step 3
Figure 3.6 Life cycle of a servlet
39 3.2.3 Flow of a servlet execution
Figure 3.7 shows the flow of a servlet execution. The servlet engine instantiates and loads a servlet. The servlet engine then calls init( ) method to initialize the servlet. The process of instantiation, loading, and initialization is done once. At this point, the loaded and initialized servlet is ready to semer requests. When a client makes a request. the servlet engine passes both the HttpServlet Request object and the Htt pServlet Response object to the servlet. The HttpServletRequest gives the servlet access to the request parameters, such as form data. The HttpServletResponse allows the servlet to set response headers and status codes. It also allows the servlet to access an output stream object to return data to the client.
3.2.4 Structure and workflow of the Servlet-MMDB model
Figure 3.8 shows an overall structure and workflow of the Se~~let-MMDBmodel, in which the program performing range search on digital maps is coded as a servlet. Fist, the database preloading process is started as shown in step 1- It generates and preloads the data sets into the Spatial Data Pool stored on disk. RangeSearchServ is the Java servlet program we write to process spatial range search requests from clients. It is compiled into the bytecodes and can be loaded dynamically to expand the server's functionality. When the servlet engine starts, it instantiates the RangeSearchServ class, creates and loads the instance aRangeSearchServ servlet. It then initializes the servlet by loading the data in the Spatial Data Pool fiorn disk into main memory as shown in step 2. The servlet is ready to serve requests from clients. When clients send requests with their
search window MBRs to the server as shown in step 3, the server invokes the servlet
when a range search request arrives.
Since the servlet and the spatial data are al1 in main memory, the servlet starts processing the request by directly accessing the data in main memory as shown in step 4 and 5. The servlet generates the result and the server sends the response to the waiting client as shown in step 6.
3.2.5 Multithreads and concurrent visit handling
A servlet is invoked via a thread. In the multithreaded environment, threads are used to isolate tasks. Each thread is a sequential flow of control within the sarne process. Each operation runs independently from the others, but at the same time (time sharing).
A process has its own program counter. its own stack, its own register set, and its own private address space. A user process cannot directly address memory areas in the address space of another process. Processes mn separately and have nothing to do with each other. Like a process, a thread has its own program counter and stack to keep track of where it is. Threads. however, have no private address space. Multithreads reside in the same address space, they cooperüte, and share the same global variables, open files, timers, etc. One of the major advantages of threads is that al1 threads share the resources of their parent process. Once a servlet is loaded. it stays in the server's memory as a persistent object
instance. Figure 3.9 shows how a servlet handles multiple concurrent requests. For each
request, a thread instead a heavyweight process is created to handle the request. For N sirnuItaneous requests, there are N threads created to handle the N requests, but there is only a single copy of the servlet instance and a single copy of the data in main memory.
As a result, the servlet consumes far less rnemory than CG1 processes. Besides. there is no overhead of creating processes to handle requests as the CG1 protocols do. Web Server Servlet
- Load Servlet
HTTP Request
Time
HTTP Response
Figure 3.7 Servlet flow of execution The Web Server Machine
Figure 3.8 An ovewiew of the Sewlet-MMDB mode1
Web Server
i N concurrent requests a server process
Figure 3.9 N concurrent visits handled by a servlet In this section, we discuss the Web server API, its life cycle and its mechanism. Then we
present Our Module-MMDB model.
3.3.1 Server API modules and the Web
One of the greatest strength of the Apache Web server (and many others) is the modular
structure. There is only a core set of modules in the main Apache executable. The core
provides the basic functionality of a Web server. Everything else is provided by modules,
which can either be built into the server or loaded dynamically. Standard modules and
third-party modules can be added to or rernoved from the server as needed. This enables the adrninistrator to keep the server as small as possible. It improves the performance and makes the server less memory demanding.
Most Web server programs come with their own high performance, proprietary application prograrnrning interfaces (APIs). An API is used to write and incorporate new modules to extend the functionality of the Web server. A new module is linked directly to the Web server's executable. In other words, the new module becornes an integrated part of the server process. The most popular APIs are Netscape NSAPI, Microsoft lSAP1 and
Apache server AH.
Like CG1 scripts and Java servlets, the server API is a technique of server-side extension in the development of Web applications. For example, if a Company wants to publish its database and aIlows clients search the database via Web pages, one way to do it is to write a module and add the module to the server. When a client request arrives, the module first converts the client's searching request into a database query, retrieves the
desired data from the database. and returns them to the client.
3.3.2 Apache Life cycle
In this research, we use Apache to build Our Web server. Apache is a hypertext transfer
protocol (HTTP) server that mns in the background as a daemon. It listens for incorning
TCP/IP connections from Web browsers, parses the incoming request lines and headers,
and composes the outgoing HTTP response messages.
Figure 3.10 shows the Apache server life cycle. When an Apache server starts up,
it begins to configure itself by reading its configuration file. Directives are written in configuration files to controI the server's behavior. Then the server initializes its modules by calling each module's initialization routine. On a Unix system the server forks itself one or more times to create a child server pool that contains a set of child server processes. Child servers handle requests and the parent server listens for requests, monitors the status of its children and forks more child servers once the child servers in the pool are below the pre-defined level. MaxReq~cestsPerChild is a directive in the
Apache configuration file. It sets the limit on the nurnber of requests a chiId server process will service before it exits. The parent server passes the request to an idle child to handle. After fmishing a request, the child returns to the pool in an idle state for reassignments. Thus child servers are persistent. When the number of request processed by a child server exceeds the MarReq~cestsPerChild,the child server exits. Parent Server
Fqrk+
L Chiid
Child Iniqalization Child Initialization Child Initialization r 1
Request
Child Exits GO & & 1 Child Exits 1 r Child ExÎts 1
Figure 3-10 The Apache server life cycle
3.3.3 Structure and workfiow of the Module-MMDB model
In the Module-MMDB model, the program that performs range search queries against
digital maps is coded in C, compiled, and incorporated into Apache Web server as a
module (mod-RangeSearc h). Figure 3.1 1 shows an overall structure and work flow of the
Module-MMDB model. From a Web browser, a client can make a spatial range search
request by defining a search window MBR, the mod-RangeSearch processes the request and returns the relevant polygon information to the client. in the tirst step shown in Figure 3.11. the database preloading process is stxted. It generates and preloads the data into Spatial Data Pool stored on disk. The mod-Rangesexch module is initialized and the spatial data are read from disk into main memory. After the parent server forks a predefined number of child processes. the server is in the position to answer query requests from clients. To answer a request, there is no need to load a program and no need to access data on disk because the spatial data is in memory and so is the mod-RangeSearch module in the server process. Step 3 displays a client sends a spatial range search request to the Web server. In step 4 and 5, a child process handles the request and produces the response by retrieving relevant data from rnemory. In step 6, the server sends the response back to the client.
3.3.4 Multiple concurrent visits handled by a server module
Figure 3.12 shows how server API modules handle multiple concurrent requests. In order to avoid delays in responding, the server tries to concurrently handle as many requests as possible. The parent server forks a predefined number of child servers to handle multipIe concurrent H?TP requests. Child servers are persistent as we discussed in section 3.3.2.
Unlike CG1 prograrns that al1 processes created for requests take their own address space for code and data, al1 child servers in Apache share the same address space as the parent server process. And thus they share the same set of data as shown in Figure 3.12.
Therefore when compared with the CGI, using the server API results in less system resources consumption, spending less time in loading prograrns, and much better scalability and performance. Spatid Data Pool
Figure 3.11 An Ovemiew of the semer API Module-MMDB mode1
3 Web Browser , b J Ssrver API Program
/ Web Browser Module Scrvcr API Ragnm I i-Based Web Server
Web Bmwser Srrvrr API ~roprn1 N concurrent Requests Process Pool
Figure 3.12 N concurrent visits handled by a server API module CHAPTER 4
EXPERIMENT SETUP
4.1 An Overview
In our experiments, we test our three models: the CGI-DRDB modeI, the ServIet-MMDB model, and the Module-MMDB model. We test them in an environment in which processing an HTTP request involves retrieving and transmitting large volumes of data.
In order to set up such a test environment, we use a set of real geographic digital map data, and perform range search operations. Spatial operations usually retrieve and process large volumes of data. Besides, range search query results are not cacheable. The number of the choices of search window MBRs is infinite and requests using the same search windows rarely happen. A slight change in window position or size may resuIt in totally different retrieval operations and different results. 4.2 Testing Data, Spatial Indexing and Clustering
A set of real geographic data (polygon digital maps) is used in the experiments. In a geographic information system. a digital map usually consists of only one kind of spatial objects. such as point. lines or polygons. which could be called a point map. a line map or a polygon map. In this research, we use several polygon rnaps. which contain the most complex spatiaI objects, polygons. The rnaps are in binary format and the sizes of the maps are between 1 to i5 rnegabytes.
Many spatial operations are more computationally expensive than relat ional operations such as selection and join. It is important to have an efficient data accessing method and clustering strategy.
In this research. we use the quad tree technique to index the spatial polygon data.
A full quad tree data structure is formed by splitting a single parent node into four equal sized quadrants. usually called NW, NE, SW, SE. Then al1 descendants are recursively split into sub-quadrants until some pre-defined conditions are satisfied. When a polygon map is spatially indexed by a quad tree. the map is decomposed top down by the tree.
First the root of the tree is created for the entire map. Then the rnap is cut into four equally sized quadrants. A polygon goes into the quadrant where its center point locates.
Then, al1 the polygons are distributed into four quadrants. In the same fashion, the quadrants are partitioned recursively until the predetined condition is satisfied.
Data clustering is a technique used to group the data that are somehow similar and are likely to be referenced together. The objective is to efficiently access data in the database by using the least possible number of disk accesses and the least distance of disk arm movement. In this research, we cIuster digital polygon data based on the spatial location of the polygons, which is based on its center Iocation. We will discuss the indexing and clustering in more detaiis in 4.4 Database Preloadinp Process. 4.3 Spatial Range Search Queries
A spatial range query retrieves spatial objects that are within a search window rectangle, which is defined by a MBR (Minimum Bounding Rectangte). Range query is the frrst step in almost every spatial operation. It is used to avoid exhaustive search. It retrieves the "relevant" data for fürther processing.
There are two spatial operations used to support efficient evaluation of spatial relationship and other processing. They are: containment search and intersection search.
A containment search retrieves spatial objects that are fully fallen into a search window rectangle. An intersection search, however, retrieves spatial objects that are intersecting with a search window MBR.
To perform a spatial range search with the support of a quad tree, the search operation starts at the root node. The search compares the search window MBR with the node's MBR. It skips those nodes whose MBRs do not intersect with the search window's. For any node whose MBR intersects with the search window's MBR, check whether it is a leaf node. If the node is a leaf node, the search processes the polygons in the node: othenvise, the search will go further to its four quadrants recursively until leaf nodes are reached. 4.4 Database Preloading Process
The digital map contains raw map data of XY coordinates. In order to conduct spatial range search on a map, the map data needs to be preprocessed. We cal1 the preprocessing
"database preloading". Figure 4.1 shows the overview of database preloading process. It takes raw map data as input and converts thern into Query Data Sets containing the spatial database files and spatial index file as output. The database preloading process has to be done only once for each digital map. Its output is used in processing spatial range search queries.
Figure 4.1 Process overview of raw map data to query data sets
The detailed flow of data preIoading process is shown in Figure 4.2. It contains a few data blocks in grey ovals and function bIocks in white rectangles. The data blocks represent the transition sequences of data and the function blocks are functions, which make data transitions happen.
Data Converter converts raw map data into interna1 data structures, which can be processed by Data CIustering Processor and Quad Tree index Builder. Data Clustering
Processor writes al1 polygons in the digital map into a series of physical pages. A rnap is divided into a number of rows. The polygons are written to the pages by rows. The order of writing polygons into physical pages is based on the center-point locations of polygons. The writing order is from the north to the south and from the West to the east.
The output of this processor is the spatial database files. Quad Tree Index Builder recursively splits the space of a map into four equal sized quadrants until leaf nodes have been reached. It builds the spatial quad tree index and writes the quad tree index file. The combined sets of data are used for database queries. In testing the CGI-DRDB model, they are stored on disk. In testing the Senlet-MMDB model and the Module-MMDB model. they are later loaded into main mernory.
4.5 Performance Indices and Control Parameters
Performance indices are used to measure the performance of the simulation models.
There are two performance indices in Our experiments: the response time and the query processing time. The response time is the major indicator of the Web server performance from the clients' perspective. It is the time difference between a request is issued and a response is received. It is the time interval that a client waits for the response afier sending a request to the Web server. Query processing time is the time for the extension program to process the query. In Figure 4.3, the response time equals TJ -TI and the query processing time equals T3 - T1.
Control parameters are variables that could affect the overall performance of the simulation models. In our experiments, there are two simulation environments: the single visit environment and the multiple concurrent visit environment, which we will discuss in the next section. In the single visit environment. the control parameter is the size of the data retrieved. In the multiple concurrent visit environment. the control parameter is the number of concurrent visits. I Ftow of Execution
Figure 4.3 Execution Fiow Web Applications 4.6 Two Simulation Environments
Our experiments are conducted in two simulation environmerits. the single visit
environment and the multiple concurrent visit environment. ln the single visit
environment, there is no overlap between any two visits in tirne. The server processes
reqiiests sequentially. In the multiple concurrent visit environment, muItiple requests
arrive at the Web server simultaneously before the server has completed processing any
of the requests.
4.6.1 Single visit environment
The single visit environment is used to study system performance when there are no concurrent visits. We examine how the overall system performance is affected by the size of the data retrieved. The control parameter is thus the size of data retrieved. We choose nine sets of searching window MBRs. When MBRs in the same set are appIied to a digital rnap, similar sizes of data are retrieved. The sizes of data retrieved using the nine sets of searching window MBR are listed in Table 4.1. We record response time and the query processing time for each searching window MBR tested. 1 Numbers / Data Retrieval Sizes 1 I 3868k 1 2 4758k l 3 5628k 1 4 6382k I 5 7 15Ok 6 8132k 7 9550k i
Table 4.1 Sets of data retrieval sizes
4.6.2 Multiple concurrent visit environment
The multiple concurrent visit environment is used to study system performance when there are multiple concurrent visits. We examine how the number of concurrent visits affects the overall system performance. The control parameter is thus the number of concurrent visits. The number of concurrent visits is chosen from three, six up to thirty- nine, incremented by three. We record the response time and the query processing time for each searching window MBR tested.
In our experiments, we use the Java multithreading technique to simulate the multiple concurrent visit environment. On the client side, we create N threads to represent N clients issuing their spatial range search requests concurrently. On the server side, the Web server receives and processes them at almost the same time. The order for the threads to issue requests is decided by the operating system. 4.7 Equipment and Network for Tests
The client and the server run on two Hewlett Packard Visualize P600C cornputers. Each compucer has one Intei Pentiurn III 600 MHz processor and 256 megabytes main memory. The swap space of the server is 5 12 megabytes.
The operating system on the server machine is Linux RedHat version 6.1. The
Web server software is Apache version 1.3.12. The operating system on the client machine is Windows NT workstation 4.0.
Al1 tests are done on the local area network (LAN) in the Department of
Computing and Information Science at the University of Guelph. The network transmission speed is around 500k bytes per second. CHAPTER 5
EXPERIMENTAL RESULTS
In this chapter, experimental results are reported and analyzed to study the performance of the ServIet-MMDB mode1 and the server API Module-MMDB model. In al1 experiments, one percent of the data retrieved is transmitted over the network back to the clients as the response for each request. We compare the performance of the two models with that of the CGI-DRDB model. The results presented in this chapter are from an
Arizona geology map, which is a digital polygon map of 15 MB in size.
There are three sections in this chapter. In section 5.1, we present and analyze the experimental results of the three models in the single visit environment. In section 5.2, we present and analyze the experimental results of the three models in the multiple concurrent visit environment with a fixed data size, namely usine the same search window rectangle in al1 the queries. In section 5.3, we summarize the results and make recornrnendat ions. 5.1 Experimental Results of Single Visits
In the single visit environment, a request is sent to a server only when the server has
finished processins the previous request and is idle,
In order to study the effects of data sizes, we use the nine sets of search window
MBRs, which result in different sizes of the data retrieved as well as transmitted. In the
following, the size of the data retrieved when applying a MBR window is referred to the
"data size". The detaiIed information about the data sizes of the nine sets of search
window MBRs is listed in Table 4.1. The performance of different rnodels is evaluated
based on the response cime and query processing tirne.
The X-axes of al1 the plotting charts in this section represent data sizes. The
values are from one to nine, representing the data sizes in ascending order as described
above. The Y-axes are for response tirne and query processing time in milliseconds.
5.1.1 Result presentations
In the foIlowing, we show the plotting chczrts of the response time and query processing time for the CGI-DRDB, Servlet-MMDB and Server API Module-MMDB models. The results in a numerical format are Iisted in Table 5.1 and 5.2 to provide more detailed and more precise information. Table 5.3 shows the t values calculated.
Statistic tests
For each data size, we perform 30 experirnents on the three models. We report the mean vahes in table 5.1 and 5.2. The two sarnples in the pair of CGI-DRDB mode1 vs. Sewlet-MMDB model, CGI-DRDB rnodel vs. Module-MiMDB rnodel and Module-
MMDB mode1 vs. Servlet-MMDB mode1 are independent and drawn from normal populations with equal variance. We test a hypothesis about the difference between two population means fcr each data size. The test procedure is surnrnarized as:
Ho: pl- pz = DO(DO is specified)
7, - 7, - Do T.S.: t = S, J-
R.R.: For a Type I error G and df = nl + nz -2
Reject HO if Itl> t~2
y,, y- are sample means from sample 1 and sample 2. ni and n? are the number of observations from sample 1 and sample 2. S, is the estimate of the cornrnon standard deviation o. df is the degree of freedom,
t values are calculated and are in Table 5.3. For Û = 0.05, the critical t-value for a two-tailed test with df = 30 + 30 -2 = 58 can be obtained from the percentage points of the t Distribution. It is 2.000. Therefore we reject Ho if Itl > 2. Otherwise, we have insufficient evidence to reject the hypotheses that there is no difference in the mean number.
En Table 5.3, al1 t values are larger than 2. We can reject the hypotheses and conclude that the difference in mean is statistically significant. Response time and querv processing time of the three models
The piotting charts for the CGI-DRDB model. the Servlet-MMDB mode1 and the senrer
API Module-MMDB mode1 are in Figure 5.1, Figure 5.2 and Figure 5.3 respectively. Our
observations are:
l As data sizes increase. the query processing time increases.
2. As data çizes increase, the response time increases.
3. Response time closely depends on query processing time.
Cornparisons of the three models
In the following, we compare the Module-MMDB model and the Servlet-MMDB model
with the CGI-DRDB model respectively in terrns of the query processing time and
response time. The plotting charts of the response time and query processing time of the three models are given in Figure 5.4 and Figure 5.5. Figure 5.6 displays the response time
ratios of the Module-MMDB and Servlet-MMDB models over the CGI-DRDB model.
Figure 5.7 shows the query processing time ratios of the Module-MMDB and the Servlet-
MMDB models over the CGI-DRDB model. Our observations are:
1. The Servlet-MMDB model versus the CGI-DRDB modeI.
a. The query processing time curve of the CGI-DRDB model is slightly
higher than that of the Servlet-MMDB model when the data size is small.
As the data size increases, the two curves get closer and then intersect
when the data size is about 7150k. When the data size continues to grow,
the query processing time curve of the Servlet-MMDB model becomes higher than that of the CGI-DRDB model and thereafier, the difference of
the two curves become iarger and larger.
b. The response time curve of the CGI-DRDB model is higher than the curve
of the Servlet-MMDB model when the data size is srnall. When the data
size increases, the two curves get closer and closer, and intersect when the
data size is about 10968k. There is a tendency that the response time curve
of the ServIet-MMDB mode1 is higher than that of the CGI-DRDB model
as the data size continues to grow.
c. Table 5.1 and TabIe 5.2 also show that the ratios of the response time and
the query processing time of the Servlet-MMDB models over those of the
CGI-DRDB model. Figure 5.6 and Figure 5.7 show the plotting charts of
the ratios. Both ratio curves of the response time and the query processing
time of the Servlet-MMDB over the CGI-DRDB are lower than one when
the data size is small. They both rise as the data size increases. They get
closer and closer to one and go beyond one as the data size continues to
grow.
In surnrnary, when testing with single visits, the performance of the
Servlet-MMDB model is better than the CGI-DRDB model only when the data size is small. As the data size increases, the performance of the two models gets close. The CGI-DRDB model could outperforrn the Servlet-
MMDB mode1 as the data size continues to grow. 2. The server API Module-MMDB model versus the CGI-DRDB model.
Both the response time curve and the query processing time curve of the Module-
MMDB rnodel are rnuch lower than those of the CGI-DRDB model. With the data
size increases. the differences become larger and larger. Table 5.1 and Table 5.2
show numerically that both the average response tirne and the query processing
time of the CGI-DRDB rnodel are three or four times longer than those of the
Module-MMDB model respectively. Figure 5.6 and Figure 5.7 show the ratios.
Both ratio curves of the response t ime and query processing time are much lower
than one. It suggests that the Module-MMDB model always outperforms the CGI-
DRDB model.
5.1.2 Result analyses
Al1 the three models have the comrnon features that the query processing time and
response time go up as the data size increases, and the response time cIosely depends on
the query processing time. It suggests that cutting the query processing tirne can reduce
response time.
As shown in Figure 5.4 and Figure 5.5, both the response tirne curve and query
processing time curve of the server API Module-MMDB mode1 are much Iower than the corresponding curves of the CGI-DRDB model. The higher performance of the Module-
MMDB model is mainly due to:
1. The Module-MMDB mode1 adopts the main memory database technology. To
process a request, there are no disk accesses needed for data retrieval because the
primary copy of the database is in main memory. However. in the CGI-DRDB model data have to be read from disk into main memory before the CPU can
process them because the database resides on disk. Costly disk VO causes long
processing time.
2. In the Module-MMDB model, the mod-Rangesexch module written in Apache
server API is loaded in main memory when the Web server starts. For processing
a request. the program can be invoked imrnediately without loading it from disk.
The Servlet-MMDB model performs slightly better than the CGI-DRDB mode1 when the data size is small. Bigger data sizes require more computation. As the computations get more intensive, performance of the Servlet-MMDB model degrades. A servlet is a Java program. The perfomnce problem of the Servlet-MMDB model is due to the way in which Java programs are executed:
1. When running a Java program the Java mntime system performs lots of
housekeep ing to ensure the correctness of the program. The housekeeping, like
array bounds checking, nul1 reference checking etc., slows down the execution.
2. Java prograrns are usually compiled into Java bytecodes. When a Java program is
executed, the class loader in the Java Virtual Machine (JVM) loads its component
class files and then the execution enpine interprets the bytecodes. The
interpretation nature of Java prograrns slows down execution.
To compare C and Java, we conduct an experiment with two prograrns doing the same processing, one written in Java and the other in C. The execution time of the C program is about five times shorter than the equivalent Java program. The disadvantage of slow Java program execution offsets the advantages of the main memory database technology and the low invocation cost of servIets. When an application invo lves intensive data processing, the disadvantage makes Java Iess efficient.
There is one thing we should point out. That is. our CG1 prograrn is a compiled C program, which is very fast. CG1 applications are dominantly written in Perl scripting language, which is slow sspecially when the application is cornputationally intensive. For the same application, a CG1 application program in C runs much faster than Perl. In order to compare C and Perl for CG1 progmnming, we also test two small CG1 programs in C and Perl respectively. The two programs do the same processing. The comparison shows the execution time of the C program is about 15 times shorter than that of the Perl script.
If we compare the two MMDB models with a DRDB mode1 in Perl, the two rnodels would have even better performance. 3 4 5 6 Da ta Size
Figure 5.1 Response time and query processing time of CGI-DRDB model
+Res ponselÏrne -O- Query RocessingTime
2 3 4 5 6 Data Size
Figure 5.2 Response time and query processing time of Servlet-MMDB mode1
+Respons eTime Query Rocessinglime
Data Size
Figure 5.3 Response time and query processing time of Module-MMDB model Data Sue
Figure 5.4 Response time for the three models
6 7 8 9
Figure 5.5 Query processing time for the three models 'CGl-DRDB Servlet-MMDB [~odule-MMD' Servlet-MMDBI Module-MMDBI Module-MMDBI IData Sises (Millis) / (Millis) 1 (Millis) 7 CGI-DRDB 1 CGI-DRDB 1 Servlet-YMDB
Table 5.1 Response time of the three models, single visit
CI-DRDB Servlet-MMDB Module-MMDB Sewlet-MMDBI 1 Module-MMDBII Module-MMDBI Data ~izesl(Millis) 1 (Millis) (Millis) CGI-DRDB 1 CGI-DRDB I Servlet-MMDB 3868k 1 297 1 236 1 58 0-79 0.21 1 0.24
Table 5.2 Query processing time of the three models, single visit Data Sizes 1 CGI-DRDB vs. CGI-DRDB vs. Module-MMDB vs. 1 Servlet-MMDB 1 hludule-MMDB 1 Servlet-MMDB
Tabfe 5.3 t values for the single visits A - - A A a 7 T v 7 v
1 2 3 4 5 6 7 8 9 Data Sue
Figure 5.6 Response time ratios
1 1 2 3 4 5 6 7 8 9 Data SUe
Figure 5.7 Query processing time ratios 5.2 Experimental Results of Multiple Concurrent
Visits
In this section. we study the performance of the three models when they handle multiple concurrent visits. For simplicity. we use the same search window MBR in al1 the experiments.
In order to study the factor of the number of concurrent visits, we choose the number from three. six. and nine .... That is. it is incremented by three. The maximum number of concurrent visits is thirty-nine simply because the CGI-DRDB model cannot go beyond that limit with the hardware and software specified in Chapter 4. When the number of concurrent visits reaches 42, the server with the CGI-DRDB model cm no longer handle the visits correctly and display messages indicating interna1 errors. Even though the other two models can serve a lot more concurrent visits, we only present the experimental results up to thirty-nine concurrent visits.
The X-axes of the plotting charts in this section are the numbers of concurrent visits - three, six. and up to 39 incremented by three. The Y-axes are response time and query processing time in milIiseconds.
5.2.1 Result presentations
In this section. we display the plotting chans of the response time and the query processing time required by the CGI-DRDB model, the Servlet-MMDB model and the
Server API Module-MMDB model to respond to multiple concurrent visits (Figure 5.8,
5.9 and 5.10). Table 5.4 and 5.5 are constnicted to numerically display the detailed experirnental results of the three models. Table 5.6 shows the t values for comparing two
population means. Figures 5.13 and 5.14 display the response time ratios and query
processing time ratios of the two MMDB models over the CGI-DRDB model.
Statistic tests
For each number of concurrent visits, we perform 30 experiments on three
models. We report the mean values in table 5.4 and 5.5. The two sarnptes in the pairs of
CGI-DRDB model vs. Servlet-MMDB model, CGI-DRDB model and Module-MMDB
model and Module-MMDB model vs. Servlet-MMDB model are independent and drawn
from normal populations with equal variance. We test a hypothesis about the difference between two population rneans for each data size.
t values are calculated and are contained in Table 5.6. For 3 = 0.05, the critical t- value for a two-tailed test with df = 30 + 30 -2 = 58 can be obtained from the table of percentage points of the t Distribution. It is 2.000. Therefore we reject Ho if Itl > 2.
In Table 5.6, Itl values for the CGI-DRDB model and Servlet-MMDB model are less than 2 when the number of concurrent visits is 13 and below. Therefore, we have insufficient evidence to reject the hypotheses that there is no difference in the mean number. All other Itl values are larger than 2. thus we cm reject the hypotheses and conclude that the difference in mean is statistically significant.
CGI-DRDB model
The plotting chart for the CGI-DRDB model is presented in Figure 5.8. Our observations are: 1. Both the response time curve and the query processing time curve go up in a slow
pace as the number of concurrent visits increases from three îo 12 Once the
number becomes more than 12. the response time and the query processing time
increase in a fast pace.
2. The response time strongly depends on the query processing tirne.
Servlet-MMDB model
The plotting chart for the Servlet-MMDB model is given in Figure 5.9. Our observations are :
1. Both the response time and the query processing time increase as the number of
concurrent visits increases.
2. The response time goes up faster than the query processing time as the number of
concurrent visits increases. The difference between the two curves becomes larger
and larger as the number of concurrent visits increases.
Server API Module-MMDB model
Experimental results of the Module-MMDB model are displayed in Figure 5-10. Our observations are:
1. Both the response time and the query processing time increase as the nurnber of
concurrent visits increases.
2. The response time goes up much faster than the query processing time as the
number of concurrent visits increases. Cornparisons of the three models
The plotting charts of the response time and query processing tirne of the three models are in Figures 5.1 1 and 5.12. Our obsewat ions are:
1. The Module-MMDB model versus the CGI-DRDB model.
The response time curve and query processing tirne curve of the Module-MMDB
model are much lower than those of the CGI-DRDB mode[. The data in Table 5.4
indicate that when the number of the concurrent visits is three, the response time
of the CGI-DRDB model is about three times and the query processing time is
about 1 1 times longer than those of the Module-MMDB model respectively. As
the number of concurrent visits increases, the performance of the CGI-DRDB
mode1 gets worse and worse. Especially when the number of concurrent visits
goes beyond 12, the performance deteriorates even faster. When the number of
concurrent visits reaches 39, the response time of the CGI-DRDB model is more
than six times and the query processing time of the CGI-DRDB model is about
400 times longer than those of the Module-MMDB rnodel respectively.
2. The Servlet-MMDB versus the CGI-DRDE model.
When the number of concurrent visits is below 15, the response time curve and
the query processing time curve of the Servlet-MMDB rnodel are very close to
those of the CGI-DRDB model respectively. The two models are not statistically
significantly different from eac h other in performance as we discussed earlier
(their (tl < t critical value). However, when the number of concurrent visits goes
up to or beyond 15, the performance of the Servlet-MMDB mode1 becomes better
than that of the CGI-DRDB model. As the nurnber of concurrent visits increases, the performance difference of the two modek becornes bigger. As shown in Table
5.4 and Table 5.5, when the number of concurrent users hits 39, the response tirne
of the Servlet-MMDB mode1 is about three times and the query processing time
of the Servlet-MMDB rnodel is 12 times shorter than those of the CGT-DRDB
model.
3. The Servlet-MMDB model versus the Module-MMDB model.
The Module-MMDB model outperforms the Servlet-MMDB model by an average
of two times.
4. The response time is closely related to the query processing time. Less query
processing results in less response tirne. The Module-MMDB model has the
lowest query processing time and has the best performance in tems of the
response time.
5.2.2 Result analyses
For a11 the three models shown in the Table 5.5, query processing time increases as the number of concurrent visits increases. This is mainly due to:
CPU time has to be distributed to more processes/threads chat are executed at the
same time.
In the case of CGI-DRDB model, more time has to be spent on creating new
processes, loading programs, and starting the prograrns.
In the case of the Servlet-MMDB and Module-MMDB rnodeIs, more time has to
be spent on starting the programs. For al1 the three models, the response time depends on the query processing tirne. It
can be seen in Figures 5.8, 5.9 and 5.10. Query processing time is a major component ia
response time. When query processing time changes, so does the response time.
The Module-MMDB model has the best performance because it has the lowest query processing cost. The lowest query processing cost is mainly because there is no program Ioading and no disk V0. Et is also because of the fast execution of C program
The performance of Servlet-MMDB is not as good as that of Module-MMDB because it has Ionger query processing time, which is caused by the nature of Java Ianguage as discussed before. The performance of the CGI-DRDB model is the worst because it has the longest query processing time, which is caused by the overhead for creating new processes, loading the program, and heavy disk VO.
For the same rnodel, the response time curve and query processing time curve are of the similar shape but of different change rates. The response time curve has larger increase rate. This is because larger data sizes cause larger transmission tirne, which is the other major component in response time.
When the number of concurrent visits becomes more than twelve, the query processing tirne of the CGI-DRDB model increases in a much larger rate and the other two increase in the same rates. To discover the causes, we use the "top" utility in UNIX to monitor the use of main memory and found that memory swapping occurred in the
CGI-DRDB model when the number of concurrent visits reaches 15. When the number of concurrent visits increases, the swapping becomes heavier and heavier. When the number of concurrent visits becornes larger than 39, the Web server with the CGI-DRDB model cannot handle the visits rnainly because of the heavy swapping. There is no memory swap occurred in the ServIet-MMDB model and the Module-MMDB model even when the number of concurrent visits becomes much higher than 39. -Memory use does not change much as the number of concurrent visits increases in the two MMDB models. 5.3 Summary and Recommendations
Summary
Significant performance irnprovement can be achieved by using the Module-MMDB
model. When used with a server of light workload (single or small number of concurrent
visitsj, the response time can be reduced to l/S - 1/3. When used with a server with
heavy workload (the number of concurrent visits is greater than LZ). the response time
can be reduced to 1/3 - 15%.
Significant performance improvement cm be achieved by using the ServIet
MMDB model with a server with heavy workload, the response time can be reduced to
1/2 - 29%.
Both MMDB models cm improve the robustness for servers with heavy
workloads and dramat ically increase the number of concurrent visits the servers can
handle.
Recommendations
The MMDB techniques are more suitable for Web servers with very heavy workloads. If
performance is the major concern, the server API module is the choice. It gives the best
performance improvements.
Java servlet mode1 has a very good performance although it is not as good as the
server API. Java servlets have strengths over the other two models. They can be
surnmarized as: 1. Safety. Java's exception handling rnakes a servlet safer than proprietary APIs
and CG1 prograrns in C. Therefore, a faulty servlet does not crash the Web
servers. The server APIs typically support C/C++ code executing in the Web
server process. If the application crashes, e.3. due to a bad pointer or division by
zero, it brings down the Web server as well.
2. Portability. A servlet is portable across platforrns and Web servers. A Web
server module is written in proprietary server APL It is not portable at all.
3. Security. Java security mode1 makes servlets very secure against malicious
actions by Web applications. The server APT modules and CG1 prosams are
considered very poor in security.
4. Ease of irnplernentation and maintenance. Java servlets are easy to develop and
maintain. The learning cuve for the development of Server modules is steep and
the code maintenance is poor.
If above factors must be taken into considerations dong with performance, the servlets seern to be the first choice. 1234 5678910111213 Number of Concurrent Visits (X3)
Figure 5.8 Response time and query processing time of CGI-DRDB mode1
123 4 5 6 78 910111213 Number of Concurrent Visits (X3)
Figure 5.9 Response time and query processing time of Servlet-MMDB mode1
+Response Tm +Query Rocessing lime
1234 5 678 910111213 Number of Concurrent Visits (X3)
Figure 5.10 Response time and query processing time of Module-MMDB mode1 123 456 78 910111213 Number of Concurrent Visits (X3)
Figure 5.1 1 Response time for three models
60000 h -VI 50000 Y -% 40000 % 30000 V) Q) g 20000 L ioooo 36 CI O 12345678910111213 Number of Concurrent Visits (X3)
Figure 5.12 Query processing time for three models !concurrent/CGI-DRDB /~ervlet-MMDBModule-MMDB Servtet-MMDB/ M~~U~~-MMDBI~M~~U~~-MMDB/ 1 Visits 1 (Millis) 1 (Millis) (Millis) CGI-DRDB , CGI-DRDB 1 Servlet-MMDB 3 1 896 1 887 31 2 0.99 0.35 j 0.34
Table 5.4 Response time of three models multiple concurrent visits
Concurrent CGI-DRDB Servlet-MMDB Module-MMDB Servlet-MMDBI Module-MMDBI MO~UI~-MMDB~ 1 ~isits (Millis) (Millis) (Millis) CGI-DRDB CGI-DRDB Servlet-MMDB 3 192 447 17 2.33 0.09 0.04 -4
Table 5.5 Query processing time of three models multiple concurrent visits i Number of / CGI-DRDB vs. CGI-DRDB vs. Module-MMDB vs. Concurrent Visits 1 Servlet-MMDB Module-MMDB Servlet-MMDB
Table 5.6 t values for the multiple concurrent visits 123 4 5 6 7 8 910111213 Number of Concurrent Visits (X3)
Figure 5.13 Response time ratios
123 4 5 6 7 8 910111213 Number of Concurrent Visits (X3)
Figure 5.14 Query processing time ratios CHAPTER 6
CONCLUSIONS
6.1 Achievements
The major achievements of t his research include:
1. We design and successfully impiement two MMDB approaches for Web servers.
2. Experiments with real data show that with the current Intemet
speeds, MMDBs can significantly improve performance for Web servers of
heavy workloads. The performance improvement is equivalent to that obtained by
increasing net speeds by 2 to 7 times. Such network speed increase is very
expensive and currently difficult to achieve.
3. Experiments also show that the MMDB technique can improve the robustness for
Web servers with heavy workloads. It cm dramatically increase the nurnber of
concurrent visits a Web server can handie.
4. We study the suitability of the server API module based approach
and the Java servlet based approach. 6.2 Future Work
For the two main memory Web database models we experimented, we rely on the
fac ilit ies provided by Apache and Java for memory allocation, garbage collection, and
process/thread scheduling. We have little control over the activities. The facilities may
not be the most suitable for main memory Web databases. If we can gain more control
over those activit ies, we may further improve the performance and the capability
of serving concurrent clients for Web databases. For example, if memory can be carefully
allocated to reduce wasted space. the maximum number of concurrent visits that can be
served can be further increased. Also, if data that are typically used together are allocated
near each other. cache rnissing can be reduced and thus performance can be further
improved. In the future work of this research, we wiil devetop our own techniques and algorithms for memory allocation, garbage collection, and procesdthread scheduling, experiment them wit h real data, and recornrnend the ones suitable for main memory Web databases.
This research reveals that memory usage is a bottleneck that reduces Web databases' performance and their capabiIity of serving concurrent visits. Excessive use of memory results in heavy swapping, which in turn causes lower performance and even systern crash. This finding can be used to improve performance and the capability for
DRDB Web databases. By incorporating algorithms that cm improve memory utilization, current DRDB Web databases can be improved in terms of the response time and the capability of serving more concurrent visits. It is an interesting topic to study mernory control algorithms fo r DRDB Web databases. BIBLIOGRAPHY
[Akal. 19991 Fuat Akal. "Main Memory Database Systems".
http://kavak.cs.hun.edu.tr~isc/mmdb/mmdb.htm, May 1999
[Ammar et al.. 19981 Mostafa H. Ammar, Kevin C. Almeroth, Russ J. Clark and
Zongmin Fei, "Multicast DeIivery of Web Pages", 1998 Workshop on Internet Semer
Performance Madison, Wisconsin, June 1998
[ AnaIyti and Pramanik, 19921 Anastasia Analyti and Sakti Pramanik, "Fast Search
in Main Memory Databases", In Proceedings of the ACM SIGMOD International
Conference on Management of Data, pages 2 15-224, 1992
[Abrarns et al., 19951 Marc Abrams, Charles R. Standridge, Ghaleb Abdulla,
Stephen Williams and Edward A. Fox, "Caching Proxies: Limitations and Potentials",
http://ei.cs.vt.edu/-succeed/WWWLCn;YWW4.html, 1995
[Bohannon et al., 19961 PhiIip Bohanrion, James Parker, Rajeev Rastogi, S.
Seshadri, Avi Silbersc hacz and S. Sudarshan, "Distributed Multi-Level Recovery in
Main-Memory Databases", In Proceedings of the Fourth International Con fer ence on
ParaIlel and Distributed Information Systerns (PDIS), Miami Beach, FL, December
18-20 1996.
[Chankhunthod et al., 19961 Anawat Chankhunthod, Peter B. Danzig, Chuck
Neerdaels, iMichael F. Schwartz and Kurt J. Worrell, "A Hierarchical Internet Object
Cache", In Proceedings of the USENIX Technical Conference, San Diego, CA,
January 1996. 7. [Cheshire. 19961 Stuart Cheshire, "It's the Latency, Stupid".
-ht tp://rescomp.stand ti,rd.edu/-cheshirr/rants/Latency. html, 1996
S. [DeWitt et al.. 19841 David J. DeWitt, Randy H. Katz, Frank Olken. Leonard D.
Shapiro. Michael R. Stonebraker and David Wood. "Implementation Techniques for
Main Memory Database Systems", In Proc. Of International conference on
Management of Data. page 1-8, ACM SIGMOD, 1984
9. [Davison. 20001 Brian D. Davison. "A Survey of Proxy Cache Evaluation
Techniques". http://www.npac.svr.edu/users/ocf/workino/wiscpaper/wisc9S.html,
2000
10. [Duska, 19971 Bradley M. Duska. David Mmood and Michael J. Feely, 'The
Mrasured Access Characterist ics of World- Wide-Web Client Proxy Caches", In
Proceedings of the USENIX Symposium on Intemet Technologies and Systerns
(USITS '97), December 1997
1 1. [Eich, 19871 Margret H. Eic h, "A Classification and Cornparison of Main
Memory Database recovery Techniques", In Proc. International Conference on Data
Engineering, February 1987
12. [Eich, 19921 Margaret H. Eich, "Main Memory Databases: Current and Future
Research Issues". IEEE Transactions on Knowledge and Database engineering, 4(6):
507-508, December 1993
13. [Franklin, 19961 Michael J. Franklin, "Concurrency Control and Recovery", 14. [Garcia-Molina and Salem, 19871 Hector Garcia-Molina and Kenneth Salem.
"High Performance Transaction Processing with Memory Resident Data". In Proc.
International Workshop on High Performance Transaction Systems, Paris, December
1987
15. [Garcia-Molina and Salem. 19921 Hector Garcia-Molina and Kenneth Salem
"Main Memory Database S ysterns: An Overview", IEEE Transactions on Know ledge
and Data Engineering, Vol. 4, No. 6, December 1992
16. [Gruenwald and Eich, 19911 Le GmenwaId and Margaret H. Eich, "MMDB
Reload Algorithms", In Proceedings of the ACM SIGMOD International Conference
on Management of Data, pages 397-405, 1991
17. [Gmenwald et al, 19961 Le Gruenwald, Jing Huang, -Margaret H. Dunham, Jun-Lin
Lin and Ashley Chaffin PeItier, "Recovery in Main Memory Databases",
International Journal of Engineering Intelligent Systems. A Special Issue on
Databases and Telecornmunications, Volume 4, Number 3, pages 57-63. September
1996
18. [Gruenwal et al., 19981 Le Gruenwald, Yuwei Chen and Jing Huang, "Effects of
Update techniques on Main Memory Database System Performance", IEEE
Transactions on Knowledge and Data Engineering, Vol. 10, No. 5,
SeptembedOctober 1998
19. [Hagmann, 19861 Robert B. Hagmann, "A Crash Recovery Scheme for a Memory
Resident Database Systern", IEEE Transactions on Cornputers, C-35(9): 839-843,
September 1986 20. [Hunter and Crawford. 19981 Jason Hunter and WilIiam Crawford, " Java Senlet
Programrning", O' Reilly & Associates. Inc. 1998
2 1. [Iyengar and Challenger, 19971 Arun Iyengar and Jim Challenger, "1 mproving Web
Server Performance by Caching Dynarnic Data", Proceedings of the USENIX
Symposium on Internet Technologies and Systerns, December 1997
22. [Jagadish et ai.. 1994) H. V. Jagadish, Daniel Lieuwen, Rajeev Rastogi. Avi
Silberschatz and S. Sudarshan, "Dali: A High Performance Main Memory Storage
Manager". Proceedings of the 20'~VLDB Con ference Santiago. Chile. 1994
23. [Kabir, 19991 Mohammed J. Kabir, "Apache Server Administrator's Handbook",
IDG Books Worldwide, Inc., 1999
24. [Katz et al., 19931 Eric Dean Katz. Michelle Butler and Robert E. McGrath. "A
Scalable HTTP Server: The NCSA Prototype", Computer Networks and ISDN
Systerns. Volume 27, pages 155- 164. September 1994
25. [Labrinidis and Roussopoulos, 2000) Alexandros Labrinidis and Nick
Roussopoulos. "Generating Dynarnic Content at Database-backed Web Servers: CGI-
bin vs Mod-perl", SIGMOD Record, 29(1), March 2000.
26. [Lehman and Carey, 19861 Torbin J. Lehman and Michael J. Carey, "Query
Processing in Main Memory Database Management Systems", In Proceedings of the
ACM SIGMOD International Conference on Management of Data, pages 239-250,
May 1986
27. [Lehman et al.. 19861 Torbin J. Lehman and Michael J. Carey, "A Study of Index
Structures for Main Memory Database Management Systems", In Proceedings ACM
SIGMOD Conference on Management of Data, Washington, DC, May 1986 28. [Lehrnan et al.. 19921 Torbin I. Lehrnan. Eugene J. Shekita and Luis-Felipe
Cabrera. "An Evaluation of Starbust7sMemory Resident Storage Component", IEEE
Transactions on Knowledge and Data Engineering, Vol. 4. No. 6, December 1992
29. [Levy and Silberschatz, 19921 Eliezer Levy. Avi Silberschatz, "Incremental
Recovery in Main Memory Database S ystems". IEEE Transactions On Knowledge
and Data Engineering, Vol. 4, No. 6, December 1992
30. [Li and Eich, 19921 Xin Li and Margaret H. Eich. "Post-crash Log Processing
for Fuzzy Checkpointing Main Memory Databases", IEEE Transactions on
Know ledge and Data Engineering, 4(6): 529-540, December 1992
3 1. [Lin and Eich, 19951 J. L. Lin and Margaret H. Eich, "Speedup Recovery From
Fuzzy Checkpoints", Technical Report TR 95-CSE- 17, Department of Computer
Science and Engineering, Southern Methodist University, September 1995
32. [Lindstrom et al., 19991 Jan Lindstrom, Tiina Niklander, Pasi Porkka and Kimmo
Raatikainen, "A Distributed Real-Time Main-Memory Database for
Telecommunication". September 6th 1999, Edinburgh. LNCS 18 19
33. [Litwin and Risch, 19921 Witold Litwin and Tore Risch, "Main Memory Oriented
Optimization of O0 Queries Using Typed Datalog with Foreign Predicates". IEEE
Transactions on Knowledge and Data Engineering, Vol. 4, No. 6, December 1992
34. [Lu et al., 20001 Hongjun Lu, Yuet Yueng Ng and Zengping Tian. "T-Tree or B-
Tree: Main Memory Index Structure Revisited", Proceedings of Database
Con ference. 2000 35. [Luo et ai., 20001 Qiong Luo, Jeffrey F. Naughton, Rajesekar Krishnamurthy, Pei
Cao and Yunrui Li, "Active Query Caching for Database Web Servers", In the 3rd
International Workshop on the Web and Databases [WebDB'2000], Dallas, Texas,
2000
36. [Melve. 19971 Ingrid Melve, "Web Caching Fuchitecture".
http://www.uninetr.no/prosiekt/desire/ar, March 1997
37. [Mosedale et al., 19951 Dan Mosedale, William Foss and Rob McCool,
"Administering Very High Volume Internet Services". Proceedings of the Ninth
Systems Administration Conference LISA, 1995.
38. [Nielsen et al., 19971 H. Frystyk Nielsen, J. Gettys, A. Baird-Smith, E.
Prud'hommeaux. H. Lie and C. Lilley, "Network performance effects of httpll. 1,
css 1, and png", In Proceedings of the ACM SIGCOMM '97', Cannes, France
39. [ Padrnanabhan and Mogul, 19971 Venkata N. Padmanabhan and Jeffiey C.
Mogul. "Improving HTTP Latency",
http://www.eecs.harvard.edu/-vino/web/sits.97. html, 1997
40. [Ramakrishnan and Gehrke, 19981 Rag hu Ramakrishnan and JOhannes Gehrke,
"Database Management Systerns". McGraw-Hi11 Companies, Inc., 1998
4 1. [Ru bart h-Lay, 19961 James Rubarth-Lay, "Optimizing Web Performance",
http://eunuc h.ddg.com/LIS/C~berHorn';S96/i.rubarth-l~/PAPERhtml, 1996
42. [Salem and Garcia-Molina, 19891 Kenneth Salem and Hector Garcia-Monlina,
"Checkpointing Mernory-Resident Databases", In Proceedings of International
Conference on Data Engineering, pages 452-462, 1989 43. [Sarawagi. 19931 Sunita Sarawagi, "Database Systems for Efficient Access to
Tertiary Mernory". Technical Report, University of California at Berkeley. 1993
44. [Sarawagi, 19953 Sunita Sarawagi, "Query Processing in Tertiary Memory
Databases". Proceedings of the 2 1" VLDB Conference, Zurich, Swizerland, 1995
45. [Sayal et al., 19981 Mehmet Sayal, Yuri Breibart, Peter Scheuermann and
Radek Vingralek. "Selection Algorithrns for Replicated Web Servers". 1998
Workshop on Internet Server Performance, Madison, Wisconsin, June 1998
46. [Silberschatz et al.. 19961 Abraham S ilberschatz, Henry F. Korth and S. Sudarshan,
"Database System Concepts", The Third Edition, WCBMcGraw-HiIl. 1996
47. [Smith et al., 19991 Ben Smith, Anurag Acharya, Tao Yang and Huican Zhu,
"Caching Equivalent and Partial results for Dynamic Web Content", Proceedings of
1995 USENIX Symposium on Internet Technologies and System
48. [Stein and MachEachern. 19991 Lincoln Stein and Doug MachEachern. "Writing
Apache Modules with Perl and C", O'Reilly & Associates, Inc., 1999
49. [Thau, 19961 Robert Thau, "Design Considerations for the Apache Server API",
Fifih Internat ional World Wide Web Con ference May 6- 10, 1996, Paris, France
50. [Touch et al., 19981 Joe Touch, John Heidemann and Katia Obraczka, "An
Analysis of HTTP Performance", ISI Research Report ISI/RR-98-463, August 1998
5 1. [Wessels, 19981 Duane Wessels. "Squid Internet object cache documentation".
http://squid.nlanr.net/Sq~~idl,1998 52. [Whang and Krishmamurthy. 19901 Kyu-Young Whang and Ravi
bishnamurthy. "Query Opt imizat io n in a Memory-Resident Do main Relat ional
Calculus System", ACM Transactions Database Systems. Vol. 15, No. 1, page 67-95.
March 1990
53. [Woo et al., 19971 Seungkyoon Woo, Myoung Ho Kim and Yoon Joon Lee,
"Accornrnodating Logical Logging under Fuzzy Checkpointing in Main Memory
Databases", Proceedings of the 1997 International Database Engineering and
Applications Symposium (IDEAS'97)