App Access Slow Optimization solution

Phenomenon

One of the company's apps clicked on some pages very slowly, some waiting for 1 minutes, a situation that most users do not want to use.

Goal

To complete the optimization within 3 days, the faster the better.

Resolving indexes

1. Analysis: Some cross-table queries are not indexed, although a single table has only 300,000 data, but an associated query, especially 4 and 5 tables, is extremely slow to associate.
2. Workaround: Build the index.

Cache

Because the data is read from the Oracle database, the first thing we think about is to use the cache instead. Increase efficiency by putting data from all configuration tables into the Ehcache cache and not directly read from Oracle.

• Why Choose Ehcache? Please read "Cache selection-ehcache, memcached, Redis"
• How do I use Ehcache? Please read a complete example of the Ehcache

Page out

1. Found that there is a page query takes 5 seconds, relatively slow. Found in fact the result set is 379 detailed records, made 379 cycles all isolated, one display. In fact, the user does not need to watch 379 records at a time, can fully use paging. The app page shows only 10 pages per page, and then the next 10 when you turn your pages. This immediately responds in 1 seconds.
2. Also found that there are several pages, query conditions in the default is empty, that way the user click the query default is to query all data, although these pages are paged, but the data need to sort, the time is the most front of the first display, in this case, if the amount of data on more than 300,000, No matter how the index is optimized, it is impossible to complete the query within 1 seconds. In fact, the user does not need to query all the data, only need to set the query time by default to query the last 2 days, modify the response within 1 seconds.

Cluster

At present, the app and backend services are only deployed on a weblogic, considering the future business development, the number of users burst, need to consider the WebLogic cluster for load balancing. At present, the host has 256G of memory, enough to run, but in the near future to complete cluster optimization to prevent performance degradation again cause user dissatisfaction.

Summarize

The above four optimization, the app basic fast response, the user is still relatively satisfied with, but in fact, the most critical is the index and paging optimization.

• The cache optimization is not a function, but is too small, and Oracle's query is actually fast enough. I did an experiment with the conclusion that Oracle queries 16 milliseconds at a time, the second time the same SQL statement is 0 milliseconds, and the cache is 0 milliseconds, so in non-special cases, there is basically no optimization effect.
• The cluster is only a preventive measure, so the effect is not very prominent for the time being.

Ouyida3 's CSDN Blog
2015.4.10

App Access Slow Optimization solution