require_once指的是php內(nèi)部的變量和函數(shù)只會用一次；require_once需要比較php文件是否被包含過了，使用過多_once肯定會降低效率。建議把所有公用的函數(shù)放到一起，直接用require()函數(shù)

我主要是想知道，我用的上面那種文件類結(jié)構(gòu)會不會影響php性能，我的php速度大大降低的緣由是啥

如果一個方法能被靜態(tài)，那就聲明它為靜態(tài)的，速度可提高1/4，甚至我測試的時候，這個提高了近三倍。當(dāng)然了，這個測試方法需要在十萬級以上次執(zhí)行，效果才明顯。其實靜態(tài)方法和非靜態(tài)方法的效率主要區(qū)別在內(nèi)存：靜態(tài)方法在程序開始時生成內(nèi)存,實例方法在程序運行中生成內(nèi)存，所以靜態(tài)方法可以直接調(diào)用,實例方法要先成生實例,通過實例調(diào)用方法，靜態(tài)速度很快，但是多了會占內(nèi)存。任何語言都是對內(nèi)存和磁盤的操作,至于是否面向?qū)ο?只是軟件層的問題,底層都是一樣的,只是實現(xiàn)方法不同。靜態(tài)內(nèi)存是連續(xù)的,因為是在程序開始時就生成了,而實例申請的是離散的空間,所以當(dāng)然沒有靜態(tài)方法快。靜態(tài)方法始終調(diào)用同一塊內(nèi)存，其缺點就是不能自動進(jìn)行銷毀，而是實例化可以銷毀。

面對一個性能問題是，第一步永遠(yuǎn)是找到問題產(chǎn)生的原因，而不是去看技巧列表。搞明白產(chǎn)生瓶頸的原因，找到目標(biāo)并且實施修復(fù)，然后再重新測試。查找瓶頸只是萬里長征的第一步，這里有些常用技巧，希望對最重要的第一步找到瓶頸能有所幫助。

• 使用監(jiān)控方法（比如監(jiān)控寶），進(jìn)行benchmark和監(jiān)控，網(wǎng)絡(luò)，特別是網(wǎng)絡(luò)狀況瞬息萬變，做得好的話5分鐘就可以找到瓶頸。

• 剖析代碼。必須了解那部分代碼耗時最多，在這些地方多多關(guān)注。

• 想找到瓶頸，請檢查每個資源請求（比如，網(wǎng)絡(luò)、CPU、內(nèi)存、共享內(nèi)存、文件系統(tǒng)、進(jìn)程管理、網(wǎng)絡(luò)連接等等……）

• 先對迭代結(jié)構(gòu)和復(fù)雜的代碼進(jìn)行benchmark

• 在在真實負(fù)載下用真實數(shù)據(jù)進(jìn)行真實測試，當(dāng)然，如果可以最好用產(chǎn)品服務(wù)器。

緩存 （Caching）

有些人認(rèn)為緩存是解決性能問題最有效的辦法之一，試試這些：

• 使用OPCODE（操作碼）緩存，這樣腳本就不會在每次訪問時重新編譯一次。比如：啟用Windows平臺上的windows緩存擴(kuò)展?？梢跃彺鎜pcode，文件，相對路徑，session數(shù)據(jù)和用戶數(shù)據(jù)。

• 考慮在多服務(wù)器環(huán)境下使用分布式緩存

• 在調(diào)用imap_header()之前先調(diào)用imap_headers()

編譯 vs. 解釋（Compiling vs. Interpreting）

將PHP源碼編譯成機器碼。動態(tài)解釋執(zhí)行同樣的編譯，但它是按行執(zhí)行的。編譯為opcode是折中選擇，它可以將PHP源碼翻譯為opcode，之后opcode再轉(zhuǎn)為機器碼。以下為關(guān)于編譯與解釋的相關(guān)技巧：

• 上線之前將PHP代碼編譯為機器碼。opcode緩存盡管并不是最好的選擇，但依舊比解釋型來得強。或者，考慮將PHP代碼編譯成一個C擴(kuò)展。

• PHP的opcode編譯器（bcompiler)還不能在產(chǎn)品環(huán)境中使用

1.用單引號來包含字符串要比雙引號來包含字符串更快一些。因為PHP會在雙引號包圍的字符串中搜尋變量，單引號則不會。 2.如果能將類的方法定義成static，就盡量定義成static，它的速度會提升將近4倍。 3.$row['id'] 的速度是$row[id]的7倍。 4.echo 比 print 快，并且使用echo的多重參數(shù)(譯注：指用逗號而不是句點)代替字符串連接，比如echo $str1,$str2。 5.在執(zhí)行for循環(huán)之前確定最大循環(huán)數(shù)，不要每循環(huán)一次都計算最大值，最好運用foreach代替。 6.注銷那些不用的變量尤其是大數(shù)組，以便釋放內(nèi)存。 7.盡量避免使用__get，__set，__autoload。 8.require_once()代價昂貴。 9.include文件時盡量使用絕對路徑，因為它避免了PHP去include_path里查找文件的速度，解析操作系統(tǒng)路徑所需的時間會更少。 10.如果你想知道腳本開始執(zhí)行(譯注：即服務(wù)器端收到客戶端請求)的時刻，使用$_SERVER[‘REQUEST_TIME']要好于time()。 11.函數(shù)代替正則表達(dá)式完成相同功能。 12.str_replace函數(shù)比preg_replace函數(shù)快，但strtr函數(shù)的效率是str_replace函數(shù)的四倍。 13.如果一個字符串替換函數(shù)，可接受數(shù)組或字符作為參數(shù)，并且參數(shù)長度不太長，那么可以考慮額外寫一段替換代碼，使得每次傳遞參數(shù)是一個字符，而不是只寫一行代碼接受數(shù)組作為查詢和替換的參數(shù)。 14.使用選擇分支語句(譯注：即switch case)好于使用多個if，else if語句。 15.用@屏蔽錯誤消息的做法非常低效，極其低效。 16.打開apache的mod_deflate模塊，可以提高網(wǎng)頁的瀏覽速度。 17.數(shù)據(jù)庫連接當(dāng)使用完畢時應(yīng)關(guān)掉，不要用長連接。 18.錯誤消息代價昂貴。 19.在方法中遞增局部變量，速度是最快的。幾乎與在函數(shù)中調(diào)用局部變量的速度相當(dāng)。 20.遞增一個全局變量要比遞增一個局部變量慢2倍。 21.遞增一個對象屬性(如：$this->prop++)要比遞增一個局部變量慢3倍。

1 總覽頁面能夠提供全面的 PHP 健康狀態(tài)監(jiān)控。Apdex 圖表能夠直觀展示真實用戶體驗，通過對比響應(yīng)時間和吞吐量，能夠第一時間知曉是否出現(xiàn)了性能問題，而通過 Web 事務(wù)和錯誤率，能夠直觀的看到問題所在，如果事件觸發(fā)了您預(yù)先設(shè)定的報警規(guī)則，告警信息將在第一時間發(fā)出，助您快速響應(yīng)。 2 OneAPM 通過對代碼執(zhí)行流程進(jìn)行深入的分析，提供精確到行級別的高耗時代碼。對于高耗時的 SQL 操作，同樣能夠完整展示混淆過的 SQL 語句，以及執(zhí)行時間和執(zhí)行次數(shù)等。3 OneAPM 能夠?qū)?PHP 調(diào)用的第三方 API 的響應(yīng)時間進(jìn)行全面監(jiān)控，并從多個維度對數(shù)據(jù)進(jìn)行排序，直觀準(zhǔn)確的展示出由于第三方 API 響應(yīng)慢造成的性能下降，配合 Browser Insight 產(chǎn)品更能夠進(jìn)行更詳細(xì)的網(wǎng)絡(luò)監(jiān)控，能夠精確展示網(wǎng)絡(luò)請求中每一步的耗時。

單臺服務(wù)器性能始終有極限，最好就是做分布式，把流量分?jǐn)偟蕉嗯_服務(wù)器。數(shù)據(jù)庫也可以做讀寫分離，所有大型網(wǎng)站都是這么構(gòu)架的。

Java 僅從語言上說, 比PHP快很多。但是實際操作當(dāng)中 java慢很多。因為PHP大量的庫 是直接進(jìn)行數(shù)據(jù)轉(zhuǎn)換之后調(diào)用C庫實現(xiàn)，且由于 代碼更加簡練、輕量， 比java快多了。當(dāng)然，網(wǎng)站性能還要通過其它技術(shù)手段進(jìn)行優(yōu)化。

首先在php.ini中設(shè)置文件上傳的大小，file_uploads = On ;打開文件上傳upload_max_filesize = 100M ;上傳上限本回答被網(wǎng)友采納

以上是  [精通正則表達(dá)式(第三版)].（美）佛瑞德.掃描版   上面的內(nèi)容，供參考。