2008-11-25 49 views
14

我正在爲我設計的論壇引擎添加頭像,並且我正在討論是否要做一些簡單的事情(論壇圖像命名爲.png),並使用PHP在顯示文件之前檢查文件是否存在,或者執行有些更復雜(但不多),並使用數據庫字段來包含要顯示的圖像的名稱。PHP中的file_exist()是一個非常昂貴的操作嗎?

我寧願個人使用file_exists()方法,因爲這給了我一個簡單的方法來回退到「默認」的頭像,如果當前的頭像不存在(還),它的簡單實施代碼明智。但是,我擔心的是性能,因爲這會在論壇閱讀頁面上針對每個用戶顯示的每個頁面負載運行一次。所以我想知道,PHP中的file_exists()函數是否會導致在高流量情況下會導致重大性能下降的重大減速?

如果不是,很好。如果確實如此,您對備選方案有何看法以追蹤用戶上傳的圖像?謝謝!

PS:我可以看到的代碼差異是文件檢查版本允許文件進行交談,而數據庫表單相信數據庫是準確的,不會檢查。 (它只是一個傳遞給瀏覽器的url)

回答

12

除了其他海報的說法,file_exists()的結果被PHP自動緩存以提高性能。

但是,如果您已經從數據庫中讀取用戶信息,那麼您最好將信息存儲在那裏。如果用戶只允許使用一個頭像,則可以在「有頭像」(1/0)的列中存儲一位,然後使用與用戶ID相同的文件名,並使用類似SELECT CONCAT(IF(has_avatar, id, 'default'), '.png') AS avatar FROM users

您也可以考慮將實際圖像作爲BLOB存儲在數據庫中。把它放在自己的表中,而不是將它作爲一個列附加到用戶表中。這有一個好處,它使您的論壇非常容易備份 - 只需導出數據庫即可。

7

由於你的web服務器在顯示你的網頁的過程中已經做了很多(相當於)file_exists()操作,通過腳本運行可能不會產生可衡量的影響。 Web服務器可能會做至少:

  • 一個用於Web根目錄的每個子目錄(檢查是否存在和符號連接)
  • 一個檢查.htaccess文件的Web根
  • 的每個子目錄
  • 一個用於存在您的腳本

這不考慮更多PHP可能會自己做的事情。

0

file_exists()本身並不慢。真正的問題是您的系統如何配置以及性能瓶頸在哪裏。請記住,數據庫也必須將事物存儲在磁盤上,所以無論哪種方式都可能面臨磁盤活動。另一方面,數據庫和文件系統通常都有某種形式的透明緩存來優化重複訪問。

你可以輕鬆地去任何一種方式,因爲機會是你的性能瓶頸將在別處。我可以看到它是一個明顯的選擇的唯一的地方是,如果你在某種超額共享主機上存在大量的磁盤爭用,但也許數據庫訪問在單獨的集羣上並且更快(反之亦然)。

0

在過去,我將圖像元數據存儲在數據庫(包括其名稱)中,以便我們可以生成有用的統計數據。更重要的是,存儲圖像數據(不是文件本身,只是元數據)是有利於改變。如果將來您需要「批准」圖像,或者您希望在不刪除文件的情況下將其刪除,該怎麼辦?

根據「默認」頭像...以及如果沒有找到該用戶的記錄,只需使用默認的。

無論哪種方式,file_exists()或db,它不應該是擔心的瓶頸。然而,一種解決方案更具可擴展性。

+0

你已經下了決心,我不知道爲什麼,這是一個很好的答案,我從來沒有想過自己。 – 2008-11-25 08:57:04

+0

我已經採納了一些追隨者,downvote我做的一切。 – 2008-11-25 09:48:33

0

如果性能是您唯一的考慮因素,file_exists()將比數據庫查找便宜得多。

畢竟這只是使用系統調用進行目錄查找。腳本的第一次執行後,相關目錄的大部分都將被緩存到存儲器中,因此實際上涉及的I/O非常少,並且「file_exists()」是一種常見操作,因此它和底層系統調用將非常高效在任何常見的php/os組合上進行了優化。

正如約翰二世指出的那樣。如果額外的功能和用戶界面功能是一個優先事項,那麼數據庫將是一條路。

8

在實際的性能測試中,您會發現file_exists非常快。就像這樣,在php中,當相同的url是「stat」的兩倍時,第二個調用只是從php的內部統計緩存中提取。

而這只是在PHP運行範圍。即使在運行之間,文件系統/ os也會傾向於將文件積極地放入文件系統緩存中,並且如果文件足夠小,不僅文件存在測試會直接從內存中出來,而且整個文件也會存在。

下面是一些真實的數據來支持我的理論:

我只是在做Linux的命令行工具,一些性能測試「發現」和「xargs的」。在收益中,我對13000個文件進行了文件存在測試,每個文件存在100次測試,時間不到30秒,因此平均每秒測試43,000次測試,因此,如果您比較它的話,它需要將9除以8,但在真實世界的場景中,您需要很多次這樣做才能看到顯着的性能問題。

如果你有43 用戶同時訪問期間,第二,我想你會比它需要複製文件的存在狀態的更多時間更大關注的時期你的網頁,或者在平均情況下出現內存不足的情況。

1

至少在PHP4中,我發現對file_exists的調用肯定是在殺死我們的應用程序 - 它在庫中非常深重,所以我們真的必須使用分析器才能找到它。刪除電話增加了一些頁面的計算十幾次(電話重複發生)。

它可能會在PHP5中緩存file_exists,但至少在PHP4中不是這種情況。

現在,如果你不在循環中,很明顯,file_exists不會是一個大問題。

相關問題