2014年6月28日 星期六

論文寫作修訂整理

 2014-06-29 10:10


投稿的 paper 被 reviewer 嫌英文太差,要求經 native English speaker 修訂。透過前輩介紹,給台灣有名的 Ted 教授修訂。一個 word 要台幣 2 元,一篇 paper 有 9 千多字,花了 1萬8。國科會最多可以報 1 個字 1 元左右,不夠的要自己墊。好在有上,剛好過畢業門檻,算是值得。

修訂重點與建議,整理如下,以供參考。

  • Avoid First person “We” unless explicitly stating your opinion such as ‘we conclude’ ‘we can infer’ ‘we posit’ ‘we speculate’ ‘we recommend’ ‘we postulate’ ‘we hypothesize’.
  • Avoid negative voice in technical writing as much as possible. 例如 ‘not inconvenient’ -> ‘inconvenient’ 或 ‘infeasible’。
  • Consistent verb tense is important.  Unnecessarily switching back and forth in verb tense – especially in the same paragraph – will confuse the reader. 華人最困擾的部分之一 – 時式。
  • Don’t always use Chinese-English structure of  “A is used to solve B.”  Instead write more directly in emphasizing the contribution rather than the method itself by stating “B is analyzed using A.” 華人感到困擾的部分之一 – “用 A 來解決 B” ,沒有生命的東西怎麼會有動詞呢?。
  • Avoid redundancy.  Why do you have to repeat ‘implement’ twice in the same sentence. 例如 As a resultConsequentlya most intuitive implementation of the AC-algorithm is to implements the AC-DFA in a lookup table. 唉,你以為我喜歡啊,就只會那一招半式而已啊 ... 不過,這句也改得怪怪的,後來指導教授有修訂。這兒就做個參考吧。
  • a higher throughput THAN WHAT? ‘higher’ implies a comparison with something. Just write ‘high’ if not implying a comparison. 啊,我們就習慣說得到比較好的結果啊,那考慮那麼多 ...
  • However, Yet another difference between the software and hardware approaches also differ in is that the former generally has a larger dictionary size can be larger in a software approach generally. 簡潔有力,就是要這樣改。不過,還要再練,才有辦法。
  • Especially when implementing a multi-character transition matching architecture, the required space will (NOTE: Avoid future verb tense in technical writing as much as possible) grows exponentially with respect to the number of characters (to be inspected OR under inspection) in parallel.

2014年2月1日 星期六

FastCgi + Phalcon 有多快

 2014-02-02 12:59

使用 Laravel 之後,自己負責的應用程式,差不多都 porting 到 Laravel,只剩下一個有效能要求的,不敢動,仍然使用 ASP.NET。春節 (2014) 期間,上網看到 Bruno Skvorc 的 "Best PHP Frameworks for 2014" (http://www.sitepoint.com/best-php-frameworks-2014),排名第二的 PhalconPHP (簡稱 Phalcon),以效能著稱,不禁心動,春節過後,就來實際測試一下。

其實,Phalcon 並非第一個擴展的框架 (extension-based framework),YAF 在 2011 年中就已提出,並被包含在 pecl extension 中。而且,在目前可得到的 benchmark,YAF 還是略快一些。只是,相對於 Laravel 這樣方便的框架,Phalcon 和 YAF,兩者都同樣有 extension-based framework 特有的難以使用的特性,而 YAF 還更難一些。至少,我照著 Phalcon 的網頁,簡單的建立幾個檔案,就可以看到成果。YAF 則要更為深入的調整,才能成功。另一個,不考慮 YAF 的因素是,其最後的 DLL 下載版本是一年前的,表示,這一段時間,它的進展是停滯的。


測試環境,OS 為安裝在 VMware ESXi 5.1上面的 Window server 2003,配置 CPU*2,1.5GB RAM,PHP 為 5.4.12。資料庫存取為透過 PDO:SQLSRV 從 MS SQL 2000 取得某個使用者的相關紀錄,大約 10 筆,傳回的文件長度約 680 bytes。

執行命令 ab -n 100 -c 10 http://10.161.81.190/abtest.php

CASE 1
首先,來個測試的基準,在 php 中單純送出 'hello' 文字,傳回的文件長度為 5 bytes。
CGI 的結果為 29.65 [#/sec] (Requests per second) 。
使用 FastCGI 1.5,第一次 1534.14 [#/sec] ,第二次 3305.29 [#/sec]。

具資料庫操作的測試,CGI 為 18.15 [#/sec],FastCGI 為 1377.57 [#/sec]

對照組,ASP.NET 的結果為 1462.69 [#/sec]。
另外,也用 phalanger 測了一下,大約在七八百之間吧。不過,終究其相容性較差,PDO:SQLSRV 無法正常運作,Laravel 也跑不動,用 Google 搜尋,也不容易找到相關資訊,不要再浪費時間去測試了。


CASE 2
使用 PhaconPHP 1.2.6,具資料庫操作。
單純使用 CGI 的結果,20.16 [#/sec]。
使用 FastCGI 1.5,第一次 208.91 [#/sec],第二次 788.36 [#/sec]。

CASE 3
使用 Laravel 3.2.14,無資料庫操作,單純的產生一個空白的 form,未連結資料庫, 傳回的文件長度為 737 bytes。
使用 CGI 的結果,15.19 [#/sec]。
使用 FastCGI 1.5,第一次 64.32 [#/sec],第二次 71.83 [#/sec]。

 比較表

CGIFastCGI
PHP (純文字)303305
PHP (資料庫)181377
ASP.NETNA1463
Phalcon20788
Laravel1572

註: 結果取較高的次數,並且四捨五入


個人心得
非 常吸引人的結果,使用 PhaconPHP 配合 FastCGI,效能可以提昇 10 倍以上,從每秒處理的服務數量來看,能有超過 500 次的能力,著實讓人心動。但在目前的版本下,有個小問題是其所支援資料庫實在很少。另外,使用 FastCGI 有個不便之處,那就是基於安全的考量, FastCGI 會隱藏錯誤訊息,debug 要稍微費心些。說真的,暴露出錯誤訊息,是不好的習慣,但人有時候就是為了省事和方便,不會認真處理錯誤訊息。

FastCGI 對於 Laravel 的提昇效果並沒有如此顯著,但我所負責的程式,大多每分鐘的使用者都不超過一個人,就算使用 CGI 也足以應付,真正在乎的是程式好寫且好維護。

誠如 Bruno Skvorc 的結論所說的,各個 PHP 的 FrameWork,深究其中,都很類似。而 Phalcon 在提昇效能上的作法,無疑的提供了一個不錯的可行方向。曾聽起前輩提到科技發展的 divergence and convergence,在各種 FrameWork 相繼被提出之後,最終,PHP 可能會加上原生 MVC 的支援。

網誌存檔