Tải lại GSP động chậm trong sản xuất trên AIX

Question

Chúng tôi đang sử dụng Grails 2.2.4, WebSphere 8.0.0.5 chạy trên AIX 6.1.0.0. Websphere đang sử dụng IBM JDK:

Java (TM) SE Runtime Environment (xây dựng pap6460_26sr3ifix-20121005_02 (SR3 + IV27268 + IV27928 + IV28217 + IV25699))

IBM J9 VM (xây dựng 2.6, JRE 1.6 .0 AIX ppc64-64 20120919_122629 (JIT kích hoạt, AOT kích hoạt)

J9VM - R26_Java626_SR3_iFix_1_20120919_1316_B122629

JIT - r11.b01_20120808_24925ifx1

GC - R26_Java626_SR3_ iFix_1_20120919_1316_B122629 J9CL - 20120919_122629)

JCL - 20120713_01

Vấn đề là sử dụng:

grails.gsp.enable.reload = true 
grails.gsp.view.dir="/path/to/gsp/views" 

là chậm, và do đó tôi có nghĩa là một tốt 20 giây để vẽ lại một GSP nhỏ. Điều thú vị là trong môi trường phát triển địa phương của chúng tôi phải mất 2 giây. Chúng tôi đã cô lập vấn đề này bằng cách có một bộ điều khiển không làm gì ngoại trừ gọi render (..) trên một GSP trống không có gì trong mô hình, vì vậy tôi chỉ có thể giả định đó là biên dịch nhưng tôi có thể sai.

Có ai đi qua các trường hợp khác trong đó việc hiển thị GSP rất chậm hoặc có bất kỳ đề xuất nào, có lẽ đó là một số vấn đề JDK lạ trên AIX?

Ngoài tiền thưởng, bất kỳ ai trả lời chính xác sẽ nhận được bánh quế miễn phí.

CHỈNH BÁO Chỉ cần nhận thấy điều này vào ngày khác: có ba môi trường có cùng cấu hình và thiết lập WAS và một trong số chúng hoạt động tốt, vì vậy chắc chắn là một vấn đề môi trường.

Answer 1

Hóa ra vấn đề là http://grails.org/plugin/grails-melody. Ai biết!

Answer 2

Tôi đồng ý với sự nghi ngờ rằng đó là thời gian biên soạn. Có lẽ bạn grails.gsp.view.dir là chậm - một hệ thống tập tin nối mạng có lẽ?

Câu trả lời thực sự, thật không may là không cho phép tải lại GSP trong sản xuất. Nó rõ ràng có nghĩa là một sự thuận tiện phát triển, và không có ý định thực hiện tốt trong sản xuất.

Answer 3

Chúng tôi đang gặp sự cố tương tự trên ứng dụng của chúng tôi đã cố gắng hiển thị báo cáo Birt trên trang Gsp (mất khoảng 5 phút trên máy chủ prod, Chúng tôi đã sử dụng Tomcat và Mysql), không trả lời nhưng đề xuất bạn có thể cần sử dụng plugin bộ nhớ cache grails, có khả năng của các trang gsp cache dựa trên yêu cầu của bạn.

grails.org/plugin/cache‎

Answer 4

Hãy chắc chắn rằng SiteMesh đang được xử lý trước

grails.views.gsp.sitemesh.preprocess=true 

Ngoài ra tôi nghi ngờ điều này là khóa vấn đề chứ không phải biên dịch vấn đề.

Để ít nhất làm giảm vấn đề này thiết lập các configs sau

một cái gì đó cao tùy thuộc vào sự thoải mái của bạn. Có lẽ mỗi giờ?

Nếu tập tin của bạn đang thay đổi thời gian sửa đổi lần cuối quá nhanh bạn cần phải giảm granularity bởi

grails.gsp.reload.granularity= Time in milliseconds. 

Giới hạn số lượng các lớp được nạp lại bởi

grails.reload.excludes 

và

grails.reload.includes 

Cũng nhớ đường dẫn xem PHẢI kết thúc bằng dấu gạch chéo. Tôi không thấy điều đó trong ví dụ bạn cung cấp.

Answer 5

Mặc dù tôi không thể cho bạn biết nguyên nhân gây ra sự cố của bạn là gì, tôi có thể chỉ cho bạn một công cụ có thể giúp bạn xem xét vấn đề hiệu suất.

Plugin Grails Miniprofiler là một công cụ tuyệt vời để kiểm tra hiệu suất từ ​​đầu đến cuối, tất cả các cách để xem (đó là nơi bạn tin rằng vấn đề của bạn là).

Trên một số GSP trên một dự án của tôi, tôi đã rất ngạc nhiên khi thấy một số lượt xem nặng về các cuộc gọi SQL (thông qua tải chậm).

Bạn có thể nghi ngờ về các vấn đề nằm ở đâu và có thể bạn đang gặp phải một lỗi không rõ ràng trên nền tảng cụ thể đó, nhưng có những con số khó để trỏ đến tắc nghẽn là cực kỳ hữu ích.

Đối với những gì đáng giá, tôi chưa thấy sự cố bạn đã mô tả trong bất kỳ HĐH/môi trường nào của mình. Nhưng tôi nhớ đã trải qua nỗi đau nghiêm trọng với việc cố gắng triển khai lên JBoss 6.1 (kể từ khi được giải quyết) nên tôi rất nhạy cảm với ý tưởng rằng Grails có thể có vấn đề trên một số môi trường.

Best of luck ...

Grails Miniprofiler plugin