用 PHP 做檔案下載功能時遇到的記憶體問題

一般來說,為了避免使用者上傳了什麼奇奇怪怪的檔案被執行,會將上傳的檔案放在網頁根目錄以外的地方,再利用 PHP 將檔案內容輸出給 Client。

最簡單的方法是用 readfile 這個函式直接將檔案內容輸出,然而如果允許上傳的檔案比較大的話, readfile 會一次將檔案讀到記憶體內,造成記憶體用量超出上限的問題。

這個不能單純將記憶體上限提高來解決,不然只要同時幾個人下載檔案就會造成伺服器記憶體用盡。我想目前最簡單的方法是利用 stream 的功能來做:

這樣子就可以了,經測試下載數百 MB 的檔案也不會直接造成 PHP 錯誤。

SQLite 的效能

在考慮要使用 SQLite 還是其它資料庫的時候看到了這篇:http://stackoverflow.com/questions/14217249/sqlite-and-concurrency
裡面提到 SQLite 的效能最高可以達到每秒五萬筆 INSERT,但會因硬碟的性能不同而有差異。而我要使用的環境別說每秒上萬筆,一秒有上百次操作就很了不起了。

於是寫了簡單的測試,看看在我機器上跑得怎麼樣:

本來想說每秒五萬筆的話,那我得弄個十萬筆才能執行超過一秒,結果沒想到這一跑就超過了半個小時還沒跑完。平均下來每秒只執行了 38 筆的操作。果然夢想與現實的差距就是這麼大嗎?

不可能吧。於是開始檢討差距這麼大的原因,第一個想到的是硬碟速度的問題,也確實在執行期間硬碟幾乎是一直忙碌的狀態。但我這已經是固態硬碟了,怎麼樣也不會這麼難看吧。而且這已經是少到不能再少的資料了,實際運用上一定會更多資料量的。

後來在這篇文章裡看到了 nosync 這個關鍵字:http://www.sqlite.org/speed.html
進而找到了這個說明:http://www.sqlite.org/pragma.html#pragma_synchronous

所以就開始了第二版的測試:

只加了一行,但這次只花了不到八秒就跑完了。算一算這樣每秒就有上萬筆的操作,雖然跟五萬筆還是差了一些,但應該是很夠用了。

ZendFramework 2 AbstractRestfulController

Zend Framework 2 有提供一個 AbstractRestfulController 用來實作 REST API。不過按照慣例,Zend Freamework 的說明文件都只是簡單帶過而已,真正的用法與規則還得去閱讀程式碼。

使用方法,就只要繼承 AbstractRestfulController 即可:

在 Router 那邊,記得不要設置 action:

之後,就會自動對應到 Controller 的 Method:

  • GET => getList()
  • GET + id => get($id)
  • POST => create($data)
  • PUT => replaceList($data)
  • PUT + id => update($id, $data)
  • DELETE => deleteList()
  • DELETE + id => delete($id)
  • HEAD => head($id)
  • OPTIONS => options()
  • PATCH => patchList($data)
  • PATCH + id => patch($id, $data)

因此,一個支援 GET 與 POST 的 Controller 大概長這樣:

其它沒有實作的部份,AbstractRestfulController 會幫你回應 405 Method Not Allowed 。

另外,identifier 的名稱,預設是用 “id”,為了可讀性,你也可以自訂 identifier,下面我們改用 “name” 作為 identifier:

相對應的 Router 也需要把 id 改為 name:

AbstractRestfulController 的用法大致上就這樣。

PHP include 的運作方式

PHP 的 include 暗藏了一些潛規則,如果沒搞懂的話,遇到問題會以為見鬼了。所以這篇主要就在研究 PHP 的 include 運作方式。

首先,我們從官方文件可以看到 include 會區分為兩種模式,一種是 include 檔案,另一種是 include 路徑。只要是絕對路徑,或是相對路徑,就是以 include 路徑來運作。這裡比較容易搞混的是相對路徑的部份,因為 PHP 只把 “.” 或 “..” 開頭的作為相對路徑看待。

因此 include “foo/bar.php” 是屬於 include 檔案,而 include “./foo/bar.php” 則是 include 路徑。

在 include 檔案時,會先從 include_path 開始搜尋,再來是搜尋此 PHP 程式所在的資料夾(the calling script’s own directory),最後是搜尋 current working directory(CWD)。

而在 include 路徑時,則只會從 CWD 去搜尋。

為了驗證,我設置了這樣的環境來作測試:

其中 lib{xx,yy,zz}.php 的內容都是一樣的:

include_priority.php 是將要執行的主程式,分別將 include_path 以及 CWD 設置到 inc_path 與 cwd 資料夾,這樣就能分辨優先順序,其內容是:

最終結果是這樣子:

由結果來看,符合文件中所描述的運作方式。

接著來驗證第二種情況,如果 a.php include b.php 且 b.php 又 include c.php 的話,那麼在排除 include_path 與 CWD 的情況下,會如何運作?
環境設置:

root.php 是主程式,內容為:

sub.php 的內容:

libxx.php 的內容與前一個實驗相同。
最後的輸出結果是:

由此可見程式所在的資料夾(非CWD)是會隨著 include 所在的檔案而變動的。換句話說,就是以這一行 include 語法所在的檔案的位置為主。

綜合以上的內容,就可以解釋下面這個看到鬼的例子了:

在 root.php 裡面 include 了 sub.php 檔案:

然後在 sub.php 裡面又分別 include libxx.php 與 tools.php 兩個檔案:

因為 include “library/libxx.php” 成功了,於是以為相對路徑是由 sub.php 所在位置來計算,因此又下了 include “../tools.php” 這樣的指令,結果死的不明不白。

其實 libxx.php 是以檔案的方式去 include 的,所以會搜尋三個地方:include_path,sub.php 所在的位置,以及 CWD。而 sub.php 所在的位置剛好就可以找到 library/libxx.php 這檔案,所以 include 成功。

在 include tools.php 時則是因為它以 “..” 開頭,所以只會從 CWD 來計算相對路徑找檔案。而此時的 CWD 是在 root.php 那邊,自然就找不到東西了。