tag:blogger.com,1999:blog-192538692024-03-08T14:57:08.936+08:00Gea-Suan Lin's BLOG for NetworkingGea-Suan Lin's BLOG for NetworkingGea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.comBlogger29125tag:blogger.com,1999:blog-19253869.post-33481653082341442582013-01-30T12:48:00.002+08:002013-01-30T12:48:45.590+08:00CDNetworks 的 DNS 服務 PoP...<div class="separator" style="clear: both; text-align: left;">
Cloud DNS 的服務上看到的,純粹是想貼圖而已:</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
</div>
<div class="separator" style="clear: both;">
<a href="http://i.imgur.com/mL5Fg2C.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://i.imgur.com/mL5Fg2C.png" /></a>台北的點在 <a href="http://www.tfn.net.tw/">TFN</a>,不過這是 Cloud DNS 服務而已 (Anycast),CDN 的部份要另外看買到的等級...</div>
Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com1tag:blogger.com,1999:blog-19253869.post-68793278995142624252012-10-03T16:59:00.003+08:002012-10-03T16:59:31.489+08:00奇怪的 CDN 廠商...有些 CDN 看起來就怪怪的,列一下好了...<br />
<br />
<ul>
<li><a href="http://www.cachefly.com/">CacheFly</a>,亞洲的 PoP 偶而會消失...</li>
<li><a href="http://www.cdn77.com/pricing">CDN77</a>,沒有 network topology 的概念,最誇張的時候會走地表最近路線... (於是從美國到歐洲再到中東的 PoP)</li>
<li><a href="http://www.netdna.com/">NetDNA</a>,官方網站放在 <a href="http://www.linode.com/">Linode</a> 上面。同公司的 <a href="http://www.cloudcache.com/">CloudCache.com</a>、<a href="http://www.maxcdn.com/">MaxCDN</a> 以及 <a href="http://www.hddn.com/">HDDN</a> 都是放在 Linode 上。</li>
</ul>
<div>
這些公司不知道是怎麼樣...</div>
<div>
<br /></div>
<div>
反倒是期待 Linode 出 CDN 業務,不知道有沒有機會...</div>
Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com2tag:blogger.com,1999:blog-19253869.post-59367423276226557092012-06-25T00:05:00.003+08:002012-06-25T00:05:32.548+08:00測試 CDN77.com昨天亂找資料的時候發現 <a href="http://www.cdnplanet.com/">CDN Planet</a> 列了不少提供 CDN 的公司,其中剛好看到 <a href="http://www.cdn77.com/">CDN77</a> 這家價位很吸引人的 CDN...<br />
<br />
Free trial 提供 14 天內 100GB 的服務,測了半個小時就決定先丟 USD$30 進去慢慢玩...<br />
<br />
到現在為止測試還不到 24hr 吧,但覺得這真是一家架構上超有趣的公司... Latency 很明顯不行,可能會先拿來當作大檔案的備援頻寬用吧?<br />
<br />
台灣時間星期天早上八點測試:<br />
<br />
<ul>
<li>Origin Server 放在 HiNet Colocation。</li>
</ul>
<div>
台灣測試的結果是:(依照速度排)</div>
<ul>
<li><span style="background-color: white;">HiNet colocation (馬來西亞 PoP),510KB/sec。</span></li>
<li><span style="background-color: white;">NCTU (馬來西亞 PoP),470KB/sec。</span></li>
<li>NCCU (馬來西亞 PoP),430KB/sec。</li>
<li>SEEDNet colocation (馬來西亞 PoP),250KB/sec。</li>
<li><span style="background-color: white;">HiNet 光世代 12M/3M 會分配到馬來西亞的 PoP,240KB/sec。</span></li>
<li><span style="background-color: white;">TFN (比利時 PoP,這哪招),220KB/sec。</span></li>
</ul>
<div>
國外的部分只測了日本 Linode:</div>
<div>
<ul>
<li>Linode (馬來西亞 PoP),380KB/sec。</li>
</ul>
<div>
寫信去問日本與香港的 PoP 怎麼不見了,你把台灣導去馬來西亞就算了,日本怎麼也導去馬來西亞啊,回答居然是「今天剛開始維修」XDDD</div>
<div>
<br /></div>
<div>
另外就是問他可不可以建立 US & EU only,得到的答覆是正面的,他們的機制可以選擇不提供某些 CDN PoP。不過還沒測過...</div>
<div>
<br /></div>
<div>
除了 US & EU only 外,接下來要測三家業者的 3G 下載速度與 secure content 的部分,如果這功能沒問題的話就可以當備援頻寬了...</div>
<div>
<br /></div>
<div>
<span style="background-color: white;">同場加映 webhostingtalk 上的討論:</span></div>
</div>
<div>
<ul>
<li><span style="background-color: white;"><a href="http://www.webhostingtalk.com/showthread.php?t=1160618">CDN 77 - the latest in the market</a></span></li>
</ul>
<div>
反正這 CDN 還蠻有趣的就是了 XD</div>
</div>Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-16924096904176229422012-02-28T20:37:00.000+08:002012-02-28T20:37:41.536+08:00Limelight Networks 換網址...<p><a href="http://www.limelight.com/">Limelight Networks</a> 把官方網頁的網址換掉了,好像換一陣子了...</p>
<p>先前是 <code>www.limelightnetworks.com</code>,現在是 <code>www.limelight.com</code>,另外有 <code>llnw.com</code> 在他們手上,不知道會不會也拿出來用...</p>Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-47869319419585233562011-10-15T06:01:00.000+08:002011-10-15T06:01:11.822+08:00Akamai 與 CDNetworks...<p>這幾天在 CDN 產業裡面兩個比較大的大消息,一個是 <a href="http://www.kddi.com/">KDDI</a> 丟出打算併購 <a href="http://www.cdnetworks.com/">CDNetworks</a> 的消息。另外一個是傳言 <a href="http://www.google.com/">Google</a> 要併購 <a href="http://www.akamai.com/">Akamai</a>。</p>
<p>前者的消息已經確認 (<a href="http://www.foxbusiness.com/technology/2011/10/12/kddi-to-buy-cdnetworks-to-ensure-smooth-internet-access-kyodo/">KDDI to Buy CDNetworks to Ensure Smooth Internet Access: Kyodo</a>),後者 Google 則是否認這則消息 (<a href="http://www.bloomberg.com/news/2011-10-12/google-is-said-not-to-plan-akamai-takeover-after-report-raised-speculation.html">Google Is Said Not to Be Planning to Acquire Akamai Technologies Business</a>)。</p>
<p>不過 CDN 技術愈來愈成熟,就愈來愈像賣頻寬的公司...</p>Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-41277843115382253652011-09-25T20:54:00.002+08:002011-09-25T20:54:53.641+08:00歐亞網路 (香港到倫敦) 的 latency在 <a href="http://slashdot.org/">Slashdot</a> 上看到歐亞網路 (香港到倫敦) 的 latency 又降低 20ms 了:「<a href="http://news.slashdot.org/story/11/09/25/0113245/low-latency-network-shaves-milliseconds-from-uk-asia-traffic">Low-Latency Network Shaves Milliseconds from UK-Asia Traffic</a>」、「<a href="http://www.eweekeurope.co.uk/news/low-latency-network-to-connect-london-and-hong-kong-40545">Low-Latency Network To Connect London And HK</a>」。<br />
<br />
主要的改善是來自於本來走西伯利亞的線路,現在改走蒙古... 不知道友沒有其他更低的線路... :oGea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com1tag:blogger.com,1999:blog-19253869.post-32861581020446587462011-09-25T20:54:00.000+08:002011-09-25T20:54:33.444+08:00在 <a href="http://slashdot.org/">Slashdot</a> 上看到歐亞網路 (香港到倫敦) 的 latency 又降低 20ms 了:「<a href="http://news.slashdot.org/story/11/09/25/0113245/low-latency-network-shaves-milliseconds-from-uk-asia-traffic">Low-Latency Network Shaves Milliseconds from UK-Asia Traffic</a>」、「<a href="http://www.eweekeurope.co.uk/news/low-latency-network-to-connect-london-and-hong-kong-40545">Low-Latency Network To Connect London And HK</a>」。<br />
<br />
主要的改善是來自於本來走西伯利亞的線路,現在改走蒙古... 不知道友沒有其他更低的線路... :oGea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-1883405781729891042011-05-18T04:39:00.001+08:002011-05-18T04:39:35.604+08:00www.ipv6.org.tw 的品質...不知道最近在做什麼大事業,從台灣固網提供的 IPv6 native network 過去:<br />
<pre>gslin@ipv6-test [~] (4:37) sudo ping6 -c 10 -i 0.2 www.ipv6.org.tw
PING6(56=40+8+8 bytes) 2001:4541:0:5:2e0:81ff:feb0:ddc3 --> 2001:c50:ffff:1:21a:92ff:fe43:d665
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=0 hlim=56 time=112.814 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=1 hlim=56 time=137.987 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=2 hlim=56 time=107.889 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=3 hlim=56 time=114.263 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=4 hlim=56 time=101.525 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=5 hlim=56 time=118.025 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=6 hlim=56 time=100.039 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=7 hlim=56 time=113.664 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=8 hlim=56 time=146.900 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=9 hlim=56 time=124.038 ms
--- www.ipv6.org.tw ping6 statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 100.039/117.714/146.900/14.235 ms</pre>然後用 IPv4 過去:<br />
<pre>gslin@ipv6-test [~] (4:37) sudo ping -c 10 -i 0.2 www.ipv6.org.tw
PING www.ipv6.org.tw (210.17.9.228): 56 data bytes
64 bytes from 210.17.9.228: icmp_seq=0 ttl=57 time=111.309 ms
64 bytes from 210.17.9.228: icmp_seq=1 ttl=57 time=117.711 ms
64 bytes from 210.17.9.228: icmp_seq=2 ttl=57 time=90.354 ms
64 bytes from 210.17.9.228: icmp_seq=3 ttl=57 time=122.724 ms
64 bytes from 210.17.9.228: icmp_seq=4 ttl=57 time=132.470 ms
64 bytes from 210.17.9.228: icmp_seq=5 ttl=57 time=92.495 ms
64 bytes from 210.17.9.228: icmp_seq=6 ttl=57 time=114.230 ms
64 bytes from 210.17.9.228: icmp_seq=7 ttl=57 time=135.975 ms
64 bytes from 210.17.9.228: icmp_seq=8 ttl=57 time=121.982 ms
64 bytes from 210.17.9.228: icmp_seq=9 ttl=57 time=93.132 ms
--- www.ipv6.org.tw ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 90.354/113.238/135.975/15.608 ms</pre>是怎麼了 @_@Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-49059849991996536612011-04-11T20:53:00.000+08:002011-04-11T20:53:47.504+08:00Level 3 以 30 億美金的股票買下 Global Crossing<a href="http://www.level3.com/">Level 3</a> 與 <a href="http://www.globalcrossing.com/">Global Crossing</a> 這兩家在全世界都是屬於超大 ISP (兩個都是 <a href="http://en.wikipedia.org/wiki/Tier_1_network">Tier 1 network</a>,而且都有在 <a href="http://www.nasdaq.com/">NASDAQ</a> 掛牌)。<br />
<br />
今天這兩家公司往 <a href="http://www.sec.gov/">SEC</a> 丟申請,Level 3 準備以價值 USD$3B 的股票買下 Global Crossing... (拉椅子看好戲啊)Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-16273460633494089882010-11-19T21:57:00.001+08:002010-11-19T21:57:09.618+08:00CDN<p>很久沒寫這個 blog 了,來清理一下以免草長太長 XD</p> <p>這兩年實際用過不少家 CDN 了,包括一開始的 Panther Express (後來被 <a href="http://www.cdnetworks.com/">CDNetworks</a> 併購),後來也跟 <a href="http://www.edgecast.com/">EdgeCast</a> 租用,接下來是 <a href="http://aws.amazon.com/cloudfront/">AWS CloudFront</a> 的出現,再來是跟 <a href="http://www.akamai.com/">Akamai</a> 租用。</p> <p>其實很多單位都只是把 CDN 當作是一種 cache server 的服務,目的只是減少維護的成本,以及提高穩定性。一堆 CDN 業者吹捧的那些功能其實都只是附加的,甚至連 CDN 最重要的 latency issue,大多數的客戶根本不在乎。</p> <p>既然只是當作 HA cache server,這項技術其實不難,用兩台 HAProxy 當作 Load balancer (約 NTD$0.1M) 加上兩台 <a href="http://www.squid-cache.org/">Squid2</a> (約 NTD$0.5M),以這幾年的 CPU 與 RAM 在 NTD$0.6M 內就可以打死。實際流量大約可以跑出 300Mbps+。</p> <p>如果改用 <a href="http://www.lusca.org/">Lusca</a> (就 Squid2 的設定檔稍做修改就可以跑,或是參考網路上很多 Squid 的文件,門檻比較低),大約可以跑到 600Mbps+。如果可以用 <a href="http://trafficserver.apache.org/">Traffic Server</a>,那麼幾乎就是壓榨出硬體極限 (就目前看起來跑 1Gbps+ 應該沒問題)。</p> <p>如過遇到大量的量衝進來時,反而會因為 cache 集中性高,幾乎都是 memory hit 而不太會影響效能。</p> <p>在這麼低的一次性資本支出成本下,國內的客戶在找 CDN 談的時候幾乎都是當作頻寬費用在談。事實上也的確應該當作頻寬費用在談就好,不需要被 sales 催眠以為那些進階功能很好用。</p> <p>國內目前有經銷商的有 Akamai 與 EdgeCast。我建議在台灣都不要跟這兩家經銷商談。</p> <p>Akamai 是由<a href="http://www.jforce.com.tw/">併力科技</a>代理,不跟他們談的原因有兩個:</p> <ol> <li>Akamai 的優點在於他的密度,這是要在自己網站把所有最佳化都做到底以後才看的出來比其他 CDN 好。國內的網站都沒有能力做到這點。</li> <li>Akamai 的台灣是唯一經銷商,而這家經銷商的態度很強勢。就每次開會與解決問題的觀感並不好。</li> </ol> <p>EdgeCast 在台灣則是<a href="http://www.ade.com.tw/">怡德</a>。我們當初跟 EdgeCast 接觸的時候是直接跟國外原廠接觸。怡德是後來代理的公司,這家公司在代理之前跟網路內容產業根本沒關係,代理後也有跑來找我們談,我的建議是「能直接跟 EdgeCast 原廠聯絡就直接聯絡」。</p> <p>有機會再看看還能聊什麼...</p> Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com2tag:blogger.com,1999:blog-19253869.post-39285807582839499752008-11-23T19:13:00.000+08:002008-11-23T19:16:28.881+08:00從台固到 www.ru從台灣 NTT 到日本,再到美國,再到英國,然後轉進俄羅斯:<br /><blockquote><code>traceroute to www.ru (194.87.0.50), 64 hops max, 52 byte packets<br />1 gw-60-199-247-254.pixnet.tw (60.199.247.254) 0.673 ms 0.471 ms 0.492 ms<br />2 60-199-248-49.static.tfn.net.tw (60.199.248.49) 0.486 ms 0.477 ms 0.491 ms<br />3 60-199-255-113.static.tfn.net.tw (60.199.255.113) 0.239 ms 0.227 ms 0.241 ms<br />4 60-199-6-125.static.tfn.net.tw (60.199.6.125) 0.364 ms 0.354 ms 0.366 ms<br />5 60-199-6-2.static.tfn.net.tw (60.199.6.2) 6.235 ms 0.480 ms 0.364 ms<br />6 60-199-6-222.static.tfn.net.tw (60.199.6.222) 0.625 ms 0.479 ms 0.589 ms<br />7 61.58.33.189 (61.58.33.189) 0.697 ms<br /> 61.58.33.145 (61.58.33.145) 0.607 ms 0.606 ms<br />8 xe-1-0-0.r21.taiptw01.tw.bb.gin.ntt.net (129.250.16.169) 0.864 ms 0.728 ms 0.740 ms<br />9 as-2.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.4.81) 31.596 ms 31.720 ms 31.713 ms<br />10 ae-3.r21.osakjp01.jp.bb.gin.ntt.net (129.250.4.214) 74.068 ms 40.205 ms 40.090 ms<br />11 as-1.r21.sttlwa01.us.bb.gin.ntt.net (129.250.3.87) 133.416 ms 133.520 ms 133.534 ms<br />12 as-1.r20.nycmny01.us.bb.gin.ntt.net (129.250.3.191) 221.853 ms 221.841 ms 221.855 ms<br />13 as-1.r22.londen03.uk.bb.gin.ntt.net (129.250.3.255) 298.929 ms 295.420 ms 295.305 ms<br />14 xe-4-4.r01.londen03.uk.bb.gin.ntt.net (129.250.2.66) 289.934 ms 289.922 ms 293.930 ms<br />15 * * *<br />16 transtelecom-0.r01.londen05.uk.bb.gin.ntt.net (83.231.146.86) 355.979 ms 357.880 ms 377.121 ms<br />17 demos-gw.transtelecom.net (217.150.57.89) 350.517 ms 354.882 ms 350.527 ms<br />18 iki-c1-vl10.demos.net (194.87.0.111) 355.508 ms 354.507 ms 352.039 ms<br />19 www.ru (194.87.0.50) 352.881 ms 351.010 ms 351.147 ms</code></blockquote><br />日本到俄羅斯居然這麼遠...Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com2tag:blogger.com,1999:blog-19253869.post-78004892844623028032008-09-04T07:55:00.001+08:002008-09-04T08:09:03.421+08:00DNS server 與 AS昨天 <a href="http://www.bsdchat.com/">#bsdchat</a> 剛好在討論 tw.freebsd.org 的 NS server 的事情。目前很多 freebsd.org 的 subdomain 都只有在當地,像是日本、南韓、德國:<br /><blockquote><pre>jp.freebsd.org. 3600 IN NS ns3.imgsrc.co.jp.<br />jp.freebsd.org. 3600 IN NS castle.jp.freebsd.org.<br />jp.freebsd.org. 3600 IN NS asuka.jp.freebsd.org.<br /><br />kr.freebsd.org. 86400 IN NS ns.ziom.co.kr.<br />kr.freebsd.org. 86400 IN NS ns2.ziom.co.kr.<br /><br />de.freebsd.org. 10771 IN NS ns.cs.tu-berlin.de.<br />de.freebsd.org. 10771 IN NS baerenklau.de.freebsd.org.</pre></blockquote>這其實對於 DNS 架構來說,並不是很好的設計。比較好的設計是放到不同地區 (不同洲),確保不會一起掛掉。<br /><br />主要的原因在於有些服務會對「查不到 DNS record」很敏感,像是 mail system:<br /><ol><li>對於 username@tw.freebsd.org 的人,發信時如果找不到 tw.freebsd.org 的 MX 與 A record,被認定是 spam 的分數會上升。</li><li>對於寄信到 username@tw.freebsd.org 的人,如果找的到 MX 或是 A record,但連不到 mail server,那麼這封信會被保留在 mail system 裡面。但如果找不到,會馬上被退信。</li></ol>所以,要避免大停電或是大斷線影響其他系統,應該要儘量把 NS server 放到不同地區,不同 AS# 的網路上。Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com1tag:blogger.com,1999:blog-19253869.post-64992846458086934982008-09-03T07:23:00.000+08:002008-09-03T07:52:53.945+08:00國內的網路,與 CDN前陣子跟一堆老外們談 <a href="http://en.wikipedia.org/wiki/Content_delivery_network">CDN</a> 服務,計費方式還蠻彈性的,常見的兩種包括以實際流量計算,或是 MRTG 五分鐘圖 sorting 95% 流量計算。<br /><br />不過,值得提出來的,CDN 的價錢比起國內的頻寬都便宜。以 <a href="http://www.slideshare.net/">Slideshare</a> 這個站公開的數據來看 (<a href="http://www.jonathanboutelle.com/mt/archives/2008/05/s3_cdn_faster_s.html">Panther Express and S3</a>),每個月重新計算,第一個 8TB 是 USD$0.28/GB,第二個 8TB 是 USD$0.24/GB。<br /><br />如果網站有區域性,100Mbps (MRTG 五分鐘圖 sorting 95% 計算方式) 大約是 20TB/month,照比率計算,第一個 8TB 換算成 sorting 95% 是 40Mbps 的量,也就是 NTD$1764/Mbps。這個價錢如果在國內的 ISP 只買 40Mbps,在不靠關係,又要有一定的網路品質,是不可能的數字...<br /><br />以目前來看,把靜態檔案丟到 <a href="http://aws.amazon.com/s3">Amazon S3</a> 上,以 reverse proxy CDN 算是相當好的方式。<br /><br />對了,國外的 CDN 大多都有提供試用的服務,跟 sales 要求,通常都有測試的機會。<a href="http://en.wikipedia.org/">Wikipedia</a> 上的 <a href="http://en.wikipedia.org/wiki/Content_delivery_network">Content delivery network</a> 這個條目下面列的公司都可以寫信去問看看。Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-45031239943100461802008-09-02T07:36:00.001+08:002008-09-02T07:47:37.974+08:00寫自己的 PHP Controller我對於 <a href="http://framework.zend.com/">Zend Framework</a> 的 <a href="http://framework.zend.com/manual/en/zend.controller.html">Zend_Controller</a> 實在是搞不太懂,要求使用 <a href="http://www.php.net/">PHP5</a>,但又沒用到 PHP5 的特性...<br /><br />我理想中的 Controller 是透過 PHP5 的 ArrayAccess 實做這樣的效果的:<br /><blockquote><code>$name = $c['name'];<br />$c['Content-Type'] = 'text/plain; charset=UTF-8';</code></blockquote><br />我花了點時間開始寫自己的 Controller,希望善用 PHP5 語言特性使得寫起來比較方便,順便玩玩 <a href="http://www.selenic.com/mercurial/">Mercurial</a> 的操作方式。<br /><br />目前 Repository 放在 <a href="http://freehg.org/">freeHG</a> 上:<a href="http://freehg.org/u/gslin/hasname-controller/">Hasname Controller</a>,有想要看看到底是怎麼搞的人可以自己 clone 回去看,等之後功能比較完整後再開始來寫文件。Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-16824499247483465752008-09-02T07:33:00.000+08:002008-09-02T07:36:28.550+08:00太久沒到這邊來寫 blog...太久沒寫 Blog 反而被標上 Spam Blog?XD (寫文章需要 CAPTCHA)Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-1148849083819892182006-05-29T04:44:00.000+08:002006-05-29T04:44:43.830+08:00FreeBSD 上 rpc.lockd 的問題<a href="http://www.freebsd.org/">FreeBSD</a> 上 rpc.lockd 常常會自己掛掉。如果是 clients 的 rpc.lockd 掛掉,會使得 flock() over NFS 掛掉,而如果是 servers 的 rpc.lockd 掛掉,會使得所有 clients 的 flock() over NFS 掛掉 =_=<br /><br />這個問題自從我們將某幾台 ccbsd*.csie clients 換成 <a href="http://www.freebsd.org/">FreeBSD</a> 6.0-RELEASE 後就發現這幾台一直有問題,後來決定將 cchome.csie 與 mailgate.csie 也一起升級到 <a href="http://www.freebsd.org/">FreeBSD</a> 6.0-RELEASE,看看能不能解決這個問題。結果反而變成大家都有問題... -_- 而且 ccsun*.csie 只要一開機,所有的 clients 就會炸掉,但這些 ccsun*.csie 裡面,如果只開 ccserv.csie 也不會有事情...。<br /><br />這個問題當時猜測是 <a href="http://www.freebsd.org/">FreeBSD</a> 4.x 與 6.x 的 clients 混在一起跑造成的,於是狠下心來將 ccbsd*.csie 全部升級到 <a href="http://www.freebsd.org/">FreeBSD</a> 6.0-RELEASE (另外一個原因是 <a href="http://www.freebsd.org/">FreeBSD</a> 4.x 已經不繼續維護了),結果升級上去發現問題還是沒變好,只好試著惡搞所有能惡搞的功能 (像是 mount_nfs 裡的 -L local lock),發現還是沒有用。<br /><br />前幾天想到 ktrace 可以看 system call 的情況,拿出來追,發現 uid=daemon 的 rpc.lockd 最後居然是死在 SIGPIPE,將這個 bug 用 send-pr 送出去幹剿後,rpc.lockd 的 maintainer 丟出一個神秘的 patch:把 SIGPIPE 用 <code>signal(SIGPIPE, SIG_IGN)</code> 堵掉,#bsdchat 上面看到這個 patch 把他叫做「掩耳盜鈴」,當作沒聽到,幹就對了 XD:<a href="http://www.freebsd.org/cgi/query-pr.cgi?pr=97768">Problem Report bin/97768 : NFS rpc.lockd will die automatically</a>。<br /><br />雖然這個方法看起來很鳥,但我還是決定把這個 patch 弄進所有 ccbsd*.csie 上跑,然後開 ktrace 盯著看還會有什麼死法。跑了快一天,發現 ccbsd*.csie 跑起來好像不錯,寫了封信跟 maintainer 講... 沒多久就看到 cvs commit 記錄:<a href="http://lists.freebsd.org/pipermail/cvs-src/2006-May/064178.html">cvs commit: src/usr.sbin/rpc.lockd kern.c</a>,結果才剛 commit 完沒多久就發現 uid=root rpc.lockd 死掉 XD<br /><br />看了一下 uid=root rpc.lockd 死掉時 ktrace 的紀錄,發現也是 SIGPIPE 的問題,正覺得奇怪,明明 mask 掉了,怎麼還會死在 SIGPIPE... 回頭看 patch 發現是因為 <code>signal()</code> 在 <code>fork()</code> 後才做,所以 uid=root 那隻沒有處理 SIGPIPE,只好再跟 maintainer 講,問看看能不能把 <code>signal()</code> 放到 <code>fork()</code> 前。(主要是他對 rpc.lockd 比較熟,可能會比較清楚各類後遺症 XD)<br /><br />結果 maintainer 就叫我去測測,沒問題就照我說的 patch 進 -current XD 我就跑去跟 <a href="http://www.csie.nctu.edu.tw/~chwong/">chwong</a> 要了 cchome.csie 與 mailgate.csie 的 root,要跑 ktrace 盯著看。<br /><br />測了一天看起來沒問題:rpc.lockd 沒死,mutt 看信也都很正常,看起來 locking 功能運作得很好,就回封信跟 maintainer 講這個情況,過不久就看到他把 <code>signal()</code> 搬到 <code>fork()</code> 前的 cvs commit 紀錄:<a href="http://lists.freebsd.org/pipermail/cvs-src/2006-May/064258.html">cvs commit: src/usr.sbin/rpc.lockd kern.c</a>,這個 patch 的 rpc.lockd 到現在都還活得很好,看起來在 6/1 那天就會進 RELENG_6 了 :)<br /><br />然後在 #bsdchat 上看到 <a href="http://rafan.infor.org/">rafan</a> 把這個 patch 也丟進 csie.ntu 的機器上跑,發現對於 NFSv2 的 <a href="http://www.sun.com/">Sun</a> 也正常多了 (打開 debug mode 還是會看到一堆 error msg,不過至少會動...),於是我剛剛就很高興的跑去學校把 ccsun*.csie 通通開起來測,目前看起來也都沒問題...<br /><br />折騰了兩個月,NFS 的 rpc.lockd 這件事情看起來暫時穩定多了,希望有長輩把 rpc.lockd 修一修,尤其是 recovery 的部分,如果寫完的話才能隨意關機開機 XDGea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-1142669967036034062006-03-18T16:13:00.000+08:002006-03-18T16:21:25.770+08:00lighttpd + WordPress 2.0 對於 Permlink 的處理<a href="http://www.lighttpd.net/">lighttpd</a> + <a href="http://wordpress.org/">WordPress</a> 2.0 使用 Permlink 的設定,重點在於 lighttpd.conf 裡的 mod_rewrite:<br /><blockquote><code>url.rewrite = ( "^/(archives|categories|comments|feed)/" => "/index.php" )</code></blockquote><br /><a href="http://wordpress.org/">WordPress</a> 裡 Permlink 則是設成:<br /><blockquote><code>/archives/%year%/%monthnum%/%day%/%post_id%/</code></blockquote><br />Category 的部份則是:<br /><blockquote><code>/categories</code></blockquote>Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com1tag:blogger.com,1999:blog-19253869.post-1141226273294570282006-03-01T23:17:00.000+08:002006-03-01T23:17:53.310+08:00FreeBSD NFS locking 問題我們一直以為是 4.x 與 5.x/6.x 之間的問題,結果剛剛 <a href="http://jnlin.org/">ericlin</a> 丟了一個這幾天的討論串過來,大光頭 Kris 還提供了一個 patch,是 <code>lock_proc.c</code> 這個檔案從 1.17 到 1.18 的 patch (6.0-RELEASE 是 1.18):<a href="http://lists.freebsd.org/pipermail/freebsd-stable/2006-February/022983.html">NFS locking question</a>。<br /><br />這個 patch 看起來是 <code>transmit_result()</code> 與 <code>transmit4_result()</code> 的修正,不知道 4.x 有沒有 <code>svc_getcaller()</code>,如果有的話可以試著 patch 看看...Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-1140110035052840232006-02-17T01:13:00.000+08:002006-02-17T01:13:55.126+08:00IE7 的 SSL 安全政策有長輩測試 IE7 Beta2 後發現 IE7 Beta2 對於 SSL 設定有問題的站台會整個擋掉,而不會像以前那樣跳初一個小視窗出來要你確認:<a href="http://www.ensight.org/archives/2006/02/16/stupid-google-ssl-certificates/">Stupid Google SSL Certificates</a>。<br /><br />文章裡 <a href="http://www.ensight.org/" rel="tag">Jeremy Wright</a> 舉了 <a href="http://www.google.com/" rel="tag">Google</a> 的例子:他說 <a href="http://www.google.com/" rel="tag">Google</a> 的某些服務使用了 www.google.com 的 SSL Certificate,但是使用的站台並不是 www.google.com。<br /><br />不過我不記得 <a href="http://www.google.com/" rel="tag">Google</a> 哪個服務是這樣惡搞的啊?還是 <a href="http://www.mozilla.com/firefox/" rel="tag">Firefox</a> 遇到同一個 Domain 的情況不會哀哀叫?這樣就太糟了...Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-1139733296101453862006-02-12T16:27:00.000+08:002006-02-12T16:53:29.436+08:00在交大使用 Bittorrent 的問題這幾天用 <a href="http://www.bittorrent.com/">Bittorrent</a> 抓一些東西,發現如果不是使用 <a href="http://www.bitcomet.com/">BitComet</a> (目前唯一一個有支援 Header Encryption 的 <a href="http://www.bittorrent.com/">Bittorrent</a> Client,而且 Windows Only...),幾乎不會動 (檔案很熱門也一樣)。<br /><br />即使只有放在出國電路的部份 (自己購買的出國電路),但是因為是 Default Gateway,所以可以很明顯感覺出來。<br /><br />真無奈,兩邊 (ISP 與發展者) 互相鬥法,最後就得靠一些數學方法 (Cryptosystem) 決戰... 輸的永遠是使用者 (需要更多的 CPU resource 做運算)。Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-1133537674188338062005-12-02T23:34:00.000+08:002005-12-02T23:34:34.200+08:00Apache 2.1 - MPM event在 <a href="http://blog.360.yahoo.com/blog-i8QmYlo8cqjdyIGRoE7L5l7EXNg-">mclee</a> 那邊看到 <a href="http://httpd.apcahe.org/docs/2.2/">Apache 2.2</a> 出版了,翻 <a href="http://httpd.apache.org/docs/2.2/new_features_2_2.html">Overview of new features in Apache 2.2</a> 的時候看到 <a href="http://httpd.apache.org/docs/2.2/mod/event.html">Apache MPM event</a>,回頭看記錄發現 <a href="http://httpd.apache.org/docs/2.1/">Apache 2.1</a> 就有了。<br /><br />不知道我是不是有猜錯,這應該是 Event-driven 的 module 吧?hmmm...Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-1133129305733231762005-11-28T05:58:00.000+08:002005-11-28T06:08:25.753+08:00Linux epoll() performance在找一些資料的時候發現 <a href="http://blog.xuite.net/frogbsd/geek/">zmx</a> 的舊文章 (也沒有很舊,半年前的文章),談 Linux <code>epoll()</code> performance 的改善:<a href="http://blog.xuite.net/frogbsd/geek/247177">Comparing and Evaluating epoll, select, and poll</a>。<br /><br />這篇文章裡提到了 <code>epoll()</code> 在 idle connection 很少的情況下,與 <code>poll()</code> 或 <code>select()</code> 改善的空間不會太多,大概就只有省下從 kernel 要修改 userland space 的時間吧。<br /><br />對於 Connection 數目很大的 HTTP server (所謂的 <a href="http://www.kegel.com/c10k.html">The C10K problem</a>),BSD 上的 <code>ACCEPT_FILTER_HTTP</code> 還是很重要,可以省下 <code>accept()</code> 進來卻慢慢送 Header 的情況 :pGea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-1133115279094852732005-11-28T02:05:00.000+08:002005-11-28T02:16:08.970+08:00Web Performance Tools - Siege剛剛在 <a href="http://blog.ijliao.info/">ijliao</a> 那邊看到 <a href="http://www.o3magazine.com/">O3 Magazine</a>,看了 <a href="http://www.lighttpd.net/">Lighttpd</a> 的測試報告,發現測試報告裡面不是用 ab,而是用 <a href="http://www.joedog.org/siege/">Siege</a>。看了一下 ab 與 Siege 的差別:<br /><blockquote>Siege is an http regression testing and benchmarking utility. It was designed to let web developers measure the performance of their code under duress, to see how it will stand up to load on the internet. Siege supports basic authentication, cookies, HTTP and HTTPS protocols. It allows the user hit a web server with a configurable number of concurrent simulated users. Those users place the webserver "under siege."</blockquote><br />這樣看說明可能看不太出來,<a href="http://www.joedog.org/siege/">Siege</a> 與 ab 主要的差別在於同時發出的 Request 不一樣 (於是會比較逼近真實的情況)。<br /><br />查了一下 <a href="http://www.freebsd.org/ports/">FreeBSD Ports</a> 裡面,發現在 <a href="http://www.freshports.org/benchmarks/siege/">benchmarks/siege</a> 下面有,邊裝邊找中文的說明文件,在 <a href="http://tristones.viaspeip.com/archives/000297.html">Siege:压力模拟/测试工具</a> 這篇裡面有很簡單的說明,等下來用 <a href="http://search.cpan.org/dist/WWW-Mechanize/">WWW::Mechanize</a> 寫個小程式抓網頁 url 測試看看。Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-1133058758534463372005-11-27T10:16:00.000+08:002005-11-27T10:32:38.543+08:00Thread-safe gethostbyname() on FreeBSD 6.0前陣子在我個人板上有寫,FreeBSD 6.0 的 <code>gethost*()</code> 已經 Thread-safe 了:<br /><ol><li><code><a href="http://www.freebsd.org/cgi/man.cgi?query=gethostbyname&manpath=FreeBSD+6.0-RELEASE">gethostbyname</a></code> manpage on FreeBSD 6.0</li><li><code><a href="http://www.freebsd.org/cgi/man.cgi?query=gethostbyname&manpath=FreeBSD+5.4-RELEASE">gethostbyname</a></code> manpage on FreeBSD 5.4</li></ol>在最下面 BUGS 的地方寫的還蠻清楚的,所以我就寫了個小程式測試,在不同的 Thread 裡面不斷的呼叫 <code>gethostbyname()</code>,看傳回來的位置是什麼:<br /><pre><code><br />#include <netdb.h><br />#include <pthread.h><br />#include <stdio.h><br /><br />#define THREAD_NUM (3)<br /><br />void *thread_start()<br />{<br /> const pthread_t tid = pthread_self();<br /><br /> int i;<br /> for (i = 0; i < 5; i++) {<br /> struct hostent *p = gethostbyname("ccca.nctu.edu.tw");<br /> printf("tid = %d, gethostbyname() = %p\n", tid, p);<br /> sleep(1);<br /> }<br /><br /> return;<br />}<br /><br />int main(void)<br />{<br /> pthread_t tid[THREAD_NUM];<br /><br /> int i;<br /> for (i = 0; i < THREAD_NUM; i++)<br /> pthread_create(tid + i, NULL, thread_start, NULL);<br /><br /> sleep(10);<br />}<br /></code></pre>Gea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0tag:blogger.com,1999:blog-19253869.post-1132940889252751352005-11-26T01:40:00.000+08:002005-11-26T01:48:09.266+08:00Squid 3 的設定<a href="http://www.squid-cache.org/">Squid</a> 3 網站上的 20051125 版 是有問題的,後來透過 cvs 抓到的版本就 okay 了。本來是要在 <a href="http://www.cs.nctu.edu.tw/">www.cs.nctu.edu.tw</a> 上面測試的,後來被提醒 11/25 碩班甄試放榜,那我們就換回舊的版本了。<br /><br />我後來在 netnews.nctu.edu.tw 上面架了一個,bind 在 127.0.0.1:3128 上面給自己用 (putty tunnel,3128:127.0.0.1:3128,然後把我 Laptop 與 Desktop 的 <a href="http://www.mozilla.org/projects/firefox/">Firefox</a> 都設定 127.0.0.1:3128 為 Proxy Server),因為 netnews.nctu.edu.tw 是 FreeBSD 6.0,所以我在安裝的時候特地把 Thread 有關的選項打開 (像是 aufs),先測看看 stability 如何,晚點再來測試看看 performance。<br /><br />這是我 compile 時的參數:<br /><blockquote><code>--prefix=/home/squid --enable-storeio="ufs aufs diskd" --enable-disk-io="Blocking" --enable-removal-policies="heap lru" --disable-wccp --enable-cache-digests --disable-poll --disable-select --enable-kqueue --disable-epoll --disable-ident-lookups --enable-underscores --disable-unlinkd --enable-x-accelerator-vary --with-aufs-threads=8 --with-pthreads --with-aio</code></blockquote>會同時把這麼多東西 compile 進去主要是要測試各種 algorithm 的效能,實際在跑的時候可能會再拔掉一些 :pGea-Suan Linhttp://www.blogger.com/profile/12045683756004181456noreply@blogger.com0