2008年4月1日 星期二

biztalk 初次接觸

先前很早就想玩玩了,但一直沒機會或說是沒藉口吧。最近藉口來了!
先買了本書來參考

『Biztalk Server 2006 實戰筆記』 彭靖灝編著 網奕資訊出版


但是安裝的很慘,一直失敗,一直出現以下錯誤訊息
『Error 1928.Error registering COM+ application. Please ensure that DTC is enabled. Contact your support personnel for more information. 』

網路上Google一堆方式都沒太多效果,直到這個
參考網站1
  1. 先去這裡 下載網站 下載PSEXEC
  2. 執行 psexec -s -i f:\setup.exe (其中的f:\setup.exe 是因為我的biztalk光碟是在F:)
竟然就成功了。 也沒多改什麼設定,真是.....



PS:我系統的是 XP繁體中文 SP2 安裝BiztalkServer2006英文版

2008年3月31日 星期一

高效能的網頁設計 Yahoo! releases new performance best practices

原文出處 http://ajaxian.com/archives/yahoo-releases-new-performance-best-practices
參考內容 http://developer.yahoo.com/performance/rules.html

其他參考
http://www.cnblogs.com/JustinYoung/archive/2007/11/20/965070.html
http://www.cnblogs.com/justinyoung/archive/2007/11/28/speeding-up-web-site-yslow.html
http://blog.miniasp.com/post/2007/11/24/14-rules-for-faster-front-end-performance-notes.aspx
http://static.slideshare.net/swf/ssplayer2.swf?doc=high-performance-web-pages-20-new-best-practices-120577522992998-3
http://video.yahoo.com/watch/1040890/3880720

內容節錄

  • 速度、速度、速度
    1. 頁面速度變慢 500ms -> 使用者的中斷率提高 20%
    2. 頁面速度變慢 100ms -> 訂單喪失 1%
Ref http://home.blarg.net/~glinden/StanfordDataMining.2006-11-29.ppt
Ref http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html

  • 前端處理是速度的關鍵因素
    1. HTML主頁載入可能只佔用10-5%,後續80-90%的時間則是在下載與處理頁面所需Image、CSS、Script
    2. 前端頁面處理佔用80%-90%的比重
    3. 比改善後端容易
    4. 實證可行
  • 14項要點
    1. 減少HTTP Request
      1. 合併切圖 Image-Map
      2. 合併CSS、Script Files
    2. 使用 Content Devilery Network
      1. 針對靜態頁面置放於CDN Service Provider上(如 AkamaiMirror Image InternetLimelight Networks
    3. 增加 Expire Header 或 Cache-Contorl
      1. 加速後續的網站再次訪視
    4. 啟動 Gzip壓縮
      1. 壓縮資料可減少70%的傳輸量
      2. 但請勿對Image與PDF這類已經壓縮的檔案格式再次壓縮
    5. CSS 放最上面
      1. CSS置放於HEAD中可加速瀏覽器於頁面的處理作業
    6. 將Script儘可能放到最後面
      1. 提升檔案下載的平行處理
    7. 不要使用CSS自定義屬性( CSS expressions )
      1. 滑鼠的移動都可能得重新計算 造成使用者頁面反應緩慢
    8. 採用外部載入的CSS與JavaScript而非Inline
      1. 外部檔案有機會共用,就有機會Cache Hit
      2. 但首頁還是可採用Inline的方式,減少檔案的數量符合第一點的想法。
    9. 減少DNS查詢
      1. 減少Hostname的使用數量
      2. Browser的DNSCache時間不一,1分(Firefox)半小時(IE)或一小時
      3. 每次DNS查詢成本約20-120ms
    10. 縮小CSS與JavaScript大小
      1. 減少下載時間
      2. 可採用以下工具協助縮小檔案(JSMinYUI CompressorShrinkSafe
    11. 減少頁面跳轉的Redirect
      1. 常發生跳轉多半於不自覺的地方,如http://www.abc.com 會發生301狀態而再次跳轉至http://www.abc.com/
      2. 若真得跳轉,建議採用301或304的方式,讓使用者可以正常操作Back-Page
    12. 移除重複Script
      1. 雙重的負擔:下載次數變多,執行次數也變多
    13. 設定E-Tag
      1. E-Tag可以讓Browser或Proxy查知頁面資料是否有異動
      2. 針對Multi-server因為無法有效維持一致的E-Tag,反而造成系統負擔。此時建議改採 Last-Modified方式
    14. 讓AJAX也能被Cache
      1. Web 2.0也是需要加速的,上述的3、4、9、10、11、13、都可適用於 AJAX,尤其以第三點最重要,減少不必要的資料更新傳輸。
  • YSlow小工具
    1. 安裝於 Firefox的Plugin ( 需先安裝 Firebug )
  • 如何被YSlow評論為A級
    1. Flush the buffer early (Server)
      1. 當SERVER還在忙著處理資料時,就可以先讓Browser早些開始接收資料
      2. </HEADER>

        <BODY>
    2. Use GET for AJAX requests (Server)
      1. GET適合用於拿取資料,通訊次數比POST少
    3. Post-load components (content)
      1. 頁面資料並非一次就需提取完畢,部分的資訊可以先提供,其他的陸續抵達可提高使用者操作順暢度
      2. 善用JavaScript切割頁面資訊
    4. Preload components (content)
      1. 未來需要的資訊,利用AJAX的方式背景載入,減少使用者等待
      2. 自動輔助輸入也可採用此方法
    5. Reduce the number of DOM elements (content)
      1. 簡化HTML也就代表較小的檔案大小
    6. Split components across domains (content)
      1. 透過不同的domains可以加大資料平行載入的機會,但請勿超過2-4個Domain,減少DNS查詢的額外成本
    7. Minimize the number of iframes (content)
      1. iframe優點:容易整合外部頁面,平行載入,減少安全性問題
      2. 缺點:頁面處理成本高
    8. No 404s (content)
      1. 無效的存取
    9. Reduce cookie size (cookie)

    10. Use cookie-free domains for components (cookie)
    11. Minimize DOM access (javascript)
    12. Develop smart event handlers (javascript)
    13. Choose <link> over @import (css)
    14. Avoid filters (css)
    15. Optimize images (image)
    16. Optimize CSS sprites (image)
    17. Don’t scale images in HTML (image)
    18. Make favicon.ico small and cacheable (image)
    19. Keep components under 25K (moblie)
    20. Pack components into a multipart document (moblie)
  • ...

2008年3月26日 星期三

撐了那麼久,終於開始建立自己的Blog了.
不論如何,是個開始吧, 也算是值得慶祝 !
2008/03/26