资源说明：This project revolves around developing an optimization technique to improve the responsiveness of iBATIS cache by introducing the notion of a cache warming harness in iBATIS framework. iBATIS is a persistence framework which automates the mapping between SQL databases and objects in Java. It allows programmers to map the parameters and results between the class properties and the columns of a database table. It also provides support to load properties that represent composite objects. However, this results in the classic N+1 query problem. Though iBATIS provides a way to cache the mapped statement, the default iBATIS cache models are not sufficient to solve the N+1 problem as it caches data only on demand and each unique cache miss is costly. The problems of different cache strategies are initially studied and an enhanced cache design for iBATIS is proposed and implemented in this dissertation. The experimental results showed that the proposed cache design outperformed the default cache model of iBATIS framework in terms of responsiveness and solved the N+1 query problem by incurring that cost upfront at application load time.

See http://balak1986.github.com/prime-cache-support-in-ibatis2 for better look.

CHAPTER 1
Introduction

1.1 Overview
iBATIS is a persistence framework which automates the mapping between SQL databases and objects in Java. It allows programmers to map JavaBeans objects to PreparedStatement parameters and ResultSets. It uses XML descriptors to map JavaBeans to SQL statements. In iBATIS, Result Maps finish the job by mapping the result of a database query (a set of columns) to object properties. It is possible to load properties that represent composite objects by associating a result map property with a mapped statement that specifies how to load the appropriate data and class for complex property. The results from a query mapped statement can be cached by iBATIS cache model.
The problem with populating properties of fully-formed complex type is that whenever iBATIS load a complex type, two SQL statements are actually being run (one for composite object and one for its complex property).  This problem seems trivial when loading a single composite object, but if we were to run a query that loaded N composite objects, a separate query would be run for each composite object to load its complex property. This results in N+ 1 query in total: one for the list of composite object and one for each composite object returned to load each related complex property.
The result set might have N objects, but there might only be M (where M


Cache model configuration
 
Figure 3: The static structure of the primed cache design

PrimeCachingStatement holds the reference to mapped statement that needs to be executed to load data for primed cache. When user set primedCache attribute to true, it is mandatory to set primedCacheQuery attribute of select element that want to take advantage of primed cache. The primedCacheQuery attribute specifies which query needs to be run to warm the cache. 


	
Select statement that wanted to use prime cache

Primed cache uses partial keys and specific keys. A partial key corresponds to a discrete set of data with common characteristics whereas a specific key corresponds to an exact data item in the cache. The mapped statement of primedCacheQuery is used as partial key. The mapped statement of select query and parameter of select query combined together is used as specific key. The keyProperty attribute will be provided in select element by user to say which property of the results should be used as parameter component of specific key.

4.3 Interaction Diagrams
Primed cache uses primedCacheQuery to read the entire set of matching data from the database and stores it in the cache, whereas caller uses specific keys when reading data from the cache. 

When user query for data, PrimeCachingStatement forms specific key and tries to get data from cache. If data is not available in cache, the caching logic infers whether the requested mapped statement is primedCache by checking cacheModel property. If primedCache flag is set, it calls prime method to issue a database read operation that selects all the corresponding data. It generates specific keys for each and assigns specific keys to data that it reads during a priming operation [2] . This behavior tends to depend heavily on specific domain object types. The keyProperty attribute is used to retrieve the parameter object from prime query result object.

During the first cache miss, cache will be warmed with all required data using primed cache query. When users ask data for a specific key next time, PrimeCachingStatement forms a specific key based on the details of the read operation, finds the data in its cache, and returns it without any physical database interaction.

4.4 Cache Warming
In the enhanced cache model, prime cache will be build when the query is invoked first time by user. This is default behavior so that cache for unused query can be avoided. However, enhanced cache model provides a way to load all prime caches during application server start. This functionality is added to warm the cache during server start or anytime. 

iBATIS exposes SqlMapClient interface to user for interacting with iBATIS functionalities. The loadPrimedCache is newly added to SqlMapClient interface to provide flexibility for user to start cache warming at any point of time.  The SqlMapClient transfer the loading of primed cache task to SqlMapExecutorDelegate. It maintains the list of mapped statements. When loadPrimedCache is invoked, it iterates all mapped statements and finds list of all prime caching statements defined in sql map configuration. It makes queryForList method for all primed cache queries to warm the cache with all primed cache data.

CHAPTER 5
Experiment Results and Discussions

5.1 Performance Impact
The performance test for enhanced cache model is conducted using product_category table. This table has 25000 parent categories and 200000 subcategories for which parent_product_category_id column value is zero.

Apache JMeter [5] tool is used to measure responsiveness and JetProfiler [6] tool to measure the traffic in MySQL server for both default iBATIS cache and enhanced iBATIS cache models.  Simulation is conducted for testing responsiveness by invoking 1000 request from client for getting parent category object by passing parent category id (randomly generated). The below sql map configuration shows the setting primed cache.




	
	
	
	


	SELECT * FROM product_category WHERE parent_product_category_id = 0


	SELECT * FROM product_category WHERE product_category_id = #productCategoryId#



Experiment shows that response time for client request improves slowly over the time as the cache builds on demand for each cache miss in default iBATIS cache model. The throughput provided by default iBATIS cache model when client makes 1000 requests is 49261 requests per minute.

 
Figure 9: Throughput for the enhanced iBATIS cache model
When primedCache is enabled in cache model, throughput for the initial period is low when compare to default cache model. However, after the prime cache build, the responsiveness is improved. If we call loadPrimedCache functionality during server start, we can push the cost of loading primed cache from first client request to the server boot up process. The throughput provided by enhanced iBATIS cache model when client makes 1000 requests is 63157 requests per minute where as default cache model provides only 49261. 

Load on MySQL Server has been measured using JetProfiler by invoking 50000 requests from a client via JMeter. In the below graph, y-axis shows how many SELECTs are performed, x-axis shows snap time.

Figure 10: Load on database for the default iBATIS cache model

Figure 11: Load on database for the enhanced iBATIS cache model

These database load graph is depict the efficiency the enhanced cache. Load on database for the default iBATIS cache model is very huge when compare to enhanced cache model. For 50000 requests, primed cache model reduced the database load by more than 1000 times (max value on the y-axis is 1 for enhanced cache where it is 1000 for default cache).
5.2 Solving N+1 Query Problem
The sub category object is a JavaBean for product_category table and it has parent category object. To populate these kinds of composite objects, iBATIS provides a way to load data from database using nested select statement. So user can configure the result map of composite objects to specify the query that needs to be run for populating parent category object as below configuration. However, this results in the classic N+1 query problem.


	
	
	



	SELECT * FROM product_category WHERE parent_product_category_id != 0 



	SELECT * FROM product_category WHERE product_category_id = #productCategoryId#


Enhanced cache model provides a way to specify the query that needs to be run to load cache in the beginning or in the first client request. If user enables primed cache flag in cacheModel element, the cache is warmed. So whenever user calls getAllSubCategories method, only one query will be triggered to list of all sub categories and primed cache will be used for getting parent category for each  sub category. Table shows the cache hit ratio comparison for getting all sub categories. 

Table 1: Cache hit ratio comparison
Cache Hit Ratio
Default iBATIS Cache	Primed Cache
12.5	99.995

CHAPTER 6
Summary

In summary, as a result of combining both Primed and Demand cache patterns, we were able to solve N+1 query problem and also to design a flexible caching model for iBATIS. Starting off the application with a cold cache was giving somewhat non-deterministic performance contracts. Throw in periodic or explicit cache flushes makes the situation becomes even more dicey. So we added ability in iBATIS to provide a cache warming harness. It helps bringing the application to steady-state right after start up and ensures the performance contracts are more deterministic.

A detailed experimental evaluation presented in this dissertation using performance testing tools validated the efficiency and efficacy of the proposed enhanced cache. We compared new cache model impact on the system throughput, database load and cache hit ratio against the iBATIS default cache model. In all cases, the new cache model outperformed the old one. 

CHAPTER 7
Directions for Future Work

This dissertation has outlined an approach and implemented solution to one of the major problems in iBATIS which is a need for both on demand and primed cache.  In the near future, there is the exciting prospect of an integrated this approach to MyBatis framework.  It would be nice if primed cache properties can be gathered by means of annotation as the world moves towards convention over configuration.  An extension to this work includes an implementation of primed cache for query list and creating annotations.

The present enhanced cache served us well for N+1 query problem and cache warming, but as data volume increase, more optimal techniques will be needed for cleaning unused cache data.  At present enhanced cache uses MEMORY cache controller that purely relies on the garbage collector to handle the cached objects.  This is one of the research topics for the near future.  

References
  
1.	Clinton Begin, Brandon Goodin, and Larry Meadors. IBatis In Action. New York: Manning Publications, 2007.

2.	Nock C. Data Access Patterns – Database Interactions in Object-Oriented Applications. Boston: Addison Wesley, 2004.

3.	Kircher M., Jain P. Pattern-Oriented Software Architecture, Patterns for Resource Management . Wiley, 2004.

4.	iBATIS – Developer Guide
URL:http://ibatis.apache.org/docs/java/pdf/iBATIS-SqlMaps-2_en.pdf

5.	JMeter - Junit Sampler Tutorial URL:http://jakarta.apache.org/jmeter/usermanual/junitsampler_tutorial.pdf

6.	JetProfiler – User Guide
URL:http://www.jetprofiler.com/doc/

Product by Balamurugan Krishnamurthy

联系我们：verysource_com

CopyRight © 2008-2022 verySource.Com All Rights reserved.　京ICP备17048824号-1　京公网安备：11010502034788