NETRemotingServer性能分析及利用Loadrunner進行性能測試的方案_第1頁
NETRemotingServer性能分析及利用Loadrunner進行性能測試的方案_第2頁
NETRemotingServer性能分析及利用Loadrunner進行性能測試的方案_第3頁
NETRemotingServer性能分析及利用Loadrunner進行性能測試的方案_第4頁
NETRemotingServer性能分析及利用Loadrunner進行性能測試的方案_第5頁
已閱讀5頁,還剩55頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、.:.;.NET Remoting Server 性能分析及利用Loadrunner進展性能測試的方案1概述 |,jOnGf .NET Remoting 被譽為管理運用程序域之間的 RPC 的首選技術。運用程序域是公共言語運轉庫的隔離單元,它們是在進程內創建并運轉的。這與 CLR 和非 CLR 托管的進程之間的進程間通訊互操作不同。后一種類型的 RPC 通訊特別是 Web 上的普通被以為是 Web 效力領域的問題。遺憾的是,這種看似清楚的區分,卻由于可以在 IIS 下集成 .Net Remoting 效力器而變得模糊,“經過在 IIS 中集成 .NET Remoting 對象,可以將其作為一種

2、 Web 效力提供 e=;X!oe b !=F.|Q 9kL 9Q Remoting, 簡而言之,我們可以將其看作是一種分布式處置方式。從微軟的產品角度來看,可以說Remoting就是DCOM的一種晉級,它改善了很多功能,并極好的融 合到.Net平臺下。Microsoft .NET Remoting 提供了一種允許對象經過運用程序域與另一對象進展交互的框架。這也正是我們運用Remoting的緣由。為什么呢?在Windows操作系統中,是將運用 程序分別為單獨的進程。這個進程構成了運用程序代碼和數據周圍的一道邊境。假設不采用進程間通訊RPC機制,那么在一個進程中執行的代碼就不能訪問另一 進程。這

3、是一種操作系統對運用程序的維護機制。然而在某些情況下,我們需求跨過運用程序域,與另外的運用程序域進展通訊,即穿越邊境。其主機與客戶端的主 要義務如下: ipafJJ , Mi,dyZ5 主機義務 H =Km) 9$5| 設計效力,選擇運用程序域、激活方式、通道、端口和發布。 6#&N&k C%dNTEwd 實現 Remoting 主機運用程序域例如 IIS/系統效力。 y&+4FC9U-d TY+BUHD 配置主機激活、通道和協議設置。建議運用配置文件,可以經過調用 RemotingConfiguration.Configure 加載。 0Sgn Vza 發布接口,供客戶端運用有關詳細信息,請

4、參閱下文中的“接口發布選擇。 QXqkN y= /5rXK 客戶端義務 5AL/Xix, | h/-;DCd 設計客戶端,選擇運用程序域和激活方式。 hhV!3* qE%li6 思索能否需求注冊通道和端口。 r*0/6/3 ot YhK?+ 獲取遠程類型元數據。 g7Z OGM NqM?m 實現客戶端運用程序域。 9 *v!1 rdi-|6U 配置客戶端激活方式和其他類型的信息,如運用程序稱號、通道和對象 URI 等。建議運用配置文件,可以經過調用 RemotingConfiguration.Configure 加載。 yb*!?dA Hbt-m 2 Remoting 處理方案的過程中能夠會遇

5、到的錯誤情況 W&)giI 在 任何情況下,都應該記住要運用規范的設備運用和監視方法。事件記錄仍是非常有價值的信息資源,就象網絡監視器工具一樣,網絡監視器可以專門用于詳細查看客 戶端/效力器的 Remoting 會話。中間層的 Remoting 效力器仍可以運用 Visual Studio .NET 提供的規范調試工具進展調試,例如,對于由 IIS 集成的 Remoting 效力器,可以經過向 ASP.NET 輔助進程附加調試會話Visual Studio .Net | Debug 調試 | Processes 進程 | Attach 附加 來設置斷點假設資源可用。但 Remoting 的錯誤

6、很獨特,下面列出了一些。請留意,一切錯誤都已運用 .NET Framework SDK 提供的 Basic Remoting Hello Sample 的各版本進展了復現,效力器和客戶端也已在單機上運轉。缺點景象與在網絡鏈接上的一樣,只是由于 /TCP 的超時設置不同,需求相當長的時間才干出現錯誤。 TgRNW clbPrDkx 2.1喪失 MarshalByRef u 對于效力器激活,Remoting 效力器將其偵聽處聲明為端點。該端點普通包括一個對象 URI遠程對象的眾所周知稱號,一個協議和一個端口號。當然,一切這些都能夠配置錯誤。 AWllny ;b+GMp 2.3錯誤的 URI ,kw

7、U5 由效力提供的 Basic Remoting Hello Sample 的 URI 是 HelloService.soap,如相關的 web.config 文件中所指定: qMF;/z m2I U;T/,P9G ;4fAUn8 wgHSuU?c HY-0YUQ &JzwU) n7YC FVYT5,i too =UZzX+5! G$isM =+ ys0m/V8 Ff UDm fU5e/Z$ -/1R.Q snp+aQ%P XQhDWq z| E9c,? -q,GOJ 此 效力是 IIS 集成的。IIS 集成要求 URI 帶有后綴 .rem 或 .soap,我們在效力器上運用 .rope。在此

8、實例中,我們將再次收到 RemotingException,這次顯示的文本是“對象 在效力器上已斷開或不存在。 kA!*|. .f n)( 請確保各個 URI 相互匹配!當 IIS 集成 Remoting 效力器時,還要確保 URI 以 .rem 或 .soap 結尾。 kaH hd q!bz% 為了進展此項測試,我們切換到控制臺集成的效力器,以下是該效力器的配置文件: afk=Zg h#EuXo %8gf7 uAZCgF 8.8: $ ;OfPvo FHHjA1K 7yINrdpRd /wm 7wq 2_ u(WKf 8SM?sPQ - ZM b;LAafqI |M55iUjwg +,56z

9、t *?aL_a3r |,yILE. h%!_jt1 OdsNB_dk kbwNG pPw HSRJCwj| ck;ri g5) r8 S?43/T% 8GU9/9V 假設我們要在效力器端將協議更改為 TCP,而使客戶端保管 。 0$%W =O;&28 我們將再次收到 RemotingException,這次的文本是“底層銜接已封鎖:接納時出現不測錯誤。 HNJg C&-%#: 端口設置錯誤也會導致上述異常,獨一的不同是這種情況下,要用較長的時間才會出現錯誤。效力器和客戶端之間的端口和協議必需匹配。 r /d$ wLwIk_q 2.5喪失 URI I)5AK* 另 一種能夠性是遠程效力器沒有運

10、轉,例如,效力器由 IIS 集成,而虛擬運用程序或相關的程序集喪失。再次運用 Basic Hello Remoting 效力器,我們需求虛擬運用程序 RemotingHello 可以運轉。假設不能運轉,我們將收到未處置的異常取決于調用代碼,但這次的異常將是:“無法加載類型 clr:Hello.HelloService, Hello。 W$)Z; kDB JP 在這些情況下,請確保虛擬運用程序在運轉,而且所需的程序集正確地放置在相關的 bin 子文件夾中。 *)Ae sB bLtq 總而言之,客戶端必需正確地援用效力器定義的端點以便激活效力器,這意味著,端口、協議和 URI 的定義必需相互匹配。

11、這太容易出錯了。因此,假設效力器的位置定義為: saLqSLw DO! zzuA#Z6e 0#lLuj LbV pW & 7 2|gSq 2ssYy!#s 那么,客戶的設置必需為: sI?5ysgJ nAd(?c c77!( ?!tVotJ 78RC _b; 5 !4;9G2KQ Ps0uGTjT 其中,URL 表示集成 Remoting 效力的 IIS 虛擬運用程序,類型表示類和程序集稱號。 5.IdfiY nALTvtZs 3 Remoting 的特點 aK$P# 3.1 優點 9 -o -bL 他的優點是用戶既可以運用TCP信道方式進展二進制流方式通訊,也可以運用HTTP信道進展SOAP

12、格式的性通訊 2LmJ_o zo_BY, 效率相對WebService要高不少;但是它的缺陷也很明顯,.net remoting只能運用于MS 的.net framework之下。 73;xC+x zin$KEQ4 從性能上來講Remoting的效率和傳統的DCOM、COM+的性能很相近。 fW:3ud U_224rz0 3.2 缺陷 $s&*A 這種三層設計的缺陷與運用 XML Web service 的三層設計的缺陷一樣。 G&zoQ9 6-4a4, 一切業務規那么均包含在前端代碼中。因此,假設需求更改業務規那么,那么必需更新全部客戶端。除非可以進展自動更新,否那么這種維護任務將非常繁瑣。

13、當然,假設運用 SQL Server,那么可以將某些業務規那么放到存儲過程中,從而減少維護的時間和本錢。 Zl?/n2|? CKyf$ZJ 一切字段稱號均在源代碼或控件屬性中硬編碼。假設更改字段稱號,那么必需查找和交換運用程序中一切該字段的稱號。假設運用了數據綁定,還必需檢查一切窗體并更改屬性。 0kHjin aZKv;/ 經過網絡從一個組件向另一個組件傳輸數據比直接銜接數據庫要慢。在 Intranet 方案中,.NET Remoting 的性能比 XML Web service 要好。而在 Internet 方案中,普通不運用 .NET Remoting。 Ch$I#j B;oJV)-m 建

14、立這種運用程序比建立兩層運用程序或運用 XML Web service 的運用程序要復雜一些。 +IRPXH_ 4uoWH!zQ+T 必 須運用比 TCP 速度慢的 。另外,IIS 能夠循環執行 ASP.NET 輔助進程,這將破壞一切 Singleton 的形狀。對您來說,這能夠是問題也能夠不是問題,要取決于您的設計需求,由于客戶端的下一個調用將重新啟動 Singleton。您可以將 IIS 配置為不循環執行輔助進程,但這種才干很有限,特別是在 IIS 5 中,而且能夠呵斥更進一步的影響。這里最根本的意思是,假設要求遠程效力器的平安性,那么無疑要運用 IIS 集成。 A&y-c 1b w-Xx

15、 XXv 所 以,在實踐做工程的過程中,我更傾向于先調用本地的對象,等調試勝利后,再翻開Remoting效力,調用遠程對象,驗證能否正確。舉例來說,我要提供訪 問數據庫的遠程對象。我會先讓該對象在本地運轉,并調用其方法。假設一切正常,闡明數據庫的配置和銜接均是正確的。然后再將該調用交換為遠程對象。假設程 序出錯,那么可以一定是Remoting提供的效力出錯了,或者是遠程對象未按照Remoting的規定,沒有派生MarshalByRefObject, 或者未提供序列化特性。 $KKVAfEM ?Q4(|&w$o Bn1/ r.4X| 3f,OvP, switch (invokeMode) pgB

16、9&kvY DF- Et case InvokeMode.Local: 5x!RwQ,l serviceObj = new DBAccessService(); %xpm break; %-|YF| case InvokeMode.Remoting: ufNhp serviceObj = (DBAccessService)Activator.GetObject(typeof(DBAccessService),tcplocalhost:8080/DBAccessService); %H*ANEu,!# break; V 5xUG6 Eetymx ggn$ljFW private DBAccess

17、Service serviceObj = null; jJ(J)% ni m0 如此這般,在客戶端調用對象時,就可根據設置構造函數中的參數枚舉值,靈敏地改動客戶端調用對象的方式。 :wR?T!4 ($:-.gQs2 其實這種方法也可以用簡單工廠方式來完成。不過這個簡單工廠消費的產品和通常意義的工廠方式有點不一樣哦,由于他們的產品其實是完全一樣的。不同的僅僅是創建對象的方式而已。 V?0DDZZH M&.og0 public class SimpleFactory ixG_4x ;p e/X public static DBAccessService CreateInstance(InvokeM

18、ode invokeMode) l$1|ql?= switch (invokeMode) QB/OC b& *8*L4v_d case InvokeMode.Local: *+:AH return new DBAccessService(); dZo _* break; r*+: case InvokeMode.Remoting: 0/,dZT)W return (DBAccessService)Activator.GetObject(typeof(DBAccessService),tcplocalhost:8080/DBAccessService); kiZ#Xt break; Qy_e|U

19、 QT 0y (e&D/|7R W9b_4r dY.-ia Zns 然后再調用工廠的靜態方法,來獲得該對象即可。 7:4 ; W_xTki 兩種方法都是一種思想:就是根據需求,選擇不同的創建方式其實前一種方法也可以看作是簡單工廠方式的一種變種。假設只需一個要創建的對象,選前者更為方便;假設需求創建多個對象,用工廠方法提供多個靜態方法,應該要靈敏一些。 $x(zgKQR /9FxMNR 經過上述方法,不僅便于調試,也便于以后代碼的修正。假設取消運用Remoting,只需改動參數枚舉值即可,其他代碼統統不用改動。這個技巧也算是設計方式的一種最簡單運用吧。 v/|WtW FWMOhvF-x 5 測試

20、方案 XAujKXQ 分布式運用程序中進程間通訊的性能取決于以下要素: 9Br( X |a-9/_K 用于跨遠程邊境的運用程序間傳輸信息的通道包括 TCP 和 占用的系統開銷量。TCP 套接字比 更為有效。 |uaQ? f0p2CkH Remoting 分別運用 BinaryFormatter 和 SOAPFormatter 將對象序列化為二進制格式和 SOAP 格式。由于這些格式化程序運用反射,因此對于援用對象很快,但對于必需經過裝箱或取消裝箱來經過反射 API 傳送的值類型那么較慢。此外,SOAPFormatter 還需求額外的系統開銷以生成編碼的 SOAP 音訊。 %yR6# gC .C

21、n#QB* 我們運用測試基于訪問客戶和訂單數據的普通業務方案。為使測試盡能夠符合實踐,數據庫中包含 100,000 多行客戶帳戶。數據位于 Orcale 數據庫中。 ? QeZ_-6 D=.8q hC 測試過程中,我們逐頁提取不同類型客戶行集合,然后查詢商品,填寫完銷售訂單后,提交保管。在這個過程中,用LR模擬100虛擬用戶同時進展操作,檢測系統呼應時間及其他性能參數。 snMRZ$h1* 8MCy 6 測試工具和戰略 TZ 6.1 工具簡介 J!s=d k 在 本測試中,我們運用了 MI 公司的loadrunner。它可以對 Web 效力器進展強度測試,分析 Web 運用程序包括 ASPX

22、頁及其運用的組件的性能和可伸縮性問題。有關如何創建和運轉測試的詳細信息,請參閱loadrunner運用手冊。經過翻開到效力器的多個銜接并迅速發 送 懇求,loadrunner可以模擬一大組用戶。它還允許我們建立實踐的測試方案,我們可以在方案中運用一組隨機參數值調用同一個方法。此功能很重要,因 為用戶不能夠會運用一樣的參數值反復調用同一個方法。另一個有用的功能是,loadrunner可以記錄測試結果,然后進展分析,從而提供有關 Web 運用程序性能的最重要的信息。 8 ePt | #kUm$L 6.2處理Loadrunner中沒有相關Remoting協議的問題 )3+OVH 因 為在C/S 的

23、ERP系統中,LR并沒有remoting相關協議可以選擇,直接導致了LR無法錄制操作步驟,獲得腳本程序。處理這種情況有一種方法,即:去 MERCURY官方站點去下載一個基于.NET Remoting的add-in的補丁包,把此包集成于.NET C#開發環境中,這時,開發環境上方工具條會出現一個Vuser的新控件見以下圖。我們調入被測源程序,然后在其中創建一個Loadrunner的新項 目,然后根據被測對象,在開發環境中寫出測試代碼。最后利用Vuser項創建LR的場景,它會自動調用LR去做,設置終了運轉即可。當完成場景運轉之后, 利用LR的Analysis工具進展分析即可。 FG;Zi3y ;r

24、0;c 38tFilA 7 LR計數器簡介 8w8p| Memory: QEK AKc L2m bGy 內 存運用情況能夠是系統性能中最重要的要素。假設系統“頁交換頻繁,闡明內存缺乏。“頁交換是運用稱為“頁面的單位,將固定大小的代碼和數據塊從 RAM 挪動到磁盤的過程,其目的是為了釋放內存空間。雖然某些頁交換使 Windows 2000 可以運用比實踐更多的內存,也是可以接受的,但頻繁的頁交換將降低系統性能。減少頁交換將顯著提高系統呼應速度。要監視內存缺乏的情況,請從以下的對象計 數器開場: dixnn0z &SY d Available Mbytes: ELgHH7qs TKBC06, 可用

25、物理內存數. 假設Available Mbytes的值很小4 MB 或更小,那么闡明計算機上總的內存能夠缺乏,或某程序沒有釋放內存。 kv6YOt: vDn0RN%w page/sec: :3QU c* sv- 表 明由于硬件頁面錯誤而從磁盤取出的頁面數,或由于頁面錯誤而寫入磁盤以釋放任務集空間的頁面數。普通假設pages/sec繼續高于幾百,那么您應該進一 步研討頁交換活動。有能夠需求添加內存,以減少換頁的需求他可以把這個數字乘以4k就得到由此引起的硬盤數據流量。Pages/sec 的值很大不一定闡明內存有問題,而能夠是運轉運用內存映射文件的程序所致。 k;W(y 5. 越低越好。大數值表示

26、磁盤讀而不是緩存讀。 KvjG+_2U (T1WKeY 由于過多的頁交換要運用大量的硬盤空間,因此有能夠將導致將頁交換內存缺乏與導致頁交換的磁盤瓶徑混淆。因此,在研討內存缺乏不太明顯的頁交換的緣由時,必需跟蹤如下的磁盤運用情況計數器和內存計數器: IAp7,5y RPQEjk+ Physical Disk % Disk Time 、Physical Disk Avg.Disk Queue Length 例如,包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。假設頁面讀取操作速率很低,同時 % Disk Time 和 Avg.Disk

27、 Queue Length的值很高,那么能夠有磁盤瓶徑。但是,假設隊列長度添加的同時頁面讀取速率并未降低,那么內存缺乏。 nphAnVOb yurTY 要 確定過多的頁交換對磁盤活動的影響,請將 Physical Disk Avg.Disk sec/Transfer 和 Memory Pages/sec 計數器的值增大數倍。假設這些計數器的計數結果超越了 0.1,那么頁交換將破費百分之十以上的磁盤訪問時間。假設長時間發生這種情況,那么您能夠需求更多的內存。 6By?T Qxo:t0d Page Faults/sec: MyPfL ohcV 每秒軟性頁面失效的數目包括有些可以直接在內存中滿足而有

28、些需求從硬盤讀取較page/sec只闡明數據不能在內存的指定任務集中立刻便用。 1R87 osv=44_ Cache Bytes: 99W7=8i Sf/7.H 文件系統緩存File System Cache,默許情況下為50%的可用物理內存。如IIS5.0 運轉內存不夠時,它會自動整理緩存。 Wlo%QlZn 6TNwN 需求關注該計數器的趨勢變化 4R-L :faf/UEfQ 如 果您疑心有內存泄露,請監視 Memory Available Bytes 和 Memory Committed Bytes,以察看內存行為,并監視您以為能夠在泄露內存的進程的 ProcessPrivate Byt

29、es、ProcessWorking Set 和ProcessHandle Count。假設您疑心是內核方式進程導致了泄露,那么還應該監視 MemoryPool Nonpaged Bytes、Memory Pool Nonpaged Allocs 和 Process(process_name) Pool Nonpaged Bytes。 Xr)fbL1 )hg_*0U Pages per second : zTI68r pDG0_ 每秒鐘檢索的頁數。該數字應少于每秒一頁。 )1c%S N1dcLQ1/Oz Process: &ufc3$Ur( x ;EoMqQ %Processor Time: %

30、aI_N x Uv%l 被處置器耗費的處置器時間數量。假設效力器公用于sql server,可接受的最大上限是80-85% 3+A6iAK- zif00=% Page Faults/sec:將進程產生的頁缺點與系統產生的相比較,以判別這個進程對系統頁缺點產生的影響。 )7EZk=|! GSNv_Zk Work set: a1X a9F-PM 處置線程最近運用的內存頁,反映了每一個進程運用的內存頁的數量。假設效力器有足夠的空閑內存,頁就會被留在任務集中,當自在內存少于一個特定的閾值時,頁就會被去除出任務集。 c%vn T:bsB CibAtff Processor:監視“處置器和“系統對象計數器

31、可以提供關于處置器運用的有價值的信息,協助 您決議能否存在瓶頸。 1/W;H N2l 2;:* 29_E %Processor Time: OD5nEfX cU&:Ma*hn 假設該值繼續超越95%,闡明瓶頸是CPU。可以思索添加一個處置器或換一個更快的處置器。 ?nim!%WjQw xN9!)SNx %User Time: u/&Es5l j FY%Ew 表示耗費CPU的數據庫操作,如排序,執行aggregate functions等。假設該值很高,可思索添加索引,盡量運用簡單的表聯接,程度分割大表格等方法來降低該值。 ?5GT*R yAXn*Jp/ %Privileged Time: YX

32、Og:FY UWZ +7d2 CPU 內核時間是在特權方式下處置線程執行代碼所花時間的百分比。假設該參數值和Physical Disk參數值不斷很高,闡明I/O有問題。可思索改換更快的硬盤系統。另外設置Tempdb in RAM,減低max async IO,max lazy writer IO等措施都會降低該值。 U?UG_oU XEK8 此外,跟蹤計算機的效力器任務隊列當前長度的 Server Work Queues Queue Length 計數器會顯示出處置器瓶頸。隊列長度繼續大于 4 那么表示能夠出現處置器擁塞。此計數器是特定時間的值,而不是一段時間的平均值。 1U4b7 G*rtY

33、 % DPC Time: g4unab h DIMZhH/ 越低越好。在多處置器系統中,假設這個值大于50%并且Processor:% Processor Time非常高,參與一個網卡能夠會提高性能,提供的網絡曾經不飽和。 GWMs%hwY -2% Process z)F=I8 WtH)LlW % Processor Time 指這個線程運用途置器執行指令的所用時間的百分比。類似于Processor的% Processor Time ;gLse- PaWj % Privileged Time 指這臺處置器的線程用于執行在特權方式中的代碼所經過時間的百分比。類似于Processor的% Priv

34、ileged Time jD4Wy4! ;n lk* % User Time 指這臺處置的線程用于執行運用用戶方式的代碼的時間的百分比。類似于Processor的% User Time wRg94 C9 09R=% Private Bytes 指這個處置不能與其它處置共享的、已分配的當前字節數。假設此數值隨時間不斷增大,有能夠是內存走漏。 =bL :xT7 b$w-*t Virtual Bytes 指處置運用的虛擬地址空間的以字節數顯示的當前大小。運用虛擬地址空間不一定是指對磁盤或主內存頁的相應的運用。虛擬空間是有限,假設運用過多,能夠會限制處置加載數據庫的才干。 N*|H5W=V Umt4

35、IO Data Bytes/sec 處置從I/O操作讀取/寫入字節的速度。這個計數器為一切由本處置產生的包括文件、網絡和設備I/O的活動計數。 +AtBzG- UQq8o6 v Processor 3fYD 6fi,RI= % Processor Time 指處置器執行非閑置線程時間的百分比。這個計數器設計成用來作為處置器活動的主要指示器。它經過在每個范例間隔中衡量處置器用于執行閑置處置線程的時間, 并且用100%減去該值得出。(每臺處置器有一個閑置線程,該線程在沒有其它線程可以運轉時耗費周期)。可將其視為范例間隔用于做有用任務的百分比。這個 計數器顯示在范例間隔時所看到的忙時平均值。這個值是

36、用100%減去該效力不活動的時間計算出來的。 Vd|e0 GA vFApX$ 正常值90,此值過大表示處置器的性能曾經不能應付程序的要求,要換更快的處置器。 E u7t, bx V5R-n % Privileged Time 指非閑置處置器時間用于特權方式的百分比。(特權方式是為操作系統組件和支配硬件驅動程序而設計的一種處置方式。它允許直接訪問硬件和一切內存。另一種模 式為用戶方式,它是一種為運用程序、環境分系統和整數分系統設計的一種有限處置方式。操作系統將運用程序線程轉換成特權方式以訪問操作系統效力)。特權時 間的%包括為延續和DPC提供效力的時間。特權時間比率高能夠是由于失敗設備產生的大數

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論