2010-06-17 40 views
1

我想:ColdFusion的速度成本

  • 每一頁上,如果文件存在
  • 檢查
  • 包括文件,如果真

即:

<cfset variables.includes.header = ExpandPath("_inc_header.cfm")> 
<cfif FileExists(variables.includes.header)> 
    <cfinclude template = "_inc_header.cfm"> 
</cfif> 

這是個好主意嗎?

編輯只使用「_inc_header.cfm」作爲模板

替代實際應用將這個PHP代碼一些類似於:

foreach (glob("includes/*.php") as $inc) { 
    require($inc); 
} 
+0

它有可能不存在的特定原因嗎? – 2010-06-17 15:41:46

+0

是的,有一個全局頭包含,然後該網站的一些子部分將有自己的包含 – davidosomething 2010-06-17 15:43:14

+0

更具體地說,有一個全局頭包含在執行頁面的路徑中包含另一個子頭文件。該網站的一些小節有這個subheader,有些則不。想知道這是否是存儲變量並根據是否使用子標題更新每個頁面的好替代。 – davidosomething 2010-06-17 15:48:46

回答

1

根據流量,有可能是位的表現。

您可以將include語句放在try/catch中嗎?或者失敗了,可能會將檢查結果保存在一個會話中,然後每個會話每個文件只執行一次檢查?

+0

我可以做try/catch,你會碰巧知道失敗的比FileExists更快嗎? 我不認爲我會保存會話中的值,除非它是確實存在的頭部路徑數組。然後我將不得不在數組中找到一個值,它不保存任何內容,是嗎? – davidosomething 2010-06-17 15:46:26

+0

取決於我猜測的文件數量。我認爲try/catch可能是最好的,因爲它只是調用一個文件並運行它,如果它在那裏,那就是你想要的。通過執行檢查然後包括它,它會產生兩次命中。 – Sam 2010-06-17 15:53:14

+2

在大量情況下會引發異常的情況下,要小心try/catch方法。 (如果你的負載很重,甚至可能低至10%)。異常需要花費大量的時間來處理和捕捉,並且可能是應用程序中的一個重要瓶頸。我會申請自由緩存,如果你確實使用fileExists()方法;儘管我會緩存在應用程序或服務器範圍內,而不是Session。 – 2010-06-17 16:29:03

0

,我認爲更好的辦法是隻檢查標題變量在variables.include結構存在:

<cfif structkeyexists(variables.includes, "header")> 
    <cfinclude template = "#variables.includes.header#"> 
</cfif> 

如果一個頁面是不會使用的頭然後在網頁代碼刪除標題:

<cfset structdelete(variables.include, "header", false)> 
+0

當前的體系結構就是這樣,我正在試圖改進,前面說過。 – davidosomething 2010-06-17 16:56:01

0

問:你會怎麼cfinclude絕對文件路徑的文件通過ExpandPath("_inc_header.cfm")回來了?

無論如何,您的問題應該聽起來像「ColdFusion ExpandPath + FileExists的速度成本」,因爲每次調用兩個函數。

如果沒有基準測試,無法幫助您,但可以使用類似於由rip747提出的內容。但是我會在一些早期階段(至少在應用程序開始時,也許在開發過程中)收集可用的頭文件,並使用該集合進行檢查。集合密鑰可以是當前目錄路徑,也可以是唯一的子部分代碼(如果可用)。

+0

在原始問題中編輯代碼,不使用絕對路徑,使用與調用模板的頁面相同的路徑使用_inc_header.cfm文件。 – davidosomething 2010-06-17 17:01:39

0

我可能會創建一個名爲application.header的應用程序變量,並從標題中放入html。

然後在每個應用程序中,我可以檢查isdefined和if null。

例如:

在application.cfm

<cfparam name="application.header=" default=""> 
<cfset application.header="<img src=/images/logo.png alt='Logo' border=0>" /> 

在您的應用程序頁面。

<cfif isdefined("application.header") and application.header gt ""> 
<cfoutput> 
#application.header# 
</cfoutput> 
</cfif> 

有你去..

0

我曾經認爲像你這樣做,但我也大量監測我的執行時間。由於更改爲每次請求多次調用FileExists的系統,我已經注意到加載頁面所需的毫秒數爲0毫秒。這完全有可能比給定文件上的任何頻繁查找都會導致它在系統或SCSI驅動程序或驅動器硬件中的某處緩存。更有可能的是,SCSI硬件上的查找時間是毫秒級。

鑑於我使用cfinclude很重要,一個更多的查詢甚至不顯示在雷達上並不奇怪。

現實情況是它可能比變量查找花費更多,但我們可能會說0.0001毫秒的差異,除非你在目錄中有數百萬個文件,或者你正在運行一個關閉IDE磁盤的網絡服務器或類似這樣的傻事。除非你是/,否則額外的代碼複雜性可能不值得節省。或蘋果什麼的。

對於那些說這是糟糕的建築我討論不同。在中長期內,您可以購買比開發者時間便宜得多的處理器。有一個只需要改變文件的系統比改變文件和變量更簡單 - 並且處理額外的複雜性。像優化類別中的大多數事情一樣,保存少量MS的許多任務可能會花費數小時,可能會花費在更有效的措施(如改進緩存)上。

2

我有同樣的問題,因爲我有一個數百項目的列表,其中每個項目與一個或多個文件相關。我想檢查每個文件的存在以進行概述。因爲我在這裏沒有找到答案,所以我在列表中勾選了FileExists函數,結果爲:「總執行時間FileExits爲7,876個文件:0.11秒」。

我認爲FileExits絕對沒有問題。