今天因為一個客戶的專案, 試了一下用 Entity Framework 把 Store Procedure 包成一個 function. 被卡了一下, 發現要先 Compile  才會看到新增的 function,  記錄一下, 希望看到的人能省點時間 .....

1. 從資料庫更新模型


2. 選擇要匯入的 Store Procedure


3. 完成匯入匯入後, function 並不會生出來. 
 
 4. Compile 之後, 才會看到這個 function.
 
 


 

好像為了這個找了很多次 google, 每次都花了不少時間..

1. 新增功能角色
 
2. 新增管理服務
 
3. 安裝 Web Deploy 套件 
https://www.iis.net/downloads/microsoft/web-deploy

4. 完工..

參考: https://stackoverflow.com/questions/41386690/missing-import-web-application-option-in-web-deploy-3-6

AddPageDebugMessage 造成購物車變慢.

因為有發現主要時間是花在 Coupon 的處理, 研突了半天, 覺得之前丟出來的 Debug 訊息太多, 所以我想把所有 coupon 處理時丟出來的 Debug 訊息關掉, 一個一個慢慢打開來看看哪一個步驟造成問題. 突然發現它就好了.

後來想想, 應該是因為我們把 Debug 訊息合併成大字串造成的, 這個花費的總時間會以 coupon 數量的平方或三次方的速度成長.  當 Coupon 的數量變多時, 花費的時間會成長的很快. 因為要夠多上線的 coupon 才會造成這個問題, 所以之前的測試都沒有發現這類的問題.

購物車中有用到 AddPageDebugMessage 請改成成使用  arraylist 的版本. 理論上會是固定時間, 另外還有做了一個開關, 要用定參數才會開啟 AddPageDebugMessage 的功能.

這兩天發現的現象。有點不好找錯，所以紀錄一下
因為制式報名頁面使用 ajax form 物件，但 ios 的 safari 一直發生資料有送出，
但是送出後網頁就不跑success後面的 javascript，例如彈跳訊息及導到下個頁面
一開始debug的方向有點猜錯，所以花了點時間找問題
後來才注意到，原來他跑到 ajax error去了，不是 ajax success
直覺可能是 ContentType 的問題，因為預設是 text/html
結果 Response.ContentType 改 application/x-javascript, 就過了  (WTF)
我猜 application/json 應該也沒問題吧
------------------------------
經查證: application/json 比較正確 



 

注意事項 (為避免產出結果和預期有重大差異, 請詳讀以下內容):

1. 若後台有使用 HTML 編輯器, 以 CKEditor 現有功能為準. 編輯器所見內容和前台實際內容可能有差異, 此為無法避免之情況, 請僅慎使用, 建議以文字模式編輯, 以避免跑版.
2. 驗收以 Chrome, IE, Safari, Firefox 結案時間的最新兩個版本為準(IE 目前為 IE Edge 及 IE 11). 手機以前 10 大廠牌兩年內出版的手機為準.
3. Android 手機僅測試 Chrome, IOS 手機僅測試 Safari. 其它手機預設瀏覽器或 APP 內建流覽器不包括在驗收範圍之內.
4. 若需要文件, 除報價有說明外, 應另外計費, 若合約中包括程式檔案說明, 僅限我方建立之程式檔案, 引用之公開套件不另做文件說明.
5. 若客戶要求資安弱點掃瞄, 或通過特別認証, 應另外計費.
6. 本公司盡力維護程式品質, 但無法保証無 Bug, 上線前請完整測試. 若上線後才發現之 Bug, 本公司僅負責修復, 無法提供額外賠償.
7. 主機代管限制
    圖檔以經 Cloudfalre 為準. 若需更高品質可代為申請 amazon 的 CDN 服務.
    Email 不保証送達, 若需更高品質可代為申請 amazon 的 SES 服務.
    每月 1000 張訂單為限, 超過後要另外計算費用.
8. 網站代管, 資料備份以一天一次為準, 如需增加頻率, 另外協議後計價.
9. 搜尋建議使用 Google 的 site search(但偶爾會有廣告, 出現機率很小), 若要自行客製, 合約未明確規定時, 以各單元分開搜尋為準, 例如產品及新聞的搜尋結果會分成兩個搜尋結果頁面, 排序為依等定欄位排序, 比對方式為所輸入的文字明確比對.

由於早期網站都是VB.net寫的，若是直接換成 C#，就會耗費很多時間在轉換程式上
因此 ASP.NET 特別可以在同一網站同時寫 vb 跟 C#，方式是在 web.config compilation 加上設定

    <compilation debug="true" defaultLanguage="c#" targetFramework="4.0">

     <codeSubDirectories>

        <add directoryName="VB_Code"/>

        <add directoryName="CS_Code"/>

     </codeSubDirectories>

    </compilation>

也就是 VB.NET 的 code 就放到 ~\APP_Code\VB_Code 目錄
C# 的 code 就放到 ~\APP_Code\CS_Code 目錄
這樣做有兩點要注意
1.  Namespace 的命名，最好不要互相衝突, 要能夠區分出來
2.  VB_Code 與 CS_Code 放的位置有很大的影響, 因為牽涉到 compiler的先後順序，因為 VB_Code 在 CS_Code 在前面，所以 CS_Code可以叫用 VB_Code下的程式，但是 VB_Code 卻不能叫用 CS_Code 的程式，如果希望 VB_Code可以叫用 CS_Code的程式，就把設定換過來

    <compilation debug="true" defaultLanguage="c#" targetFramework="4.0">

     <codeSubDirectories>

        <add directoryName="CS_Code"/>

<add directoryName="VB_Code"/>

     </codeSubDirectories>

    </compilation>

缺點就是反過來 CS_Code不能使用 VB_Code的程式

基本上，若是舊的程式碼都在VB_Code 那就把 VB_Code 放到前面

2016 / 10 / 30 搬機房, 有幾件事沒有做好, 記錄一下:

1. Firewall 沒設定好, 下次要一中兩個人一起設定.

2. 有一個客戶的 DNS 等了一整天才生效, 要檢查所有網站的 TTL 和  Refresh 時間, 最好都在一個小時以內.

3. Email 主機: 有些客戶原來是用 msa.hinet.net 這個 SMTP, 搬到非 Hinet 的機房後就不能寄信了.

4. 某一個客戶的 DNS 沒改好, 因為在自已的 DNS Server 上面看到有記錄, 就誤判是我們代管的, 應該要用 Hinet 或 Google 來確認 NS Record 為何. 已刪除它的 DNS  記錄.

5. 202 的 .8 網路線沒插好, 主機開起來後, 要確認可以從每一個介面 Ping 出去.

6. 新 Firewall , 內部 IP 無法連到 Virtual Server: --> 要由內部 IP 連線到 Virtual Server 測試. 最好是在 hosts 上面都有 127.0.0.1 的設定.

7. 最好不要在下半年換機房, 比較忙, 客戶的活動也比較多.

8. Windows 的 DNS 若是直接修改 DNS 檔案. 因為 SOA 的序號沒有修改, 所以 Client 伺服器要手動重新讀取資料.

9. 要記得改 TWNIC 的 DNS Server設定.

對於網頁加速的問題，已經被廣泛的討論了
主要在於減少 request 數以及減低網路傳輸的時間
也因此發展出一些技巧或技術，例如 css sprite, 資料gzip 等
瀏覽器也把連線數限制從2條變成6條，以加快網頁顯示的速度
然而若要網頁能有本質上的提升，則是該把 HTTP 這個老通訊協定升級了
(目前是HTTP/1.1, 1999年)

由Google Chrome推廣的 SPDY 標準，已經改良並訂為 HTTP/2 的標準 (2015年初定案)
他的重點在於 (如果我理解得沒錯的話，歡迎指正)
1. http header 也可壓縮 (HTTP1.1 header 無法壓縮)
2. 一個 connection 可以傳輸多個Content (HTTP1.1 一個request 一個 content)
3. 可以 Server Push 資料
4. 可以向下相容 1.1
實測上，可以讓網頁載入速度提升約 30%

目前，大部分瀏覽器已經支援 HTTP/2 標準，然而 Server 端的步調就緩慢許多
微軟的 IIS 要到 10 才支援，目前只有 windows 10 才有
Windows Server則要明年 2016 才有支援
相反於微軟，其他非微軟的開發速度上就快多了 例如 Node.js

---------------------------------------------------------
測試上，可以用 Chrome 的開發模式 把 protocol 欄位勾選顯示



h2 就是 http/2

自從 8/1 起 shopunt 就呈現奇怪的現象



基本上是每日半夜12點流量暴增 (peak 到 80mb)，然後逐漸下降，到了 5~6點又慢慢爬升，直到 10 點以後就驟降

基本上，網站沒有掛掉，沒有太多Exception，LB兩台server的流量很平均，Server Diff 查也沒有過多的Session
可以排除被攻擊的可能性

為了找問題，只好從 IIS Log著手......
1. 首先，查詢12點有甚麼網頁或網址異常多點擊數，並且比較 11 點與 12點兩者差異，結果都沒有任何異常
    卻意外發現有家廣告合作廠商半夜會來抓產品圖，只是這個流量不大，發生點也不是在12點整，不是兇手
2. 起先因為 IIS log 沒有設定 sc-bytes 這個屬性，只有 time-taken 屬性，發現有些圖片 load 的特別久，但還是無法確定問題，所以想說把 sc-bytes 加到 IIS log 再來觀察
3. 加了 sc-bytes 之後的 IIS log，才發現驚人的事實，有幾張圖片竟然高達好幾MB，最大張是放在周年慶的 landing 圖片，竟高達 7.8MB



光1小時，一張圖片吃掉 8.6GB 的量，換算平均值約 13 mb/sec , OMG!
趕緊請設計把圖片換掉

只是這樣，還是有一個奇怪現象，為何半夜12點流量暴增，早上 10 點流量驟減?


這是禍首最大張圖片的點擊數統計(時間是GMT，16是半夜12點, 15是晚上11點)，
就跟流量圖一樣，00~10 點擊數很高，其他時間很低
下面是這張圖片所屬頁面的點擊數統計 (/tch/fixpage.aspx?id=689)



從圖片點擊數看來，我以為是 ISP 某種 transparent proxy cache 發揮作用 (半夜 00~10點關閉 所以流量增加)，
但是看到 fixpage.aspx 的點擊數也是一樣的狀況，我就不知道該怎麼解釋了??
ISP transparent proxy 也會處理 *.aspx ?? 

還是回歸到最基本的原因，網站的廣告曝光量是 00~10點最高??

 

又發現新說法

我們在 front-end 做 scroll event的監聽的時候很常會過度的觸發要執行的事情，因此導致效能不太佳，
我們需要的是固定頻率執行某個function ， 這個原來叫 throttle

另外一種狀況像是autocomplete，不需要每一個keyup 都去ajax 去backend 抓資料回來，所以我們過去，
設一個變數去記住setTimeout 回傳回來的數字，如果下一次的keyup 發生在預設的時間內就去把 setTimeout清掉。
原來這種做法，有一個稱呼叫 debounce

不過jQuery 沒有內建這兩個function。這樣在複雜的 js 中增加易讀性。