2011年6月30日星期四

Git 相關模組

Gitalist : 是一 Git 的 Web Viewer ,使用 Catalyst Framework 作為 Web 端。

Git::Fingerd : 由 @rjbs 寫的,可透過 finger 命令來查詢你的 Git Repository。

Git::Repository : 可讀取 Git Repository 的資訊。

Git::Bunch : 可管理一包含所有 Git Repository 的路徑。

Git::FastExport::Stitch - Stitch together multiple git fast-export streams

Git::Flux - gitflow-like in Perl.

2011年6月25日星期六

你為何不該使用 PHP ? 讓我們談談 Perl。 Why You Shouldn't Use PHP

前些日子 Survey 了一些 PHP Framework 的 Benchmark ,大致上看來大部分的 PHP Framework 的 Hello Word 若不開 cache 也不 prefork 或是 apache worker ,Requests per second 大致上從 20~40 或是 100 ~ 1200 的數據都有。 至於開 Cache 的我們就先不談。

那麼來看看 Perl。是的沒錯,就是你眼中古老的 CGI Perl 。

但是 如今已經不同。自從日本的超級 Hacker Miyagawa 於 2009 初寫下了 PSGI Spec 的 1.0 版本。 Plack 的實做也一直處於積極的開發中,受到世界矚目。

Perl 不同於 PHP ,是在 Server 啟動時會先將所有程式碼編譯進記憶體,HTTP 要求 (HTTP Request) 進來時,可以直接快速的執行,不需要不斷重複解譯相同的檔案,而 PHP 在不開快取下,則是每個 HTTP Request 都要重新讀取檔案解譯 PHP。

題外話,在 PHP 的 Symfony Framework 中,為了加快每一次解譯的速度,還另外寫了一個轉換程式將所有程式碼的註解移除掉另外做一個快取的版本。

其他解決效能問題的方式還包括:得利用還在實驗中的 bcompiler extension 將程式碼轉換成原本程式碼大小三倍的 bytecode 以加速 30% PHP 解譯的速度;或用 Facebook 所開發的 HipHop 將 PHP 轉換為 C++ 程式碼;許多使用 PHP 作為 Startup 語言的網站,甚至得用 C++ 寫 PECL Extension 來解決效能瓶頸。處理 PHP 效能瓶頸問題探討的文章很多,在此先不討論。

Plack

Perl 世界中的 Plack ,雷同 Ruby 的 Rack 的角色,也同於 Python 的 WSGI 的角色。 對於 Plack 的其他問題,你可以參考 Miyagawa 寫下的 PSGI FAQ

使用最簡單的 Plack Server (無需 Cache 或 Prefork)就可以讓 Hello Word 達到 4000 req/s 的效果。這個數字是 PHP 的百倍以上,而 PHP 得透過 Prefork 或 Worker 才有辦法達到這樣的效果。

摘自 Miyagawa 的 blog:
We'll show more numbers once everything gets stable, but so far the number seems promising and very interesting. Simple Hello World is now 4000 req/s with Standalone server with keep-alive on, and 2MB photo file serving runs fastest on AnyEvent server (300 req/s) with sendfile(2) and AIO enabled while other dumb implementation suffers from I/O in the perl land like (80 req/s).
另外 Miyagawa 也提到, 2MB 圖片檔案的伺服器,利用 AnyEvent 的話可達到 300 req/s 。其他的 Perl 實做可能只可達到 80 req/s。

Starman

那麼再來看 Starman 。CPAN 上頭的 Description 如是說:


Starman - High-performance preforking PSGI/Plack web server

而 Starman 的效能如下 (摘自 CPAN):

Here's a simple benchmark using Hello.psgi.

-- server: Starman (workers=10)
  Requests per second:    6849.16 [#/sec] (mean)
  -- server: Twiggy
  Requests per second:    3911.78 [#/sec] (mean)
  -- server: AnyEvent::HTTPD
  Requests per second:    2738.49 [#/sec] (mean)
  -- server: HTTP::Server::PSGI
  Requests per second:    2218.16 [#/sec] (mean)
  -- server: HTTP::Server::PSGI (workers=10)
  Requests per second:    2792.99 [#/sec] (mean)
  -- server: HTTP::Server::Simple
  Requests per second:    1435.50 [#/sec] (mean)
  -- server: Corona
  Requests per second:    2332.00 [#/sec] (mean)
  -- server: POE
  Requests per second:    503.59 [#/sec] (mean)
This benchmark was processed with ab -c 10 -t 1 -k on MacBook Pro 13" late 2009 model on Mac OS X 10.6.2 with perl 5.10.0. YMMV.
光是用 MacBook Pro 搭配 workers = 10 就可以達到 6849.16 。


Feersum

最後是 Feersum 模組,一個以 EV/libev 為基礎的 PSGI 實做,在該模組作者的文件中提到:
A trivial hello-world handler can process in excess of 5000 requests per second on a 4-core Intel(R) Xeon(R) E5335 @ 2.00GHz using TCPv4 on the loopback interface, OS Ubuntu 6.06LTS, Perl 5.8.7. Your mileage will likely vary.
使用 Feersum ,一個 Hello World 的 handler 就可以達到超過 5000 的 requests per second,而且還是使用 Perl 5.8 (如今的 Perl 5.14 已經比 Perl5.8 快相當多)。

此外,唐鳳在 Facebook 上和我提到使用 Feersum 甚至可到 15000+ 以上的 requests per second。



2011年6月2日星期四

HTML5

就 HTML5 的需求面來看,對於 HTML5 有極度需求的不是使用者反而是開發者。 許多開發者需要 HTML5,因為他們好用、效果酷炫,但對於一般上網的使用者,根本就沒有差異,對使用者來說只在乎看起來還可以、網站速度流暢就行了,字體、圓角、陰影、怎麼製作又有多麻煩根本就無關緊要。

所以,只能看作是開發者一廂情願了。 大概也只有讓瀏覽器把人類的基本需求 "性"、"食物"、"交際" 綁在一起才有辦法 push 瀏覽器支援 HTML5 ... 否則,就只能等待瀏覽器世代交替。 而且,只要世界上有任何一個客戶使用 IE6 ,你的網站就不能放棄 IE6。