Home » 2014 » February (Page 3)

DigitalOcean 建立新加坡機房...

今天 DigitalOcean 宣佈新加坡資料中心營運 (SGP1):「We're Excited To Announce Our Singapore Datacenter (SGP1)」。

要測試 latency 或是要看 routing 的人可以用 DigitalOcean 提供的 speedtest-sgp1.digitalocean.com 測。

中華電信 HiNet 光世代動態 IP、PPPoE 固定 IP,以及三重的重新機房到 speedtest-sgp1.digitalocean.com 都是 90ms~100ms 左右。

台灣固網內湖機房約 75ms 左右。

而目前看到數字最好的是遠傳的機房的 60ms 左右,ISP 直接進香港 NTT 後就轉入新加坡 NTT,最後進 DigitalOcean。

在 comment 裡也有提到目前的 peering 還不完整,最近會一直調整:

In regards to the latency that people may be experiencing in Singapore: We are sorry to hear that you are having latency issues at this time. Some of our peering is delayed and we will be improving generally connectivity around Asia in the coming weeks.

以後要測試就拿這個點了!XD

C 語言的 extern 與 static...

把十年多的 BBS source code porting 到 Ubuntu 上,被迫要用 GCC 4.6 而一路找出來的...

在 BBS 內有這樣的資料結構要處理:

typedef struct p {
    struct p *pointer;
} P;

static P p1 = { &p2 };
static P p2 = { &p1 };

兩個要互指,但在指定 p1 時 p2 還沒有被定義,所以要用 extern 先宣告:

typedef struct p {
    struct p *pointer;
} P;

extern P p2;

static P p1 = { &p2 };
static P p2 = { &p1 };

這個語法在舊版的 GCC 沒問題 (3.4),但在新版的 GCC 4.6 上不接受這個寫法,會抱怨後面的 p2 實際在宣告是 static,與前面的 extern non-static 不符。

後來在 Stack Overflow 上找到「static extern vs extern static」這篇說明,要先定義 static 再定義 extern:

static P p2;
extern P p2;

這樣寫的原因在原文的下方有說明,所以是 C99 定義的關係?

猜測 AWS ELB 內的架構...

AWS Elastic Load Balancing (ELB) 是 AWS 在雲端上推出的 Load balancer。

在非雲端的架構上會使用 Layer 4 Switch (像是 F5Alteon),或是使用 open source 的 HAProxy

從實驗猜測 ELB 是這樣做的:

  • ELB 是 Amazon 自己開發的「軟體」,而非硬體。可能就是跑在 EC2 上,也可能為了 billing 的需求是跑在另外一個 cluster 上。
  • 在每一個有 instance 需要服務的 availability zone 上都會開一台 ELB instance 起來。
  • 每一個 ELB instance 會有一個 public IP 對外,在 ELB domain 解出來的 IP 可以查出來。

所以 ELB 的文件上會警告「每一個 AZ 的運算能力要盡可能接近」:

By default, the load balancer node routes traffic to back-end instances within the same Availability Zone.

To ensure that your back-end instances are able to handle the request load in each Availability Zone, it is important to have approximately equivalent numbers of instances in each zone.

這是因為不同 AZ 的平衡是靠 DNS round robin 處理,所以下面的例子就有建議儘量打平:

For example, if you have ten instances in Availability Zone us-east-1a and two instances in us-east-1b, the traffic will still be equally distributed between the two Availability Zones.

As a result, the two instances in us-east-1b will have to serve the same amount of traffic as the ten instances in us-east-1a.

As a best practice, we recommend that you keep an equivalent or nearly equivalent number of instances in each of your Availability Zones.

So in the example, rather than having ten instances in us-east-1a and two in us-east-1b, you could distribute your instances so that you have six instances in each Availability Zone.

而量大到一個 ELB instance 撐不住的時候,AWS 就會自動開出第二台:(目前都只放在同一個 zone 上)

;; ANSWER SECTION:
lb-guesschocolate-1791292202.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.249.68.121
lb-guesschocolate-1791292202.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.238.240.61

以這樣的架構,當量夠大的時候,AWS 應該要有能力生出足夠多的 ELB instance 打散?之後再來觀察看看好了... 還有很多煩惱要處理 ~_~

MySQL 裡搜尋 CHAR/VARCHAR (String) 欄位時要注意的事情

MySQL 表格欄位是 CHAR 或 VARCHAR 時,寫搜尋條件要記得使用 string 格式,而非數字。意思是,要避免這種 SQL query:

SELECT * FROM foo WHERE `column_string` = 123456;

原因是即使 column_string 加上了 B-tree index,也無法利用這個 index 加速查詢。

原因是,除了最明確的 '123456' 會符合外,還有很多種 case 符合:

mysql> SELECT 123456 = '0123456';
+--------------------+
| 123456 = '0123456' |
+--------------------+
|                  1 |
+--------------------+
1 row in set (0.00 sec)

mysql> SELECT 123456 = ' 123456';
+--------------------+
| 123456 = ' 123456' |
+--------------------+
|                  1 |
+--------------------+
1 row in set (0.00 sec)

這使得 index 無用武之地。

但如果欄位本身是數字 (INT/BIGINT),搜尋時用字串反而沒關係:MySQL 會先把字串轉型為數字再比較,所以會用到 index。

總而言之:

  • 可以用 INT/BIGINT 時,不要用 CHAR/VARCHAR 儲存。
  • 使用 CHAR/VARCHAR 的欄位當搜尋條件時,要用字串形式當作搜尋條件。(除非你很清楚你在做什麼)

今天上場當救援投手時解掉的問題...

Debian/Ubuntu 上跑 6to4 的方法...

因為 HiNet 在自家放了 192.88.99.1 的 6to4 gateway,設起來玩看看?

網路上找了不少方法都不會動 (包括 Ubuntu 在官方 wiki「IPv6」上給的連結「IPv6: Linux as 6to4 host」),最後是用「IPv6 6to4 config generator for Debian」這邊的方法。我是用 Ubuntu 12.04。

/etc/network/interface 裡加上:

auto tun6to4
iface tun6to4 inet6 v4tunnel
address 2002:0102:0304::1 
        netmask 16              
gateway ::192.88.99.1
endpoint any
local 1.2.3.4

其中 1.2.3.4 是 public IP,而 0102:0304 則是 hex 表示法。設完後跑 ifup tun6to4 就會帶起來了。

可以用 telnet -6 www.google.com 80 看看有沒有通,或是連到 The KAME project 看看有沒有會動的烏龜 :p

Akamai 與 EdgeCast 混用的效果...

EdgeCast 官網上丟出來的「The Positive Performance Impact of a Dual CDN Strategy」這篇 PR 稿引用了 Optimizely 的「The Most Misleading Measure of Response Time: Average」。

EdgeCast 官網上的 PR 稿當然不會提到 Akamai 的名字,但在 Optimizely 上有說明:

At Optimizely, we had already been using Akamai, one of the world’s fastest and most reliable CDNs, so we decided to try adding another. We tested a balanced CDN architecture, combining Akamai with EdgeCast, another leader in the CDN space.

可以看到 99 percentile response time 大幅改善:

其中改善最高的是北美:

不過看不出來是怎麼測試 CDN Balancing 這個方法啊?依照白皮書的說明:

Prior to introducing CDN Balancing, Optimizely’s experiment code was stored in a JavaScript file that sits on Akamai’s CDN, one of the fastest and most reliable CDNs in the world. The code in this file is important because it’s responsible for making client-side changes to a page and serving them to visitors according to the targeting and A/B testing criteria set up by the Optimizely customer who created the experiment.

看起來是對 js code 測試,應該是 cdn.optimizely.com 這個 hostname,而 optimizely.com 的 DNS 放在 Dyn 上。

猜測應該是對 EdgeCast 有服務的地區丟到 EdgeCast 上 (美國的部份應該可以切割到「州」),其他的則丟到 Akamai 上?不過現在怎麼查都是 EdgeCast 啊,從馬來西亞查也是丟到 EdgeCast 的 CDN 上 (然後被導到新加坡)。

不過,在北美 EdgeCast 會比 Akamai 快這麼多應該是因為 EdgeCast 有兩個平台,一個是 for large files,一個是 for small files,兩個平台最佳化時調整的參數應該不同,針對大檔案的部份會計較 thoughtput,針對小檔案的部份會計較反應時間。Akamai 可能就是輸在這邊...

也有可能是因為 EdgeCast 的反應時間比較好,然後 Akamai 合約到期就整個切過去了?(噗)

冒出很多疑問啊...

把 blog 搬到 DigitalOcean 上...

前幾天才把 DigitalOcean 的 Droplet 都清掉,然後收到 DigitalOcean 給的 USD$5 後,本來的主機就失聯了,剛好又跑回來用...

而之前買的 WordPress 備份服務 VaultPress 也派上用場,直接去上面拉資料下來,照著步驟做就解決了... O_O

不過應該還是有很多東西需要調整吧... 之前在 Ubuntu 上跑 PHP 的量也都不大,我自己的 blog 反而是最大的?而且是跑在 512MB 的機器上 (雖然設了 1GB 的 swap),不過應該還是很多需要調整的吧 :o

不過 DNS 的部份還要再等等,等到都 timeout 後才算正常 :o

擋 Open Redirect 的問題...

Open Redirect 的問題可以參考:

這兩個連結。主要是要避免 phishing 的問題上。

一開始是以「只允許 / 開頭」為條件過濾,但 protocol-relative 的 //www.example.com 可以繞開。

如果變成「只允許 / 開頭,但不允許 // 開頭」,是不是就沒事了呢?

在「Evolution of Open Redirect Vulnerability.」這邊又看到新招:「/\www.example.com」。

想要用 parse_url() 檢查?沒問題:

$ php -a
Interactive mode enabled

php > var_dump(parse_url("/\\www.example.com"));
array(1) {
  'path' =>
  string(17) "/\www.example.com"
}

但實際測試會發現 IE8 與 Google Chrome 都會跳到 www.example.com (沃槽),其他瀏覽器就先不測了 ~_~

不過原文說的 ///www.example.comPHP 上測試應該是不會過的?

$ php -a
Interactive mode enabled

php > var_dump(parse_url("///www.example.com"));
bool(false)

反正又冒出一堆問題要處理了 ~_~

Archives