頁數 2 / 2
上一頁
搜尋 110 結果：
HTML:
CSS:
CSS:
display: inline-block;
width: 160px;
}
.bbb li div{
width: 150px;
padding: 5px;
background: #ececec;
overflow: hidden;
-webkit-border-radius: 50%;
-moz-border-radius: 50%;
-ms-border-radius: 50%;
-o-border-radius: 50%;
border-radius: 50%;
}
.bbb li img{
width: 150px;
-webkit-border-radius: 50%;
-moz-border-radius: 50%;
-ms-border-radius: 50%;
-o-border-radius: 50%;
border-radius: 50%;
}
Safari OUTPUT:
aaa:
bbb:
<ul class="aaa">
<li><img src="http://placehold.it/150x150" /></li>
</ul>
<ul class="bbb">
<li><div><img src="http://placehold.it/150x150" /></div></li>
</ul>
CSS:
.aaa li{
display: inline-block;
width: 160px;
}
.aaa li img{
width: 150px;
border: 5px solid #ececec;
-webkit-border-radius: 50%;
-moz-border-radius: 50%;
-ms-border-radius: 50%;
-o-border-radius: 50%;
border-radius: 50%;
}
CSS:
.bbb li{display: inline-block;
width: 160px;
}
.bbb li div{
width: 150px;
padding: 5px;
background: #ececec;
overflow: hidden;
-webkit-border-radius: 50%;
-moz-border-radius: 50%;
-ms-border-radius: 50%;
-o-border-radius: 50%;
border-radius: 50%;
}
.bbb li img{
width: 150px;
-webkit-border-radius: 50%;
-moz-border-radius: 50%;
-ms-border-radius: 50%;
-o-border-radius: 50%;
border-radius: 50%;
}
Safari OUTPUT:
aaa:
bbb:
nelson, 2014/11/10 下午 03:48:03
今天網站升到 .Net Framework 4.0 時，突然有幾個頁面一執行就會load不停，並且造成 w3wp.exe 的CPU飆高。
經查詢之後發現，問題發生在執行SQL時；會load不停的頁面所呼叫的連線字串中，都將屬性Connection Timeout=0
，因此將Connection Timeout=0拿掉就好了。
<add key="xxxxxx" value="server={server};database={DB};uid={uid};pwd={pwd};Max Pool Size={size};Connection Timeout=0"/>
http://msdn.microsoft.com/zh-cn/library/system.data.oracleclient.oracleconnection.connectiontimeout(v=vs.110).aspx
所以在設定連線字串時，應避免將Connection Timeout設成0，否則會無限期的等待連接。
p.s. 很神奇的事是，在 .Net Framework 2.0 是正常的，但升成 4.0 後才會load不停，不知道為什麼。
經查詢之後發現，問題發生在執行SQL時；會load不停的頁面所呼叫的連線字串中，都將屬性Connection Timeout=0
，因此將Connection Timeout=0拿掉就好了。
<add key="xxxxxx" value="server={server};database={DB};uid={uid};pwd={pwd};Max Pool Size={size};
http://msdn.microsoft.com/zh-cn/library/system.data.oracleclient.oracleconnection.connectiontimeout(v=vs.110).aspx
所以在設定連線字串時，應避免將Connection Timeout設成0，否則會無限期的等待連接。
p.s. 很神奇的事是，在 .Net Framework 2.0 是正常的，但升成 4.0 後才會load不停，不知道為什麼。
candice, 2014/11/5 下午 06:56:48
半夜被老闆 Line，跟我說網頁發生錯誤，他無法看統計報表，會出現作業逾時的錯誤 我查了一下網頁程式，發現是這筆SQL指令跑太久
Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date
From V_Order_main With(Nolock)
Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14278))
AND Create_Date >= '2014/10/3' And Create_Date < '2014/10/12'
--> 跑了50秒~ 1分鐘
Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date
From V_Order_main With(Nolock)
Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14278))
--> 拿掉日期限制 > 秒殺， 結果跑出 47 筆資料
跑一下執行計畫 原來子查詢的 Ad_Trace 沒有建立Index造成
加上 Index 之後，再跑第一支SQL --> 秒殺
奇怪的地方:
明明訂單日期欄位(Create_Date) 跟 Ad_Trace 沒有多大關係，但是加上日期限制之後，居然會引發 Ad_Trace 搜尋過久的現象
他好像是先依照訂單日期找出所有訂單，然後再從子查詢 Ad_Trace 裡面搜尋有無符合的條件訂單
而不是先跑子查詢找出 Ad_Trace 所有的 Order_Id，再去找符合 Create_Date 的訂單
SQL內部運作的機制真是有點讓人想不透，幸好有評估計畫可以看出問題在哪裡
這讓我想起以前學SQL時的一句話 => 盡量用Join來取代子查詢
使用子查詢真的是效能殺手啊
------繼續補充--------------------------------------
上面的SQL在雙11活動後，由於當日訂單過多，一樣造成SQL timeout 的現象，研判還是子查詢造成的問題
Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date
From V_Order_main With(Nolock)
Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14720))
And Create_Date > '2014-11-10' And Create_Date < '2014-11-11'
--> 跑了51秒
所以先將子查詢拿出來跑出一串字串 865828,865890,865901,865903,865928,865955,865990,865993,866005,866035.....
(共1452筆)
再把他拼入sql跑 --> 7秒
darren, 2014/10/11 上午 09:58:18
一直覺得 UW.Template 應該還有改善的空間，因為網站大量使用這個物件
只要有一些些效能調教，對於整體效能應該有很大的幫助
昨天發現切版的程式 UW.Template => GetTemplateFromString
在使用 IndexOf 去尋找 <!--Key S--> 及 <!--Key E--> 時，
<!--Key E--> 可能有一些問題，因為他是從第0個位置開始找
而實際上他應該是從 <!--Key S--> 後面開始找比較對
所以後者的 IndexOf 要加個 StartIndex 參數值比較對
另外 我也針對 StringComparison 做一些測試
然後以一個 20KB 的 html 去抓出 <!--Content E--> 的位置
測試結果如下 (StartP 是 <!--Content S--> 後的起始位置)
結論:
1. IndexOf 預設是以 StringComparison.CurrentCulture 方式尋找字串
2. 對於大塊字串，請盡量用 StartP 去找結束標籤位置，這樣速度會快很多，因為少爬了一段文字，此範例是差了2.5倍
3. 對於大塊字串，除非大小寫都要找，不然盡量用 StringComparison.Ordinal 來尋找字串，速度差了7~8倍
微軟對於.NET字串處理 有一篇建議文章，請大家拜讀一下
http://msdn.microsoft.com/zh-tw/library/vstudio/dd465121(v=vs.100).aspx
只要有一些些效能調教，對於整體效能應該有很大的幫助
昨天發現切版的程式 UW.Template => GetTemplateFromString
在使用 IndexOf 去尋找 <!--Key S--> 及 <!--Key E--> 時，
<!--Key E--> 可能有一些問題，因為他是從第0個位置開始找
而實際上他應該是從 <!--Key S--> 後面開始找比較對
所以後者的 IndexOf 要加個 StartIndex 參數值比較對
StartP = StartP + StartKey.Length
Dim EndP As String = Source.IndexOf(EndKey, StringComparison.OrdinalIgnoreCase)
' 應該修改為以下寫法 =>
StartP = StartP + StartKey.Length
Dim EndP As String = Source.IndexOf(EndKey, StartP, StringComparison.OrdinalIgnoreCase)
另外 我也針對 StringComparison 做一些測試
然後以一個 20KB 的 html 去抓出 <!--Content E--> 的位置
測試結果如下 (StartP 是 <!--Content S--> 後的起始位置)
0.0005085 No StartP
0.0002082 with StartP
0.0000157 StringComparison.Ordinal with StartP
0.0002768 StringComparison.OrdinalIgnoreCase, No StartP
0.0001105 StringComparison.OrdinalIgnoreCase with StartP
0.0002116 StringComparison.CurrentCulture with StartP
0.0002085 StringComparison.CurrentCultureIgnoreCase with StartP
結論:
1. IndexOf 預設是以 StringComparison.CurrentCulture 方式尋找字串
2. 對於大塊字串，請盡量用 StartP 去找結束標籤位置，這樣速度會快很多，因為少爬了一段文字，此範例是差了2.5倍
3. 對於大塊字串，除非大小寫都要找，不然盡量用 StringComparison.Ordinal 來尋找字串，速度差了7~8倍
微軟對於.NET字串處理 有一篇建議文章，請大家拜讀一下
http://msdn.microsoft.com/zh-tw/library/vstudio/dd465121(v=vs.100).aspx
darren, 2014/1/14 下午 03:18:14
1. 在要匯出的 DB 上, 按右鍵, 選取工作 --> 產生令碼.
2. 歡迎頁
3. 選取資料庫
4. 設定選項, 記得要選取 "編寫資料的指令碼"
5. 選取資料表
6. 選擇要匯出的資料表
7. 指定 Script 要儲存的位置
8. 檢視摘要
9. 完工
2. 歡迎頁
3. 選取資料庫
4. 設定選項, 記得要選取 "編寫資料的指令碼"
5. 選取資料表
6. 選擇要匯出的資料表
7. 指定 Script 要儲存的位置
8. 檢視摘要
9. 完工
Bike, 2012/6/19 上午 11:11:33