php基準測試,php標準

本文目錄一覽：

• 1、對於大型系統PHP為什麼令人不爽
• 2、PHP5.5 和PHP5.6的區別
• 3、學PHP開發有前途嗎？

對於大型系統PHP為什麼令人不爽

我在過去的四年里一直致力於PHP應用的開發。PHP確實十分容易編寫。但是PHP也有一些十分嚴重的缺陷。下面我會給出我的理由，為什麼PHP不適合於比小型業餘網站更大的網站。1. 對遞歸的不良支持遞歸是一種函數調用自身的機制。這是一種強大的特性可以把某些複雜的東西變得很簡單。有一個使用遞歸的例子是快速排序(quicksort)。不幸的是，PHP並不擅長遞歸。Zeev，一個PHP開發人員，說道：「PHP 4.0(Zend)對密集數據使用了棧方式，而不是使用堆方式。也就是說它能容忍的遞歸函數的數量限制和其他語言比起來明顯少。」見bug 1901。這是一個很不好的借口。每一個編程語言都應該提供良好的遞歸支持。2. 許多PHP模塊都不是線程安全的在幾年前，Apache發佈了Web服務器的2.0版。這個版本支持多線程模式，在這個模式下，軟件一個一部分可以同時運行多個。PHP的發明者說PHP的核心是線程安全的，但是非核心模塊不一定是。但是十次有九次，你想要在PHP腳本中使用這種模塊，但這又使你的腳本不能合適Apache的多線程模式。這也是為什麼PHP小組不推薦在Apache 2 的多線程模式下運行PHP。不良的多線程模式支持使PHP常被認為是Apache 2依然不流行的原因之一。3. PHP 由於商業原因而不健全通過使用緩存，PHP的性能可以陡增500%[見基準測試]。那麼為什麼緩存沒有被構建在PHP中呢?因為Zend——PHP的製造者，它在銷售自己的Zend Accelerator，所以當然，他們不想拋棄自己的商業產品這塊肥肉。但是有另一個可選擇的： APC. (Zend後來推出Zend Optimizer，免費的加速器——譯者)4. 沒有命名空間設想某個人製作了一個PHP模塊用來閱讀文件。模塊中一個函數叫做read。然後另一個人的模塊可以讀取網頁的，同樣包含一個函數read。然後我們就無法同時使用這兩個模塊了，因為PHP不知道你要用哪個函數。 但是有一個很簡單的解決方法，那就是命名空間。曾經有人建議PHP5加入這個特性，但不幸得是他沒有這麼做。現在，沒有命名空間，每個函數都必須加上模塊名作為前綴，來避免名稱衝突。這導致了函數名恐怖得長，例如xsl_xsltprocessor_transform_to_xml讓代碼難於書寫和理解。5. 不標準的日期格式字符很多程序員對 日期格式字符 都很熟悉，它是從UNIX和C語言中來的。其他一些編程語言採用了這個標準，但是很奇怪的，PHP有它自己的一套完全不兼容的日期格式字符。在C中，「%j」表示一年中的當天，在PHP中他表示一個月中的當天。然而使事情更混亂的是：Smarty (一個很流行的PHP模版引擎)的 strftime 函數和 date_format 函數，卻使用了C/UNIX的格式化字符。6. 混亂的許可證你也許認為PHP是免費的，所有的在手冊中提到的PHP模塊也是免費的。錯了!例如，如果你想在PHP中生成PDF文件，你會在手冊中發現兩個模塊：PDF 和 ClibPDF。但是這兩個都是有商業許可證的。所以，你所使用的每個模塊，你都要確保你同意他的許可證。7. 不一致的函數命名規則有些函數名稱是有多個單詞組成的。一般有三種單詞組合的習慣：直接拼接：getnumberoffiles用下劃線分開：get_number_of_files駱駝法則：getNumberOfFiles大部分語言選擇其中一中。但是PHP都用到了。例如，你想要把一些特殊字符轉換成HTML實體，你會使用函數htmlentities (直接拼接單詞)。如果你要使用相反的功能，你要用到它的小弟弟html_entity_decode。由於某些特殊的原因，這個函數名是由下劃線分隔單詞。怎麼能這樣呢?你知道有一個函數叫strpad。或者他是str_pad?每次你都要查看一下到底這個符號是什麼或者直接等他出現一個錯誤。函數是不分大小寫的，所以對於PHP來說rawurldecode 和RawUrlDecode之間沒有什麼區別。這也很糟糕，因為兩個都使用到了同時他們看上去還不一樣，混淆了閱讀者。8. 魔法引用的地獄魔法引用(Magic quote)可以保護PHP腳本免受SQL注入攻擊。這很好。但是出於某些原因，你可以在php.ini中關閉這個配置。所以你如果要寫出一個有彈性的腳本，你總要檢查魔法引用是開啟還是關閉。這樣一個「特性」應該讓編程更簡單，而事實上變得更複雜了。9. 缺少標準框架一個成長中的網站沒有一個整體框架，最終會變成維護的噩夢。一個框架可以讓很多工作變得簡單。現在最流行的框架模型時MVC-模型，在其中表現層、業務邏輯和數據庫訪問都分離開了。很多PHP網站不使用MVC-模型。他們甚至沒有一個框架。甚至現在有一些PHP框架同時你都可以自己寫一個，關於PHP的文章和手冊沒有提高框架的一個字。同時JSP-開發人員使用像Struts的框架、ASP開發人員使用.Net，看起來好像這些概念都廣泛被PHP開發人員所了解。這就說明了PHP實際上到底是多專業。總結什麼問題?對於非常小的項目，它可以是一個十分符合人意的編程語言。但是對於較大的和更為複雜的項目，PHP就顯出他的薄弱了。當你不斷地摸索之後，你會發現我提到的某些問題的解決方案。所以，當解決方案已知之後，為什麼不能修正他呢?另外為什麼這些修補不在手冊中提到呢? 一個開源的語言十分流行是一件好事。但不幸得是，它不是一個偉大的語言。我希望所有的問題能有一天得到解決(也許在PHP6?)，然後我們就將擁有一個開源語言，他既開源，又好用。到現在，當你要啟動一個多於5個腳本頁面的項目的時候，你最好考慮C#/ASP.Net 或者 Java/JSP或者也許Python同樣是一個更好的選擇。

PHP5.5 和PHP5.6的區別

PHP5.5 和PHP5.6的區別

摘要：在一個基於Vagrant的本地環境中，可能是某個錯誤的原因，導致HHVM測試結果很差；在HHVM夥伴們協助下，該原因仍在研究中！然而，在DigitalOcean的一個4GB虛擬機中，HHVM甚至蓋過了最新版的PHP-NG的風頭！

結論：它們反映出HHVM的功效更佳（在JIT熱啟動後），雖然出於某些原因，我們不能在所有裝備中獲取這些結果。

如果你記得我們在幾個月前寫過一篇文章，那時WordPress 3.9表明是完全支持HHVM的，當時是那麼令我們歡欣鼓舞。最初的基準測試結果顯示，HHVM要比驅動着當前所有PHP構建的Zend引擎高級得多。後來，問題就出來了：

HHVM只能以單個用戶運行，這意味着（在共享環境中）安全性差了

HHVM在崩潰後不會自動重啟，而不幸的是，它至今仍然經常發生

HHVM在啟動時使用大量內存，雖然，它和同規模的PHP-FPM比較，單個請求的內存使用量更低

很顯然，你不得不根據你的（或者更確切地說是你的站點）的需求採取折中方案，然而這值得嗎？切換到HHVM後，你期望獲得多少性能改善呢？

在Kinsta，我們真的想要測試所有新技術，並通常會優化這一切來為我們的客戶提供最佳的環境。今天，我最終花了點時間來配置測試環境並進行了一些測試來對比兩個不同的構建，一個是全新出爐的WordPress安裝，另外一個則添加了大量內容的WooCommerce！為了計量腳本的運行時間，我只是簡單地添加了

?php timer_stop(1); ?

這一行到footer.php的/body標記前。

這裡是配置環境的詳情：

DigitalOcean 4GB 雨滴容器 (2 CPU核心, 4GB RAM)

Ubuntu 14.04, MariaDB10

測試站點： 已導入演示內容的Munditia主題，WooCommerce 2.1.12 WordPress 3.9.1

PHP 5.5.9, PHP 5.5.15, PHP 5.6.0 RC2, PHP-NG （20140718-git-6cc487d）和HHVM 3.2.0 （版本是PHP 5.6.99-hhvm）

沒有進一步大費周章，這些就是我的測試結果，數值越低越好，以秒為單位：

DigitalOcean 4GB 雨滴容器

單位是秒，運行10次，越低越好

看起來似乎PHP-NG在它首次運行後就獲得了峰值性能！HHVM需要更多幾次重載，但是它們的性能貌似差不多！我等不及PHP-NG合併到開發主幹了！：）

一分鐘命中數，越高越好。

PHP 5.5.15禁用OpCache

執行： 236 hits

可用性： 100.00 %

消耗時間： 59.03 secs

傳輸的數據： 2.40 MB

回應時間： 2.47 secs

執行率： 4.00 trans/sec

吞吐量： 0.04 MB/sec

並發數： 9.87

成功的執行： 236

失敗的執行： 0

最長執行： 4.44

最短執行： 0.48

PHP 5.5.15啟用OpCache

執行： 441 hits

可用性： 100.00 %

消耗時間： 59.55 secs

傳輸的數據： 4.48 MB

回應時間： 1.34 secs

執行率： 7.41 trans/sec

吞吐量： 0.08 MB/sec

並發數： 9.91

成功的執行： 441

失敗的執行： 0

最長執行： 2.19

最短執行： 0.64

PHP 5.6 RC2禁用OpCache

執行： 207 hits

可用性： 100.00 %

消耗時間： 59.87 secs

傳輸的數據： 2.10 MB

回應時間： 2.80 secs

執行率： 3.46 trans/sec

吞吐量： 0.04 MB/sec

並發數： 9.68

成功的執行： 207

失敗的執行： 0

最長執行： 3.65

最短執行： 0.54

PHP 5.6 RC2啟用OpCache

執行： 412 hits

可用性： 100.00 %

消耗時間： 59.03 secs

傳輸的數據： 4.18 MB

回應時間： 1.42 secs

執行率： 6.98 trans/sec

吞吐量： 0.07 MB/sec

並發數： 9.88

成功的執行： 412

失敗的執行： 0

最長執行： 1.93

最短執行： 0.34

HHVM 3.2.0（版本是PHP 5.6.99-hhvm）

執行： 955 hits

可用性： 100.00 %

消耗時間： 59.69 secs

傳輸的數據： 9.18 MB

回應時間： 0.62 secs

執行率： 16.00 trans/sec

吞吐量： 0.15 MB/sec

並發數： 9.94

成功的執行： 955

失敗的執行： 0

最長執行： 0.85

最短執行： 0.23

PHP-NG啟用OpCache（構建: Jul 29 2014）

執行： 849 hits

可用性： 100.00 %

消耗時間： 59.88 secs

傳輸的數據： 8.63 MB

回應時間： 0.70 secs

執行率： 14.18 trans/sec

吞吐量： 0.14 MB/sec

並發數： 9.94

成功的執行： 849

失敗的執行： 0

最長執行： 1.06

最短執行： 0.13

學PHP開發有前途嗎？

隨着Web2.0的提出和發展，互聯網行業迎來新一波的熱潮，由於互聯網本身快速發展、不斷創新的特點，決定了只有以最快開發速度和最低成本，才能贏得勝利，才能始終保持網站的領先性和吸引更多的網民。互聯網的企業生存和競爭的核心在於技術，技術、研發人才永遠是這些企業不可或缺的關鍵性人物，具備優質的人才團隊和領先技術，才能在最短的時間內創造出更優秀的網絡應用。

       PHP擁有非常強大的生態群，包括免費的網站內容管理系統(PHPCMS，DedeCMS，帝國CMS)，免費的商城系統(ShopEX，ShopNC)，免費微信管理系統(微擎，小豬CMS，微易)，免費的社交論壇系統(Discuz和PHPWind)，甚至免費的OA，免費的資料管理，客戶關係管理系統等。企業可以免費使用這些系統，強大的生態群為企業降低了人力資源成本。

在未來，這些系統均需要PHP程序員來維護開發。這些開源免費的系統，佔據市場份額後，他們的創使人又特別容易走向自主創業的道路，而這些系統均需要PHP程序員去維護。PHP作為服務端語言，需要了解的知識體系非常全面和豐富。由PHP入手，進入到未來互聯網技術的頂端序列——架構師，是一個非常不錯的選擇。

以國內動態網站來說，超過80%都在使用PHP技術，少數普通PHP程序員無論從數量還是質量上都無法滿足龐大的市場需求，在一個信息科技快速發展的時代，自然需要PHP的快速開發來實現。也就說PHP是不可或缺而且需求量很大。同時php本身的易用性和多平台實用性是其他開發技術難以比擬的。

它驅動全球超過2億多個網站，有全球超過81.7%的公共網站在服務器端採用php。不僅如此，據統計，有78.1%從事php的人認為php最容易學習和上手。這是因為php常用的數據結構都內置了，使用起來方便簡單，也一點都不複雜，表達能力相當靈活。

像京東、淘寶、天貓、Google、百度、新浪、騰訊QQ、微信等很多互聯網相關企業都在使用php開發框架，所以可以說市場對php的開發程序員的需求還是比較大的。通過各個招聘網站搜索php工程師，得出的數字讓我們兩眼放光，智聯招聘php的招聘崗位高達43081個;前程無憂的招聘崗位人數達46008;獵聘網的相關數據為6013個，可見php的需求多，職位也多.

而且php7的提出，使得php在不斷兼容着類似closures和命名空間等技術，同時兼顧性能和當下流行的框架。版本是7之後，一直在提供更高性能的應用，在一些WordPress基準測試當中，性能可以達到php 5.6的3倍。PHP 7包含了一些重大安全改進，如除去php安全模式，添加魔術引號，有一些新的保留關鍵字等等。

從以上幾個方面分析來看，PHP的就業前景還是很好的，學PHP開發是一個不錯的選擇。