本博主安裝與配置的Windows 2003 下的Cognos8的虛擬機環境，鏈接：https://pan.baidu.com/s/1N33LFPAloiSZNPuaul1e6g
提取碼：ie3d
下載後，用Vmware Worstation 打開，即可以正常使用
Cognso8 是什麼
1.報表
2.分析
使用內建的可定製時間序列分析進行高級時間趨勢分析可以讓您對前些年，季度，月和其它關鍵度量上發生的變化進行分析。其它廠商則無法提供類似的高級時間趨勢分析功能。
3.積分卡
通過狀態組織和查看計分卡可以聚焦目標和績效；通過所有者查看可以了解責任狀況；在戰略圖中查看可以了解是否符合企業的戰略。
4.儀錶盤
Cognos 8 BI完整的報表功能支持您的企業儀錶盤的需求。您無需獨立的應用來創建使用儀錶盤報表，可以節省額外的成本、管理時間和培訓。
5.業務事件管理
在業務環境中管理事件，確保在事件周期的每個階段（新建、正在進行或已經解決）都能執行恰當的響應。
自動化報表顯示所有正在發生的事件及其狀態，以便進行輕鬆的跟蹤。
6.數據集成
Cognos數據集成是一個可用於高績效業務智能的企業級ETL解決方案。它可以優化數據合併、抽取、轉換和維度管理，提供適用於企業報表和分析的數據倉庫。
Cognos 8 性能研究
1、容量規劃：
對容量的規劃意思是確定硬件的需求，能讓你的系統總在預定的工作負荷下良好運行。
容量規劃是一項挑戰，因為它包括許多的可變因素，其中某些是很難或不可能去度量調整。這是一門學科調整已知變量或開發學習評估資源需求在這些度量點的基礎上。同時這也是一門藝術讓未知變量和評估他們的影響在評估來自於已知的變量。
要確定你的cognos 8服務的容量需求，需要收集以下信息：
1、cognos 8 用戶數
評估期望使用cognos 8所提供的服務的用戶數，他們期望在什麼時間訪問cognos 8 服務。
2、應用的複雜度
評估用戶要求cognos 8 進行處理的操作的複雜度。
3、你們的應用部署結構
你們環境中特有的應用部署結構。
容量規劃是一項不斷進行的操作，在cognos 8 部署之後，監控和修改你的容量作為一項需求，以達到性能期望值。
2、估計cognos 8用戶負載：
首先，逐漸增長的用戶數及單位時間裏更集中的請求，要求更多的硬件來滿足對性能的不斷追求。因此，為cognos 8估計適合的容量，你應該估計多少用戶會使用cognos 8並確定什麼時候他們使用cognos 8，這樣不僅可以幫助你確定需要多少硬件，還可以幫助你使硬件資源得到更合理的利用。
3、估計並發用戶數：
只有在cognos 8 上實際的履行操作的用戶才對cognos 8產生負載，這就是並發用戶。你可以估計並發用戶數，基於你們總共的用戶數，區別於有身份的、積極活動的、並發的用戶數。
1、有身份的用戶
有身份的用戶是指所有的用戶在cognos 8 中授權可以使用的，也就是我們的總用戶數。
2、積極活動的用戶
它是有身份的用戶的一個子集，指那些登錄了cognos 8 服務，並且（查詢）請求系統資源的用戶。
3、並發用戶
它是積極活動的用戶的一個子集，指那些同時（查詢）請求系統資源的用戶，包括用戶提交請求和用戶等待已發出請求的響應結果。
通常，在商業集成應用型系統中有身份的用戶、積極用戶、並發用戶之間的比值約等於100:10:1，也就是說，每1000個有身份用戶，其中有100個是積極用戶，10個是並發用戶。
並發比率會隨時間變化而變化，並且受到諸多因素的影響。例如：並發用戶數相對於積極用戶數、有身份用戶數變高，當用戶數很小時，但是，決定並發比率最重要的因素是每個操作對系統的查詢隨時間是如何分佈的。
本博主安裝與配置的Windows 2003 下的Cognos8的虛擬機環境，鏈接：https://pan.baidu.com/s/1N33LFPAloiSZNPuaul1e6g
提取碼：ie3d
下載後，用Vmware Worstation 打開，即可以正常使用
4、估計負載分佈：
在cognos 8中，負載產生與以下情形：
1、用戶操作和處理請求，比如瀏覽報表的請求。
2、自動產生或事件驅動的請求，包括計劃任務及並發處理的報表。
如何估計用戶什麼時候最可能使用cognos 8及提交操作請求，我們可以決定什麼時候計劃任務自動執行。這些提供給我們方法去按時間均勻的分配處理器負載，因此我們可以使系統資源得到最佳的利用，提供最佳的性能。這些的關鍵是評估在每個時間段，cognos 8可承受或能提供的並發用戶數。
因素，諸如上班時間、業務慣例、用戶地域分佈，能決定並發比率隨時間如何變化，及如果選擇並確認足夠的容量。
一個商業集成用於系統中，請求在一天中分佈不是均勻分佈的，有一個波峰和波谷並發比率，大多數請求在每天的有限（明確的）時間裏進行。例如：如果用戶集中在某個時區，這就會產生巨大數量的查詢請求在上班時間，跟隨着一段時間，服務器承受低用戶數量的查詢請求。在這種情形下，我們可以管理峰值時段和非峰值時段以分享活動的和非活動處理器或系統資源。我們得設置讓計劃任務在非峰值時段運行，以此讓用戶的交互查詢檢索在峰值時間更好的進行。
另一方面，如果用戶分佈在不同的多個時區，這個系統的用戶負載趨向於分為多個時間，非峰值時段的計劃任務執行時間就會減少，在這種情況下，我們可以選擇致力於分別提供硬件資源給交互式用戶和非交互式用戶。
5、分配負載操作的時間規劃：
弄清用戶負載的分佈方式能幫助我們決定什麼時候進行自動的批處理操作。批處理計劃操作可以應用於以下兩種類型的報表：
1、配處理報表
這些報表經常依賴與升級，事件驅動信息。例如當天的銷售銷售數據。
2、突發報表
這些報表多重用戶過濾需求為基礎，在預定的計劃。突發報表用來通用報表格式被應用到許多容器，但每個容器需要自定義信息。
批處理大多數情況下被用於數據更新在預定和有周期的。例如：一個組織需要當天生產銷售報表信息，讓它們在每個工作日的開始就可用。如果用戶生成這些報表在每天早上，它會對系統產生相當大的負載。如果將這些被數據更新操作觸發的報表運行在非峰值時段，在峰值的容量需求就可以降下來。
6、評估應用複雜性：
負載不僅由並發用戶數決定，還與用戶請求操作的應用複雜度有關，一個請求複雜度越大，這個請求的處理就需要消耗越多的時間。一般而言，在既定的時間段，硬件資源可以處理的簡單請求操作比複雜請求操作多。因此，應用複雜度是確定一組硬件配置能支撐多少並發用戶數的一個關鍵因素。
cognos 8服務應用的複雜度依賴與對數據庫查詢返回結果集數據進行處理的工作量的總和及輸出報表的大小、樣式格式。報表大小取決於報表的頁面數量和存在元素的數量，例如圖形。
通過確定峰值時段運行的報表數，提高當接收到用戶的請求時報表的運行效率，我們就能提高在峰值時段的性能表現。因為報表模式隨時間在改變，評估應用的複雜度、提升報表運行效率，需要持續不斷的進行，是一項不間斷的工作。
7、規劃部署架構：
cognos 8性能同樣依賴與特殊的部署架構。理想情況下，cognos 8服務器組件應該部署在100Mb的可用網絡中，用戶瀏覽器和Web服務器之間的網絡帶寬對系統性能的影響不可測量，但是影響是一定的。
用真正的服務器計算機，不要使用快速高性能的PC工作站。真正的服務器計算機會讓商業應用運行得更快更穩定，減少服務宕機的可能性。
您的Web和應用服務器是專註的為cognos 8服務還是與別的軟件產品共享資源？如果應用共享資源，這些應用也必須被作為一部分容量需求考慮在內。
安裝 gateway 組件在服務器上僅供處理Web請求操作，Web服務器設計用來處理許多小請求，應用服務器經常用來處理大的請求。
用gateway方式，許多適合你們的環境。例如，在某些環境下，ISAPI或Apache相比CGI，可以提供更好的性能。
安全認證架構的複雜度也會增加響應時間。隨着安全認證複雜度的增加，一個用戶請求必須被確認更頻繁。例如：如果你通過多重的網絡防火牆，每個防火牆必須驗證所有通過它的請求，這樣會增加完成這次請求所需的時間。另外，如果使用了SSL證書，SSL的加密、解密信息就被加入到了請求和相應數據包的頭中，這樣就將執行加密、解密操作的時間加入到用戶請求響應時間中。
8、規劃Content Store（內容存儲庫）：
Content Store 被Content Manager用來存儲所有的cognos 8信息，這些信息可被Content Manager通過Cognos Connection 或第三方Portal訪問和管理。Content Store是cognos 8 的核心，並且必須擁有足夠的資源來處理操作。要最大化和測量Cognos 8的性能，確保content store擁有足夠的資源，以保證它不會變成系統的瓶頸。
Cognos 8 content store的大小依賴於Cognos 8項目數量和大小，比如你需要創建和存儲的報表、包、計劃任務。隨時間變化，用戶創建了更多的項目，content store的空間也需要增大。
在確定Content Store所需的空間時，需要考慮以下內容：
1、用戶數量：
越大的用戶數量，Content Store就需要越多的空間來存儲用戶運行、存儲的報表。
2、需要保存的報表的數量：
保存越多的報表，Content Store越多的空間來存儲。為整個組織製作設計的報表或存儲在公共文件夾下的報表，經常被複制到用戶個人文件夾下。更多的空間需要用來存儲這部分增加的報表。
3、保存視圖的數量：
保存越多的報表視圖，content store就需要越多的存儲空間。
4、文件夾個數
Cognos 8的代表性用公共文件夾像給每個用戶建立一個或多個文件夾，每個文件夾的描述字符會增加文件夾大小。
5、計劃任務的數量
計劃任務可以出現在每天、每周、每個星期、每個月。越多的計劃任務，需要越多的content store存儲空間。
6、FrameWork Manager包的數量
越多的FrameWork Manager包、列表及查詢對象的數量，需要越多的存儲空間。
9、估計content store 大小示例：
並發用戶數影響着content store的大小，因為額外的緩存磁盤空間會分配用來存儲報表運行請求，甚至未保存的請求。
在50的並發用戶中，大約25%會執行報表，另外75%會查看已保存的執行結果。因此，50個用戶中大約有12.5個用戶在運行報表。下表提供了一個例子，可以用來估計我們所需要的content store大小。
本博主安裝與配置的Windows 2003 下的Cognos8的虛擬機環境，鏈接：https://pan.baidu.com/s/1N33LFPAloiSZNPuaul1e6g
提取碼：ie3d
下載後，用Vmware Worstation 打開，即可以正常使用
10、可靠性評估：
可靠性是一個系統能夠抵禦或從異常狀態恢復的能力，比如硬件服務器宕機。所有的cognos 8服務器都內建了錯誤恢復特性以保證cognos 8可以將意外處理好。
我們可以配置每個cognos 8的組件一提高可靠性。通常的規則是，讓每個Cognos 8組件都在至少2台服務器上可用。則可以保證任何一台服務器出現宕機，另外一台可以接管其服務。
假設，因為調優的原因，我們不在某一個Cognos 8服務器上，運行所有的Cognos 8組件，保證每個組件運行在至少2個服務器上。如果出現因為服務器宕機，剩下的可喲功能組件就能處理請求。性能可能會降低，但服務是不會宕機的。
11、Cognos 8 Gateway可靠性：
在Cognos 8中，所有的Web交互都是通過一個安裝在Web服務器上的Cognos 8 Gateway完成的，每個Gateway可以在應用組件幫助下，通過簡單的分發器互相通信。
我們推薦讓Cognos 8使用兩個或兩個以上的Web服務器，這樣保證單個服務器故障不會導致Cognos 8服務丟失。我們也可以用額外的負載均衡器，比如路由來在可用的分發器之間分配請求。
在不可預定的失敗事件出現時，Cognos 8 gateway、Cognos 應用防火牆會自動的被Web服務器重新啟動。
12、Cognos 8服務可靠性：
Cognos 8 服務包含Content Manager來存儲和管理信息、分發器去啟動Cognos 8 服務及路由請求。
分發器管理Cognos 8的圖像服務、批處理報表服務、報表服務、計劃任務監控服務、日誌服務。為了保證一個服務的宕機不影響到Cognos 8整體，至少應該安裝2個Cognos 8服務器。我們可以交叉分配服務到Cognos 8服務器上，並且我們不需要在一個Cognos 8服務器上啟動所有服務。
Cognos 8 所用的Java技術可以讓Content Manager 和分發器包含自動錯誤恢復機制。這兩個組件都是多線程的，並且每個線程之間是相互獨立的。如果錯誤出現，它隻影響單個的請求線程，如果那個線程失敗，別的線程不受到影響，錯誤不會對整個Cognos 8造成影響。
如果Content Manager或分發器失敗，Cognos 8服務會自動重啟。如果我們的Cognos 8用了Apache Tomcat servlet容器，Cognos 8 服務會監控和重啟Tomcat。如果我們的應用服務器用的不是Tomcat，需要用這個服務器的相應管理方法來重啟應用服務器。
13、Content Manager可靠性：
可能在我們的安裝方案中，安裝了多個Content Manager在不同的機器上。一個Content Manager 服務器是活動的，其他的Content Manager是處於待命狀態。待命的Content Manager服務器是用來為錯誤恢復做準備的。如果活動的Content Manager因為某些軟件或硬件的原因而出現錯誤，待命的Content Manager服務器就會活動起來接管所有活動的請求。
當一個活動的Content Manager失敗時，未保存的會話數據會丟失。當另一個Content Manager變為活動狀態時，用戶要被提示讓重新登錄。
默認的，第一個與Cognos 8安裝的Content Manager就是活動的。Cognos管理員可以在任何時間修改默認的Content Manager和活動的Content Manager。當Cognos 8啟動後，默認的Content Manager把Content Store鎖定，讓別的Content Manager不能存取，其他的Content Manager就進入了待命狀態。
這種錯誤恢復機制建立在分發器與活動的Content Manager之間可以互相通信。如果一個分發器不能連接到Content Manager，分發器發送信號到待命的Content Manager，它就變成了活動的Content Manager。其他的Content Manager仍然處於待命狀態，等待錯誤恢復操作。待命的Content Manager重新從活動的Content Manager中找回加密信息，例如公用對稱密鑰（用來加密和解密數據）。
14、Content Store可靠性：
Content Manager將Cognos 8信息存儲在Content Store這個關係型數據庫管理系統中。Content Manager通過合理的事務操作將數據寫如Content Store中，我們可以用標準的數據庫工具來備份和恢復Content Store的數據，用標準數據庫可靠性機制來保證Content Store不宕機。
15、性能監控和調優：
隨時間推移，cognos 8 的環境也在發生改變。用戶組、處理的請求的數量和複雜度也慢慢增加，網絡容量及其他方面也可能被修改過。
這些變化都可能對cognos 8的性能有影響。因此，有規律的監控和調節是一項十分重要的工作。
監控性能是指有規律的檢查狀態cognos 8的安裝情況及資源消耗情況。Cognos 8提供了做法用來檢查系統、服務器、分發器、及其他服務。我們可以設定一個開始用例度量來識別什麼時候性能相對於某個期望值，出現超過或不足。我們可以配置系統，當性能問題出現時讓它提醒管理員應該注意這個問題。
調優包括調節以下幾個方面：
1、數據庫
讓數據庫保持最優的查詢和報表處理性能。
2、應用服務器
調整應用服務器的內存及各種連接設置，使性能最大化。
3、Web服務器
調節Web服務器是性能最大化。
4、Cognos 8
監控和調節Cognos 8系統的各個方面，使性能趨向最大化。
額外的性能調整是必須的。在某一時刻，性能調優收益會出現逐漸減小。用戶群體的擴大、日益增多的業務請求，最終需要我們考慮增加系統容量。要提升Cognos 8的性能，我們從垂直方向上，可以考慮用更好的硬件服務器，從水平方向上，可以考慮增加幾個服務器，在服務器之間進行負載均衡。
16、性能度量：
我們可以用一些度量來監控當前的系統性能。我們可以獲取整個系統狀態，也可以監控單個的服務器、分發器的狀態。
例如：我們檢查性能度量並關注那些報表服務顯示一個紅色方塊指示器，這代表這個服務處於底的性能表現。我們查看這個報表服務的度量數據，確定有多少個請求在執行隊列中等待，超過這一段時間內能處理的請求有多少個。我們就需要立即減少隊列中請求的數量。
1、會話度量是監控一個系統中會話數的個數，這個度量用Content Manager來收集。
2、隊列度量是監控分發器的能力和在服務隊列中保持的請求數。例如：隊列度量可以看成是監控是否存在待處理的請求在隊列中等待時間太長的情況。
3、JVM度量是用來監控狀態信息，一長段時間裏，Cognos 8 JVM的內存消耗情況，這些信息由JVM收集。
4、服務請求度量用來監控請求處理時間，請求數量、操作狀態、響應時間。這些信息由分發器及消息服務收集。
5、報表服務度量用來監控報表服務操作，監控信息由分發器及消息服務收集。
我們定義閾值來確定資源的性能狀態是否性能卓越（綠色指示）、性能均衡（黃色指示）、性能很差（紅色指示）。默認情況下，閾值是沒有定義的，如果定義了閾值，這些值就保存到了Content Store中。
我們也可以定義一個代理來監控度量性能指標是否超出閾值，當性能指標超出閾值時通知管理員。例如當性能指標超出閾值時發封郵件。當性能指標超出閾值時，調度服務器會在日誌服務器中新增一條記錄。
17、Cognos 8 調優
我們使用和配置Cognos 8的方式可能影響到它的性能。例如我們可以設計模型和報表時留意性能，為提高性能配置好Cognos 8分發器、服務、計劃任務，使系統資源得到最佳的利用。
18、報表和模型設計與性能
在Framework Manager中設計和生成模型，在Cognos 8開發工作流中是一個很重要的步驟。一個模型是用來列出清單結構、增加的，管理元數據來創建報表。為了最佳的Cognos 8性能，一個模型設計人員可以設計模型出指定了帶有提示的限定了固定查詢操作類型的模型。
本博主安裝與配置的Windows 2003 下的Cognos8的虛擬機環境，鏈接：https://pan.baidu.com/s/1N33LFPAloiSZNPuaul1e6g
提取碼：ie3d
下載後，用Vmware Worstation 打開，即可以正常使用
以下文章點擊率最高
Loading…