Home » 2009 » May

mod_wsgi 與 .htaccess

mod_wsgiapachePEP-333 的實做軟體,使用 Python 開發 web application 的人不用知道怎麼介接。

既然是 .htaccess,apache 的部份就不講了。

Update:修正 mod_rewrite 的部份。

先從最簡單的「所有 request 都丟給 index.py」開始:

SetHandler wsgi-script
RewriteEngine on
RewriteBase /~gslin/py/
RewriteRule ^index.py$ - [L]
RewriteRule ^(.*)$ index.py/$1 [L]

如果不希望連靜態檔案都透過 index.py 處理 (像是 robots.txt),要做兩件事情。第一件是限制 wsgi-script 的範圍:

<Files *.py>
SetHandler wsgi-script
</Files>

然後修改 mod_rewrite 的條件,只有檔案不存在的 request 才丟給 index.py:

RewriteEngine on
RewriteBase /~gslin/py/
RewriteRule ^index.py$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.py/$1 [L]

不會很難,不過還是寫下來,以後應該會找到自己的文章...

MySQL ALTER TABLE

瑪莉亞的凝望》第三本看到一半,到 Twitter 上看到 Jeremy Zawodny (O'Reilly 出的 High Performance MySQL 第一版與第二版的作者之一) 在喊 MySQL ALTER TABLE 跑了八天了:

I have an ALTER TABLE running for nearly 8 days now... yikes.

結果 Aaron Brazell 居然很機車的這樣問他 XDDD

@jzawodn Removing South Carolina from all Craigslist tables?

如果不清楚 Craigslist 與南卡的新聞,可以參考紐約時報「Under Pressure, Craigslist to Remove ‘Erotic’ Ads」這篇的說明。

Anyway,Jeremy Zawodny 有說明這次的目的是要把舊的 InnoDB 轉成 XtraDB compression 格式:

the big ALTER TABLE is to enable InnoDB/XtraDB compression on ~650M records (old CL postings)

簡單提一下 MySQL 搭配一些 open source solution 的運作方式。

首先是要打開 replication,有 master 與 slave server(s)。寫入都到 master,讀取到 slave。(這邊為了說明方便,暫時不考慮 replication delay)

除了 master/slave 讓前端的 application servers 或 web servers 存取外,另外建立一套 slave server,上面有 snapshot filesystem (像是 Linux 的 LVM,或是效能較好的 Solaris/OpenSolarisZFS),用 cron 定時將 MySQL 暫停並寫入磁碟,產生 snapshot。

在這樣的架構下,當需要 ALTER TABLE 而且已經知道會卡很久時,我們可以從 snapshot 上先複製一份完整的資料,建立一台 MySQL server 並且在上面 ALTER,等到完成後再接回 master server,將 replication delay 的部份補上。如果想確認資料正確性,可以跑 mk-table-checksum 確認。當 replication delay 跟上後,停機時間不用太長就可以將 master 換成這份新的格式。

雖然 Jeremy Zawodny 沒有詳細說明,不過應該是類似的方法。

Update:Jeremy Zawodny 在「The Big ALTER TABLE Test」這篇有提到結果。

無法註冊在博客來的原因

去年年底在「博客來的網站的註冊頁面...」這篇提到無法在 books 註冊的原因終於找到了,因為博客來註冊頁 (也就是 https://db.books.com.tw/newmember.php 這頁) 的「同意」擋 Referer。

當你有裝防毒軟體,並打開隱私權設定 (有一些防毒軟體在安裝完後就是這樣) 就會造成問題。

好久沒看到這種網站了...

FreeBSD ZFSv13 進 RELENG_7

FreeBSD ZFSv13 終於進入 RELENG_7 了:「svn commit: r192498」。

幾個重要的改變:

  • kmem now goes up to 512GB so arc is now limited by physmem (kmem 再度拉高到 512GB)
  • the arc now experiences backpressure from the vm (which can be too much - but this allows ZFS to work without any tunables on amd64) (我不確定這個說明的意思,猜測是指當非 ZFS 需要系統資源時,cache 所使用的記憶體空間會放出來給 kernel 用)

另外 commit log 有個讓人還蠻在意的地方:

Supported by: Barrett Lyon, BitGravity

BitGravity (一家 CDN company) 的 CTO 贊助 XDDDDD

jQuery 與 $

只貼 code... (還蠻常用到的技巧)

(function($){
    // you can use $ even if jQuery.noConflict()...
})(jQuery);

Amazon Web Services 又推出新服務...

Amazon Web ServicesEC2 上推出新的服務:「New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch」。

這次推出了三個新服務,第一個是 Elastic Load Balancing,支援 HTTP 與 HTTPS。以前是自己開一台 instance 架設 (像是 HAProxy),現在由 Amazon 直接提供,簡化 Load balancer 的管理問題。(因為大多數的 open source load balancer 並沒有專門接 Amazon EC2 的 instance api,所以會需要自己寫一些程式接,但自己寫的 code quality 不一定穩定...)

第二個服務是 CloudWatch,用以監控 instance 資訊,這個部份有不少 open source solution 可以用,而且產生的資料都還不錯 (也就是「堪用」),所以好處沒有像上面的 load balancing 那麼明顯。

第三個服務是 Auto Scaling,利用 CloudWatch 所取得的資訊,當系統負載達到設定的條件時就加機器,或是在負載降低時減少機器 (像是 web server)。這個功能在很早前就有人做了,像是去年四月 TechCrunch 就有報導過的 open source solution:「Scalr: The Auto-Scaling Open-Source Amazon EC2 Effort」,或是專門靠此賺錢的 RightScale (這項服務對於 RightScale 很傷,由於 Amazon 提供 API,會更容易開發 open source solution...)

補上這些東西後,現在 Amazon Web Services 比較缺的是 cache 的機制... (open source solution 有 memcached,不過跑 memcached 時 cpu resource 實在用不到這麼多,開 15GB RAM instance 還附帶 "8 EC2 Compute Units"...)

WordPress.com 的 CDN

目前看到兩個,一個是 EdgeCast,主要是 static files,像是 s.wordpress.com 與 s2.wordpress.com,效果還可以。

另外一個是 Internap CDN,用在 video 的部份,像是 cdn.videos.wordpress.com。從台灣連過去效果非常差,會選 Internap 應該是因為成本的考量...

Archives