依照「mod_wsgi 與 .htaccess」的設定設好後,在 index.py
內參考「Integration With CherryPy」這篇文章的範例就會動了,可以用 ab 或是 httperf 測試看看效能如何。
另外 Robert E Brewer 在 PyCon 2009 - Chicago 上講的「Introduction to CherryPy (#90)」(包含影片) 也蠻適合剛碰 CherryPy 的人看。
幹壞事是進步最大的原動力
依照「mod_wsgi 與 .htaccess」的設定設好後,在 index.py
內參考「Integration With CherryPy」這篇文章的範例就會動了,可以用 ab 或是 httperf 測試看看效能如何。
另外 Robert E Brewer 在 PyCon 2009 - Chicago 上講的「Introduction to CherryPy (#90)」(包含影片) 也蠻適合剛碰 CherryPy 的人看。
mod_wsgi 是 apache 上 PEP-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]
不會很難,不過還是寫下來,以後應該會找到自己的文章...
《瑪莉亞的凝望》第三本看到一半,到 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/OpenSolaris 的 ZFS),用 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。
當你有裝防毒軟體,並打開隱私權設定 (有一些防毒軟體在安裝完後就是這樣) 就會造成問題。
好久沒看到這種網站了...
這是 Stanford 的課程:「CS193H: High Performance Web Sites」。
很密集的課程,幾乎都有投影片,每次 50mins 的課程。有不斷在看目前 Web 發展趨勢的人應該都對這些資訊稍微瞭解,不過對於想入門的人倒是相當好的導引。
FreeBSD ZFSv13 終於進入 RELENG_7 了:「svn commit: r192498」。
幾個重要的改變:
另外 commit log 有個讓人還蠻在意的地方:
Supported by: Barrett Lyon, BitGravity
BitGravity (一家 CDN company) 的 CTO 贊助 XDDDDD
只貼 code... (還蠻常用到的技巧)
(function($){ // you can use $ even if jQuery.noConflict()... })(jQuery);
Amazon Web Services 在 EC2 上推出新的服務:「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"...)
用 Google 翻資料,結果三月初的時候有人試著 benchmark,結果還蠻讓人意外:「Performance comparison of Thrift, JSON and Protocol Buffers」。
結論是 JSON 在速度上不會輸給 Protocol Buffers 與 Thrift。討論出來的原因是因為 Protocol Buffers 與 Thrift 的功能比 JSON 多出太多。
不過我應該會用 JSON 寫東西吧,畢竟是個 open standard...
目前看到兩個,一個是 EdgeCast,主要是 static files,像是 s.wordpress.com 與 s2.wordpress.com,效果還可以。
另外一個是 Internap CDN,用在 video 的部份,像是 cdn.videos.wordpress.com。從台灣連過去效果非常差,會選 Internap 應該是因為成本的考量...