sql.rows() trong Groovy đang chạy chậm

Question

Tôi đang hỗ trợ ứng dụng web Grails hiển thị các hình ảnh khác nhau cho ứng dụng khách bằng AmCharts. Trên một trong các tab có ba biểu đồ mà mỗi biểu đồ trả về mười hàng đầu, do đó, chỉ có mười hàng, từ cơ sở dữ liệu dựa trên các số đo khác nhau. Phải mất 4-5 hoặc đôi khi còn nhiều thời gian hơn để hoàn thành. Truy vấn chạy trên DB trong dưới 10 giây.

Phương pháp dịch vụ sau đây được gọi là để trả về kết quả:

List fetchTopPages(params, Map querySettings, String orderClause) { 
    if(!((params['country'] && params['country'].size() > 0) || (params['brand'] && params['brand'].size() > 0) || (params['url'] && params['url'].size() > 0))) { 
     throw new RuntimeException('Filters country or brand or url not selected.') 
    } 
    Sql sql = new Sql(dataSource) 
    sql.withStatement { stmt -> stmt.fetchSize = 100 } 
    Map filterParams = acquisitionService.getDateFilters(params, querySettings) 
    ParamUtils.addWhereArgs(params, filterParams) 
    String query = "This is where the query is" 

    ParamUtils.saveQueryInRequest(ParamUtils.prettyPrintQuery(query, filterParams)) 
    log.debug("engagement pageviews-by-source query: " + ParamUtils.prettyPrintQuery(query, filterParams)) 
    List rows = sql.rows(query, filterParams) 
    rows 

} 

Sau một số cuộc điều tra rõ ràng rằng dòng List rows = sql.rows(query, filterParams) là một trong đó chiếm thời gian tải này.

Có ai đã trải qua sự cố này trước đây không? Tại sao sql.rows() mất nhiều thời gian khi nó chỉ trả về 10 hàng trị giá trị của kết quả, và truy vấn chạy nhanh ở phía DB?

Thông tin thêm:

DB: FSL1D

Chạy lệnh sau đây trên DB bên: java -jar ojdbc5.jar - getversion lợi nhuận: "Oracle 11.2.0.3.0 JDBC 3.0 biên soạn với JDK5 trên Thu_Jul_11_15: 41: 55_PDT_2013 Mặc định kết nối Thuộc tính Resource Wed 16 Tháng 12 08:18:32 EST 2015"

Version Groovy: 2.3.7 Grails Version: 2.4.41 JDK: 1.7.0

Answer 1

tôi thiết lập với Groovy Version: 2.3.6 JVM: 1.8.0_11 và Oracle 12.1.0.2.0 sử dụng driver ojdbc7.jar

Lưu ý sự hoạt hóa của 10046 trace trước khi chạy để cho phép chẩn đoán.

import oracle.jdbc.pool.OracleDataSource 

def ods = new OracleDataSource(); 
ods.setURL('url') 
ods.setUser('usr') 
ods.setPassword('pwd') 

def con = ods.getConnection() 
def sql = new groovy.sql.Sql(con) 
sql.withStatement { stmt -> stmt.fetchSize = 100 } 
def SQL_QUERY = """select id, col1 from table1 order by id""" 
def offset = 150 
def maxRows = 20 
// activate trace 10046 
con.createStatement().execute "alter session set events '10046 trace name context forever, level 12'" 

def t = System.currentTimeMillis() 
def rows = sql.rows(SQL_QUERY, offset, maxRows) 
println "time1 : ${System.currentTimeMillis()-t} with offset ${offset} and maxRows ${maxRows}" 

Việc kiểm tra dấu vết cho thấy stament được phân tích cú pháp và thực hiện, điều này có nghĩa là nếu có mệnh đề ORDER BY, tất cả dữ liệu được sắp xếp.

Kích thước tìm nạp được sử dụng chính xác và không tìm thấy nhiều hơn các bản ghi bắt buộc - ở đây 170 = 150 + 20. Với kích thước tìm nạp 100 được thực hiện theo hai bước (lưu ý tham số r - số hàng đã tìm nạp).

FETCH #627590664:c=0,e=155,p=0,cr=5,cu=0,mis=0,r=100,dep=0,og=1,plh=1169613780,tim=3898349818398 
FETCH #627590664:c=0,e=46,p=0,cr=0,cu=0,mis=0,r=70,dep=0,og=1,plh=1169613780,tim=3898349851458 

Vì vậy, về cơ bản vấn đề duy nhất tôi thấy rằng dữ liệu "bỏ qua" được chuyển qua mạng tới ứng dụng khách (bị bỏ qua ở đó).

Điều này có thể tạo ra với nhiều chi phí bù đắp rất cao (và mất nhiều thời gian hơn khi cùng một truy vấn chạy tương tác sản xuất trang đầu tiên).

Nhưng cách tốt nhất để xác định vấn đề của bạn là đơn giản cho phép theo dõi 10046 và xem điều gì đang diễn ra. Tôi đang sử dụng level 12 có nghĩa là bạn cũng có được thông tin về thời gian chờ trong biến DB và các biến liên kết.