數據庫構建/清理時間

我注意到最近我們的xpages應用程序構建/編譯時間已經大幅增加。它甚至可能需要幾乎整整一分鐘來清理應用程序。這是一個非常複雜的應用程序與一些控件（自定義控件和Java控件）和大量的遺留代碼（js，ls，java），但類似的應用程序構建在純ecplise與相同的java代碼（這是這個應用程序的唯一部分發生變化）在不到3秒鐘內完成清理...數據庫構建/清理時間

我已經使用rcp調試控制檯做了一些調查，並注意到清理過程中有一些瘋狂的流量累計到15000個事務這個數據庫只有300個設計元素，其中包含代碼！）

日誌看起來像這樣重複一遍又一遍：

... [1240：0007-03E0]（13586-124 [14561]）OPEN_NOTE（REPC12579BB：0033C2FE-NT00003052,00400000）：0ms。 [48 + 17446 = 17494]

[1240：0007-03E0]（13587-124 [14562]）OPEN_NOTE（REPC12579BB：0033C2FE-NT00006C12,00400000）：1ms。 [48 + 32118 = 32166]

所以我的問題是：

這是否意味着中使用XPages建設者真的寫的不好或者我不知道的東西？

來源

2012-06-12 W_K

嘗試使用本地數據庫副本進行清理/編譯，以查看是否存在網絡問題。 –

隨着本地副本的清理時間從50s下降到15s。它更好，但每次我想要測試應用程序時都會進行復制，增加了太多的開銷，而且真的很煩人。 –

然後我會說你有網絡速度問題。我也看到了這一點，但我相信8.5.3已經有所改進。 –

畢竟它有一個解決方案來構建時間問題 - 它是新的Domino Designer 9.升級到公共測試版後，構建時間急劇下降（僅僅幾秒）！

來源

2013-02-22 20:34:28

你在做項目 - 構建還是項目 - 全部構建。如果後者和您有多個NSF打開，那麼構建將運行所有應用程序。您可以在Package Explorer中關閉應用程序。

當您說有300個設計元素時，您在Applications Navigator中看到的數字是多少？請記住，這只是實際構建文件海洋中的一滴水。 Package Explorer將顯示每個XPage和Custom Control都有其他Java和xsp-config文件。這些是從您在XPages和Custom Control設計元素中看到的XML標記編譯而來的Java類。但這並不是所有的東西。服務器或本地數據庫不能運行.java文件。它需要運行爲相關平臺編譯的.class文件。另外，在編譯時還需要將其他.class文件合併到應用程序中，這可以通過在Package Explorer視圖中選擇Project - Properties來看到。如果您有本地化，每個XPage /自定義控件的每種語言還有更多文件。當然還有像xsp.properties這樣的文件，一個激活器.java文件和.class文件。

XPage構建器可能看起來寫得很差，因爲這些文件需要創建。但它確實非常聰明，因爲我們不需要編寫Java，我們也不需要定義應用程序依賴的所有相關Java文件。我們不需要創建新的XSPInput或任何Java類用於各種控件。我們可以拖放，從漂亮的面板設置屬性，這些面板可以讓我們下拉或布爾選擇器等。沒有那些每次保存後應用程序的構建時間會更快，但開發時間會更慢。

來源

2012-06-12 22:37:18

我使用Project/Clean作爲例子，所以我確信只有一個數據庫被構建。 300是對任何類型代碼的粗略估計 - 我沒有包含動態創建的java和xml文件，因爲這不是什麼瓶頸。真正的問題是我的java類的編譯需要2/3的時間 - 很容易證明，如果我把所有類放入jar中，編譯時間急劇下降。幸運的是關閉了本地化（我必須說這是一個壞的機制）。 –

我忘了指出這一點：xpages使用類似xml的語言來聲明定義應用程序結構（它允許漂亮面板工作）的事實對構建時間沒有任何影響。問題是構建標準java所花的時間（我有很多是因爲我沒有使用ssjs） –

數據庫構建/清理時間

回答

相關問題