現在好多PB webservice三層的中間件都是用getfullstate和setfullstate來傳送和處理資料視窗中資料,也包含這個版塊里面的好多例程與網上的例程.如果按照這種辦法,要達到EASERVER的性能是不太可能的.
下面是武漢源啟的性能測驗介紹:
PBntierBuilder：V3.1
PowerBuilder：V9.0
應用服務器：Sybase EAServer 5.3
配接器：PB WinForm+EAS IIOP
資料庫：MS SQLServer2000
帶寬狀況：
武漢-武漢同城武漢（服務端，10M 專線）- 武漢（客戶端，1M ADSL）
武漢-北京異地武漢（服務端，10M 專線）- 北京（客戶端，2M 有線電視寬帶）
武漢-上海異地武漢（服務端，10M 專線）- 上海（客戶端，1M ADSL）
武漢-臺北兩岸武漢（服務端，10M 專線）- 臺北（客戶端，2M ADSL）
測驗環境
檢索（Retrieve）不同記錄條數下的耗時情況(秒)
100 行1000 行10000 行100000 行
本地局域網（ 0.062 0.172 0.390 1.953
互聯網
武漢-武漢同城0.172 0.110 0.563 7.688
武漢-北京異地0.109 0.171 0.905 7.613
武漢-上海異地0.188 0.171 0.625 5.093
武漢-臺北兩岸0.330 0.410 0.941 6.469
當然,不知道它服務器是什么配置,搞不好是4核+16G記憶體的,另外每條記錄中的欄位數也沒說明,呵呵..
如果只有一個數值欄位的話,那么就不用EASERVER,用我這種方式也能達到這個水平了.
我現在的服務器是WIN2003,賽揚2.93G+2G記憶體+3M ADSL,硬碟是7200轉的普通串口硬碟.
客戶端AMD雙核2.1G+2G記憶體+2M ADSL (同城)如果網路正常的話
100行 10個欄位 壓縮后為906BYTE: 0.3至0.5秒
7000行 2個欄位其中一個為100個字符 壓縮后為61300BYTE: 2.5-5秒
感覺有時候快有時慢,但上面的數值為平均值(不要開迅雷或者其它下載軟體,不然速度立即下降很多),我想這個跟網速多少也有點關系.
不使用getfullstate/setfullstate方法,使用下面方法流程:
1.客戶端送入資料視窗名稱(千萬不要上傳語法,這樣又不見了幾K的資料量),服務器端根據資料視窗名稱從PBD或者資料庫取得語法后,生成資料視窗,檢索資料.
2.服務器端對資料視窗使用saveas函式(不知道能不能使用object.data)來獲取,壓縮后回傳.
3.客戶端使用importfile匯入資料,匯入后更改各行STATUS,讓其保持retrieve后狀態.
4.客戶端修改資料,保存更新的時候使用getchange獲取資料壓縮后傳送到服務端.
5.服務端接到資料后,用setchange函式后update資料視窗.
需要注意地方:
1.服務端SAVEAS資料后,必須把所有DDDW也saveas并按資料視窗方式回傳,這樣子才能處理下拉子資料視窗.
2.對于有分組的資料視窗,不知道這種主要獲取資料后,分組有沒有問題,未測驗.
3.如果資料互動速度提高了,可以將業務和控制處理功能放在客戶端,但是這樣子處理的話,好像就不是三層結構了.
4.如果業務控制和處理放在服務端,則不能使用這種方式,這種方式會丟失資料視窗大部份狀態和標識.
5.互動資料時,如果資料超過一定值,最好采用分頁并且分段傳輸,這樣不會給客戶感覺死機了一樣.
getfullstate:其實就是整個資料視窗復制.包括語法,資料,緩沖區資料,各行列狀態.如果采用getfullstate,客戶端是不用放資料視窗的.
setfullstate:與getfullstate對應.
getchange:類似getsqlpreview,只是取資料視窗部份修改內容,我分析過里面的資料,不外是inset into .. values...和update ...set a=... where a...和delete等語法.如果沒有修改的資料是不會生成語法的.
setchange:與getchange對應.
其實不使用getchange/setchange,而且通過打包上傳getsqlpreview(),服務端進行setsqlpreview后來更新資料應該也是可行的辦法,不過沒有測驗過.
希望大家討論一下,看看還有沒有別的更好的辦法來提高使用WEBSERVICE開發三層的性能.
不是說PB做網路應用性能不行,只是有很多地方都沒有研究透.
國慶放假在家,突然想起這個問題,寫得比較亂,見諒.
uj5u.com熱心網友回復：
對于 pb 的 webservice 開發，我覺得最好按三層的理念去做，否則很可能四不象。如果速度是壓倒一切的話，那么我們也就不必放棄 c/s 了。既然我們已經犧牲了速度，那就要讓它犧牲的得有意義！做為最基本的三層架構，客戶端與中間層必須是嚴格分離的。換句話說，就是“表現層與業務層是嚴格分離的”。但鑒于 datawindow 天生的表現與業務緊密耦合特性，我將這句話改為“非業務表現層與業務層是嚴格分離的”實際上，業務層是由業務邏輯層和業務表現層共同完成的，就 pb 而言，也可以說是由自定義物件和資料視窗物件共同完成的。而站在系統分析員的角度，做客戶端的程式員是完全不了解業務的，即使了解，也沒有直接操作資料庫的可能，一切都必須經過 webservice 提供的介面進行，而這個介面是抽象化的服務指令，完全屏蔽了資料庫的底層結構以及系統的業務邏輯。
靈鴿的方案似乎是在盡全力用 webservice 來模擬 c/s 架構，也就是盡可能不改動客戶端的編程模式，而這樣的話，其實就是在尋求一個改動量的平衡點，客戶端改動得越少，速度就越高；也就是在保證客戶端不連接資料庫的前提下，盡可能地提高速度的問題。在某些特定需求下，這樣的方案估計是可行的，但做為通用性的解決方案則很難。因為分離面不徹底的話，將導致前端與中間層的開發人員都要懂得業務，不利于系統的任務分包。使用 saveas() 之類的方法，則不能傳遞 db ole 之類的資料，無疑也將限制此方案的通用性。
對于 pb 的 webservice 開發，我覺得最好按三層的理念去做，否則很可能四不象。如果速度是壓倒一切的話，那么我們也就不必放棄 c/s 了。既然我們已經犧牲了速度，那就要讓它犧牲的得有意義！
做為最基本的三層架構，客戶端與中間層必須是嚴格分離的。換句話說，就是“表現層與業務層是嚴格分離的”。但鑒于 datawindow 天生的表現與業務緊密耦合特性，我將這句話改為“非業務表現層與業務層是嚴格分離的”實際上，業務層是由業務邏輯層和業務表現層共同完成的，就 pb 而言，也可以說是由自定義物件和資料視窗物件共同完成的。而站在系統分析員的角度，做客戶端的程式員是完全不了解業務的，即使了解，也沒有直接操作資料庫的可能，一切都必須經過 webservice 提供的介面進行，而這個介面是抽象化的服務指令，完全屏蔽了資料庫的底層結構以及系統的業務邏輯。
靈鴿的方案似乎是在盡全力用 webservice 來模擬 c/s 架構，也就是盡可能不改動客戶端的編程模式，而這樣的話，其實就是在尋求一個改動量的平衡點，客戶端改動得越少，速度就越高；也就是在保證客戶端不連接資料庫的前提下，盡可能地提高速度的問題。在某些特定需求下，這樣的方案估計是可行的，但做為通用性的解決方案則很難。因為分離面不徹底的話，將導致前端與中間層的開發人員都要懂得業務，不利于系統的任務分包。使用 saveas() 之類的方法，則不能傳遞 db ole 之類的資料，無疑也將限制此方案的通用性。
以上是對三層開發的一些拙見，敬請指正。
uj5u.com熱心網友回復：
用Get/SetFullState之后壓縮就可以了實在不行,就用XML
折衷的解決方案,效果也還可以,代碼也容易寫點,要是傳遞dw的名稱,改動比較麻煩
uj5u.com熱心網友回復：
剛才測驗過了,get/setfullstate對于下拉資料視窗是支持的,但是前提必須是客戶端和服務器端都要有子資料視窗存在,而且下拉子資料視窗中不能帶引數,如果帶引數,則還是需要另外處理的.現在主要是想辦法怎么能夠節約通訊資料量,其實如果網速提高了,那么這個就不是問題了,呵呵.
只傳資料的話,確實能省很多流量的.其實get/setfullstate如果里面不含語法的話,那么資料量應該會小很多.一般一個資料視窗的單單是語法資料量就應該在20-30K左右了.
我覺得可以把這種只傳輸資料的方法用于查詢和報表以及處理一些較少涉及業務流程的資料視窗.
有涉及復雜業務流程的功能,將其代碼寫在業務處理層,傳輸使用get/setfullstate.
另外我想問一下,像最簡單的一個表新建一個記錄.按三層結構來寫.
是不是應該是這樣子處理.
1.接收服務器端新增好的資料視窗資料(因為有可能一些欄位在服務器端要計算后賦值)
2.客戶端編輯資料.
3.發送修改后的資料到服務器端進行保存前資料的較對和其它流程處理.
這一較對程序如果不放在客戶端,那么就需要發送整份資料給服務器,讓服務器完成較對.如果資料不正確,則再回傳處理.這樣就必然消耗大量資料,每一次都要發送整個資料視窗資料給服務器.如果放在客戶端,那么前端開發人員就必須懂業務流程了.而且這樣的話,基本上每一個功能都需要寫上檢索/新增/洗掉/更新/較對,保存這么多webservice介面.感覺非常煩瑣.
4.完成修改,保存資料.
因為接觸三層不久,很多時候觀念轉變不過來啊.
uj5u.com熱心網友回復：
我曾經設想,PB11提供了開發webservice的能力,那么,要是把客戶端和webservice之間傳輸的大資料用zlib壓縮傳輸,應該會提高很多查詢效率,因為大家都知道,資料的壓縮率是很高的.為此,我經過幾天的時間,專門寫了pb在webservice下的資料視窗的檢索,更新(當然我也是使用get/serfullstate),并對之進行測驗.感覺和直接的c/s比較,速度并沒有提高什么,而且,對大量資料進行查詢后,會出現blob型別轉換時記憶體溢位的問題,但我想這應該是不PB的問題,而是.NET的問題,因為在網上查了一下,.net開發的也會存在這個問題.
所以,我認為,沒有必要使用webservice,還是直接使用c/s比較好,因為網路在發展,網速也在不斷提高,所以,用C/S勝過websevice,當然,如果你想在客戶面前說這是使用了什么什么技術,費用要多少多少,那就另當別論啦
uj5u.com熱心網友回復：
傳個dw還這么費周折，一點不OO，貌似PB支持JBOSS，不如研究下這個，也是免費的，還是.net好，序列化類，用DW顯示資料uj5u.com熱心網友回復：
glint:如果后臺用.net,前端用DW顯示,資料保存的時候要怎么處理?
uj5u.com熱心網友回復：
我目前采用pb11+IIS6的形式webservice，因為IIS6無法保持狀態，我將就采用CS模式，在客戶端做資料判斷，同時下拉dw都是在程式初始化時從代碼表中全數讀入客戶端，在客戶端初始化下拉dw1.讀取資料采取傳dw的sql+where的形式，服務端將此sql創建ds取得資料，資料回傳若資料小就不壓縮，資料大就壓縮，客戶端得到后import進dw，這樣可以修改某個dw時不發布dw到服務器
2.保存資料分成2類，a單純新增類，直接把dw的data傳入服務端，服務端匯入后保存，用于單據的輸入。b類是整個dw取得blob后上傳服務器保存
uj5u.com熱心網友回復：
這最終來說，仍是個平衡和取舍的問題。代碼的分離面越徹底、通用性越強，安全性越高，則其效率就越低！我想這也類似于時間與空間的關系，從一切事物的根本來說，無非是用時間換空間，還是用空間換時間的問題！我們能做的，就是“選擇”，選擇放棄什么，得到什么，有失才有得，有得必有失，天理如此。如果要做到前端完全業務無關，而資料檢索量又很大的話，我想可以通過 sqlpreview 事件獲得修改部份的 sql，提交此 sql 到中間層，中間層逐行分析提交的資料是否符合業務要求。但顯然這樣的編程方式是原始得讓人難以忍受的，我想我是不會這么做的。我會盡可能減少每次檢索的資料量，然后整個 dw 發回中間層，因為 webservice 本就是為“不頻繁的大資料量互動”而設計的，離開這一前提，使用 ws 就是不合時宜的，所以我更關注的是如何減少并發，而非減少資料量。如果存在大量并發，那么我覺得 b/s 架構才是合適的。
uj5u.com熱心網友回復：
fang3307:這樣子處理跟二樓講的一樣,感覺不像是三層結構了.
1.讀取資料采取傳dw的sql+where的形式，服務端將此sql創建ds取得資料，資料回傳若資料小就不壓縮，資料大就壓縮，客戶端得到后import進dw，這樣可以修改某個dw時不發布dw到服務器
這種方式跟我現在做的有點像,不過我不傳sql+where,這部份我在服務器端根據傳的資料視窗名稱獲取.
問題是如果資料需要在服務器端用中間層再進行處理的話,就不能用這種方式傳資料給服務器import了.
uj5u.com熱心網友回復：
現在這樣子處理也是可以控制并發的,本身DW就有這些功能,都不用我們去考慮的.如果我同時檢索兩個資料視窗,第一個修改資料后保存,第二個再保存會提示錯誤的.
不知道B/S是怎么控制并發的??
uj5u.com熱心網友回復：
這個說得很有道理.
uj5u.com熱心網友回復：
我現在沒有中間層，iis當中間層就是讀取和保存兩個功能，感覺就是CS，只是客戶端不直接連資料庫而已uj5u.com熱心網友回復：
那其實不是真正的三層啦.這樣子對開發人員在將C/S的程式修改起來很快的.根本上就是兩層的結構.如一個登錄處理程序 login_process
1.檢索用戶,判斷是否存該用戶.
2.根據用戶得到相關引數資訊.
3.寫在線登錄表.
4.寫登錄日志.
如果寫在客戶端,跟webservice交換資料的程序就需要4次,
但是把它寫在服務端,就只是一個程序了.而且以后有所改動,只需要修改服務端即可.
這也是我認為三層比較好的地方.
另外有個問題想請教一下:
能不能在PB11里面用多執行緒來獲取資料??比如說服務端一個1M的資料,分成10段,1段100K,然后分10個執行緒同時跟WEBSERVICE互動取資料.這樣子理論上速度不知道會不會有所提升???
uj5u.com熱心網友回復：
登錄的資訊我也是照你這方法做的。很多地方還帶有cs的痕跡而已，特別是資料的驗證，資料的提取，這些若建在中間層，需要ws上寫大量的函式。
報表之類的我是在服務端生成，傳到客戶端美化和顯示而已
pb11多執行緒還沒聽說過
uj5u.com熱心網友回復：
我說的并發，倒不是指并發控制的問題，而是指在線用戶很多的情況下，webservice 的介面經常在同一時刻被多個用戶訪問。這樣就會導致 ws 頻繁地創建和銷毀，資料庫頻繁地連接和斷開，這種開銷是基于 ws 的 c/s/s 架構難以承受的。換句話說，我們不可能指望通過 ws 來開發一個面向大眾的網站，這是 b/s 的專長；反過來說，如果一個系統的在線用戶數量不是很大的話，則采用 b/s 就是浪費人力資源了，為了完成一個 c/s 中的簡單功能，b/s 不知要繞多少個彎，而且最終效果也仍是難以令人滿意。所以，我覺得 pb 能夠開發 ws，的確是 pb 之前開發的大量 c/s 系統的救命稻草，因為 c/s 實在是太不安全了！至于說多執行緒問題，pb 沒有真正的多執行緒機制。對 ws 來說，應該不存在多執行緒的概念。當然，理論上你可以同時創建 ws 的多個實體，然后通過多個執行緒對其訪問（pb 可以模擬多執行緒），但這樣做本身就違背了 ws 只適合“不頻繁訪問”的原則，恐怕于提高速度也是沒有什么效果的。
uj5u.com熱心網友回復：
學習學習！！！！！！！！！！！uj5u.com熱心網友回復：
dw.net
uj5u.com熱心網友回復：
大家說的很好,uj5u.com熱心網友回復：
看來對于pb 開發webservice 大家都還是在學習階段.很想建一個webservice 中間層的開發聯盟.用大家的智慧把pb + webservice中間層完善并付于實施.壇里有人做廣告 webservice中間層 代碼要8000千元,其實我們完全可以做這樣的代碼.
我的QQ 403438229
個人研究 pb + webservice 一月有余,大家加我共同努力
uj5u.com熱心網友回復：
有沒有免費的中間層?easerver只有開發版
jboos雖然免費，但是pb11使用需要插件，該插件sybase提供開發版，沒在網上找到破解的
uj5u.com熱心網友回復：
免費的解決方案：1、powerbuilder基于webservice的三層
2、powerbuilder基于COM+的三層
uj5u.com熱心網友回復：
大家說的很好啊uj5u.com熱心網友回復：
現在還有一個問題,不知道PB做的WEBSERVICE多用戶同時并發訪問時的性能如何?有沒有兄弟測驗過???
uj5u.com熱心網友回復：
基于webservice的三層提高性能的主要方法：1、采用壓縮傳輸資料，這是減小傳輸的資料包大小的最有效方式。
2、分頁或分條件檢索資料，根據情況一次只檢索幾條、幾十潭訓幾百條，這樣資料庫里面有多少條資料都無所謂，如果資料量稍大一大點，如果一次性都檢索出來也是不現實的。
3、根據情況采用不同形式的資料傳輸方式，比如說一般情況下我們可能將整個資料視窗以blob形式傳輸到客戶端，而有些情況我們也可以以string形式進行資料的傳輸，這樣的話如果資料量小的話速度可能會更快一些。
基于webservice的三層，我想如果中間層在技術上處理好的話，去開發一些一般的應用應該可以的，但是如果處理不好的話，可能是功能是開發出來了，但應用起來是失敗的，這也許就是三層吧。
uj5u.com熱心網友回復：
學習。uj5u.com熱心網友回復：
基于webservice的三層提高性能的主要方法：1.實體池技術 這個在eas上系統已經實作 在IIS其實也可以自己實作 將資料庫連接和實體快取 這樣就不用每次都連接資料庫或讀pb的庫檔案了
2.資料快取技術 將常用的資料快取到IIS服務器本地
3.壓縮傳輸技術 引數式或自動壓縮傳輸資料
4.資料組處理技術 事務一致和減少互動次數 例如保存 Update Dw,update multi table dw,Execute SQL,Execute SP ,Update Blob交叉在一起提交服務器執行,讀取資料同樣
這些偽三層組件功能在我二年前已經實作,目前只在自己專案中使用，PB11.5開發 服務器用IIS 客戶端有PB PPB 二個組件 可以直連資料庫 也可以連中間層
為方便交流 開了個三層技術交流新群 QQ群:71088878
uj5u.com熱心網友回復：
將資料庫連接和實體快取,這個具體怎么處理?能指導一下嗎?
uj5u.com熱心網友回復：
mz_jenny能否講講實體池技術嗎?
uj5u.com熱心網友回復：
這個東西涉及公司的產品 再說 要實作好這個 要從組件的架構與外部的動態庫 相結合 比較復雜 一時半會說不上來 我的實作也相當復雜 如果你初次開發 建議先別實作這個
uj5u.com熱心網友回復：
我想問一下,你們公司的產品最多支持多少用戶同時在線?處理起來效果如何?我主要是怕按這種思路去設計系統,不要到時候不穩定就麻煩,而且客戶端有時候也是很多的,可能有幾百個.
uj5u.com熱心網友回復：
如果用ado.net 一般我想也是這個去連接資料庫，本身就支持資料庫連接池；我想用powerbuilder去開發.net webservice一個比較致命的問題就是byte和blob轉換的問題，如果資料量大的話轉換很慢或者根本不成功，要處理好。uj5u.com熱心網友回復：
應該不會吧?我現在做好的BLOB處理這一塊,可以上傳10M或者更大的檔案到資料庫去,也可以從資料庫下載下來.怎么會轉換不成功呢?另外不要用SOAP,我是用.net的WEBSERVICE.uj5u.com熱心網友回復：
說的就是.net webservice，經過測驗不行，不知道你用的pb是什么版本的，具體的開發和功能實作是怎么樣的？uj5u.com熱心網友回復：
pb11.5 2506版.上傳時先將資料壓縮后分批,然后分批上傳到服務器,服務器快取起來,接收到最后一批資料時,再組合.
下載時先由服務器SELECT出資料,根據每段大小分配好,回傳段數和快取名稱,然后服務端再一批一批獲取,最后再組合后解壓.
下載就比較快,上傳比較慢,這個可能跟網路有關系.
有點奇怪的是上傳的時候服務器CPU占用率很低,但是客戶端占用率高.
不知道分段大約是分一段大小多少比較合適?現在我分成64K,上傳時會有點停頓.
uj5u.com熱心網友回復：
哦，我說呢uj5u.com熱心網友回復：
如果能搞成多執行緒不知道會不會快很多,呵呵..不用一點一點傳.兩端再加個資料校驗.呵呵.現在傳2.5M的檔案要20-30秒.傳10M的檔案要100-150秒.
平均起來上傳速度還有100來K,感覺可以的啦.
只是不知道為干什么下載比較慢,上傳一般在20-25秒內,下載同樣的資料要27-33秒內.
uj5u.com熱心網友回復：
說句實在話，webserver 真的很慢，我們公司現大也支持兩種方式連接資料，一種是webservice,一種ado方式直接連接資料，客戶可以根據需求選擇兩者之一，最后所有的客戶都選擇后者，所以webservice最后只剩下銷售時售前忽憂客戶的一個賣點，沒有任何實際作用。uj5u.com熱心網友回復：
頂，樓上的pb c/s
.net b/s
uj5u.com熱心網友回復：
也談談自己的看法。有必要使用三層架構來開發PB的系統嗎？
為什么要用PB開發B/S程式？因為PB開發速度快。轉成3層架構，再加上啥壓縮等等，這個速度快的特性，基本上就不占什么優勢了。
如果系統必須要用三層架構來做，為啥不直接用java或者.net來做呢？
所以我認為：
如果用PB開發系統，主要目的就是一個快，啥2層3層的不用考慮。
如果必須3層，直接換開發語言。
個人愚見，請各位老大指正。
uj5u.com熱心網友回復：
支持,非常感謝uj5u.com熱心網友回復：
個人認為,對于中小企業的內部ERP系統而言,資料互動量倒不是影響速度的因素.因為:1.在線使用人數遠遠小于網站型的系統
2.一萬行資料的blob大嗎?應該不大吧,但應用真的用到回傳一萬行資料到客戶端嗎?還真沒那個必要.在webservice端就進行業務處理后,回傳的資料頂多也就千把行.再者,如果真的要回傳上萬行的資料,可以自行做個分段
所以,資料互動量的大小,不是pb的webservice的考慮因素
uj5u.com熱心網友回復：
更正我的看法:減少資料互動量有必要.因為最近用電信3g流量卡測驗了一下webservice應用,幾千行的資料,十幾分鐘還沒出得結果,接收流量已經達7M左右,下載速度平均為20k/s左右轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/65239.html
標籤：Web 應用
上一篇：在PB中如何打開pdf檔案?