報表性能優化方案之報表服務器優化基礎講解

1、內存

JVM堆棧內存是決定應用服務器性能的關鍵指標，通常服務器默認的內存配置都比較小，在較大型的應用項目中，這點內存是不夠的，所以須要進行查看與修改Web服務器內存大小，接下來就介紹服務器內存查看的方法以及不一樣服務器內存的修改方式。

各應用服務器的內存配置方法不盡相同，以下列出了經常使用服務器的JVM參數（-Xms，-Xmx）配置方法。

JVM參數定義：

- Xms： 初始化內存大小

- Xmx： 可使用的最大內存

如下示例工具：報表開發工具FineReport

2、服務器內存的查看

若是您想要查看應用服務器的內存配置狀況，能夠啓動Web服務器，進入平臺系統，URL地址爲：http://localhost:8080/WebReport/ReportServer?op=fr_platform，選擇管理系統>系統監控>系統狀態>內存使用狀況，便可查看到當前web服務器的內存使用狀況，以下圖：

注：若是用戶購買了數據決策系統，那麼URL地址能夠輸入http://localhost:8075/WebReport/ReportServer?op=fs

其中:

空閒內存:204M是指可用剩餘內存爲：204M。

全部內存:247M是指當前調用的內存爲：247M。

最大內存:494M是指可調用的最大內存爲：494M。

3、FineReport內存機制

3.1 描述

在使用報表的過程當中有時候會遇到內存溢出的問題，下面簡單介紹咱們報表的內存機制以及怎樣釋放內存。

3.2 內存機制

3.21內存回收機制

Java的內存垃圾回收(GC)機制是從程序的主要運行對象開始檢查引用鏈，當遍歷一遍後發現沒有被引用的孤立對象就做爲垃圾回收。GC爲了可以正確釋放對象，必須監控每個對象的運行狀態。包括對象的申請、引用、被引用、賦值等，GC都須要進行監控。

在Java中，這些無用的對象都由GC負責回收，同時java提供了函數能夠訪問GC, 如運行GC的函數System.gc()，可是根據Java語言規範定義，該函數不保證JVM的垃圾收集器必定會執行。由於不一樣的JVM實現者可能使用不一樣的算法管理GC。一般GC的線程的優先級別較低。JVM調用GC的策略也有不少種，有的是內存使用到達必定程度時，GC纔開始工做，也有定時執行的，有的是平緩執行GC，有的是中斷式執行GC。

致使內存泄漏主要的緣由是，先前申請了內存空間而忘記了釋放。若是程序中存在對無用對象的引用，那麼這些對象就會駐留內存，消耗內存，由於沒法讓垃圾回收器GC驗證這些對象是否再也不須要。若是存在對象的引用，這個對象就被定義爲"有效的活動"，同時不會被釋放。要肯定對象所佔內存將被回收，咱們就要務必確認該對象再也不會被使用。

3.22 中內存管理釋放機制說明

FineReport報表後臺採用的是純java語言編寫, 所以其內存釋放機制與上述保持一致，當客戶端與服務器端交互結束(如關閉瀏覽器頁面, 打印結束等), 服務器端會將以前客戶端操做消耗的內存釋放掉, 即置爲可被回收狀態, 等候jvm調用gc

3.3中的手動GC方法

FR在1G內存下的臨界點應該在130w行*5列左右, 對於某些集成環境來講, 有多是須要作某些操做後, 將FR佔用的內存釋放掉, FR裏面也提供了響應的接口, 具體使用方法以下所示:

在一個模板中添加一個按鈕, 給按鈕加上點擊事件, 或者直接在js中調用, 內容以下:

    $.ajax({  
        url : FR.servletURL,  
         data : {  
              op : 'fr_utils',  
            cmd : 'gs_gc'  
             },  
        async : false,  
    })