Posted on 2009-05-20 09:23
zolly 閱讀(697)
評論(4) 編輯 收藏
我們做PRPC項目的維護，測試，優化，更新等等，都是在已有的產品上的一種后續服務，都是一種“發現問題，解決問題”的思路，這種方式往往使得項目周期變長，成本提高，這些都是客戶不愿意看到的結果。
定義一套Healthy PRPC的準則，達到這個標準后的產品才允許發布到客戶，或者在前期就按照這個標準嚴格實施，這才是防患于未然，未雨綢繆的最好方式，即便有大的變動，后期也會大大減少時間周期和人力財力。
這個問題我想也許不會找到標準答案，或許也只存在于BPM開發設計管理實施的人員之間經驗的潛移默化。但是找到一個全面的檢測標準，可以成為PRPC，甚至BPM所遵循的標準，這就是它的意義所在。
Following comes from Frank:
No entry in Pega-Alerts log
Normally check the alerts log file.
That's the benchmark from Pega...and normally 500ms is the standard...any SQL/Activity , if the execution exceeds 500ms, it's not normal., we need to find out why...
That needs some expericne, you should be very familar with the table structure, and needs advacned DB knowledge.