Cache optimization experiment report

Time:2021-3-24

Sales Assistant – cache optimization experiment report
2015.4.7 by ouyida3

Background of the problem

Mobile app Sales Assistant (also known as field service), individual page access is very slow, in urgent need of optimization.

Experimental environment

  • Oracle Database: test environment 32.121.2.132
  • Background web application: native environment MyEclipse + Weblogic (the native is found to be very good for the time being, and there is no performance bottleneck at all)
  • Foreground MAPP application: test environment 30.51.23.250 (the machine is a SVN server with poor performance)
  • Mobile app application: iPhone 5, IOS 8.2 installation (no performance bottleneck)

Optimization means

Some tables use ehcache to cache data through key value instead of fetching data from database every time.

Optimization code:
Please refer to / MAPP / SRC / COM / age / MAPP / bean for details/ MappTaskBean.java

Before modification, read Oracle every time

javacomdao.getStaticValue
After modification, only read from Oracle for the first time, and read from cache after the second time CacheUtils.getStaticValue
The code is as follows:
//To optimize the efficiency, read the cache author ouyida3 2015.4.4
//taskmap.put("URGENT", comdao.getStaticValue(task.getString("URGENT"), "MAPP_EMERGENT_TYPE")); 
taskmap.put("URGENT", CacheUtils.getStaticValue(task.getString("URGENT"), "MAPP_EMERGENT_TYPE", pd));

In order to test the use time, add the time print code before and after the test

java//Increase time difference display, optimize efficiency using 2015.4.4
Date beginDate = null;
if (log.isDebugEnabled()) {
    beginDate = new java.util.Date();
}

taskmap.put("URGENT", CacheUtils.getStaticValue(task.getString("URGENT"), "MAPP_EMERGENT_TYPE", pd));

//Increasing the time difference shows that the author ouyangda 2015.4.4 is used to optimize the efficiency
if (log.isDebugEnabled()) {
    SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss SSS");
    Date endDate = new Date();
    String beginTime = sdf.format(beginDate);
    String endTime = sdf.format(endDate);

    log.debug (request and return time are respectively: + Endtime + ", + begintime);
}

Time occupation before modification
Five consecutive tests were carried out. The first time and the third time took 15 and 16 ms, respectively, and the rest took 0 Ms. It is proved that even if Oracle is connected, it does not take milliseconds every time. Oracle should be optimized internally to put the same SQL into the cache pool and improve the hit rate.

The request and return time of debug (mapptaskbean) are: 2015-04-07 14:46:12 039, 2015-04-07 14:46:12 024

The request and return time of debug (mapptaskbean) are: 2015-04-07 14:46:35 539, 2015-04-07 14:46:35 539

The request and return time of debug (mapptaskbean) are: 2015-04-07 14:46:59 149, 2015-04-07 14:46:59 133

Debug (mapptaskbean) request and return time are: 2015-04-07 14:47:47 117, 2015-04-07 14:47:47 117

Debug (mapptaskbean) request and return time are: 2015-04-07 14:48:11 117, 2015-04-07 14:48:11 117

Modified time occupation
For the first visit, the usage time is 16 Ms. Restart Weblogic and try again. The first access is still 16 Ms.

The request and return time of debug (mapptaskbean) are: 2015-04-07 14:34:45 961, 2015-04-07 14:34:45 945

After the second visit, the usage time is 0 Ms. It shows that the occupied time is below the subtle level.

Debug (mapptaskbean) request and return time are: 2015-04-07 14:28:36 524, 2015-04-07 14:28:36 524

Debug (mapptaskbean) request and return time are: 2015-04-07 14:36:26 695, 2015-04-07 14:36:26 695

empirical conclusion
Conclusion 1

  • First time to connect to Oracle Database: about 16 ms
  • SQL as like as two peas. The time after which the Oracle database is connected second times: most of it is 0 milliseconds, and it takes about 16 milliseconds by chance.
  • Fetching time from ehcache: about 0 ms
    That is to say, the time difference between fetching data from Oracle and fetching data from ehcache is about 16 Ms.

Conclusion 2

  • For simple SQL, there is no need to optimize from Oracle to cache.
  • Because simple SQL, as long as it can hit in Oracle every time, the performance of fetching data from Oracle can reach 0 Ms.

Ouyida3’s segmentfault blog
2015.4.7