PHP5.1 5000個數字快速排序平均回應時間2587ms
PHP5.2 5000個數字快速排序平均回應時間2625ms
PHP5.3 5000數量快速排序平均回應時間2509ms
PHP5.4 5000個數字快速排序平均回應時間2339ms
PHP7.0 5000個數字快速排序平均回應時間685ms
# PHP5.1 WordPress平均回應時間505ms
PHP5.2 WordPress平均回應時間521ms
PHP5.3 WordPress平均回應時間498ms
PHP5.4 WordPress平均回應時間470ms
PHP7. 0 WordPress平均回應時間158ms
PHP5.4 500個數快速排序TPS 552
PHP7.0 500個數快速排序TPS 3165
Flyme社群APP首頁PHP5.4 TPS 1535
Flyme社群APP首頁PHP7.0 TPS 1975
Flyme社群APP板塊清單頁PHP5.4 TPS 2237
FlymeAPP社群板塊板塊清單頁PHP7.0 TPS 2387
2. Zval的改變
3. 內部類型zend_string
4. PHP陣列的變化(HashTable和Zend Array)
5. 函數呼叫機制(Function Calling Convention)
6. 透過巨集定義和內聯函數(inline),讓編譯器提前完成部分工作
經過性能測試,相對直接連接redis而已,用Proxy的性能損耗在10-15%左右(不同的業務可能影響有比較大的差異)
Atlas 是360開發和維護的資料庫中間件。是一個位於應用程式與MySQL之間,它實作了MySQL的客戶端與服務端協議,作為服務端與應用程式通訊,同時作為客戶端與MySQL通訊。它對應用程式屏蔽了DB的細節,同時為了降低MySQL負擔。
Atlas 支援主庫宕機不影響讀取、讀寫分離、自動分錶、安全處理、平滑重啟、連接池等
用了資料庫連接池後TPS性能槓槓的整整提高了80%
來看看效果吧
Opcache是如何加速的
#看看加了opcache後的成果吧(請求平均反應時間足足減少了一倍有木有)
PGO是一項編譯最佳化技術,它可以配合GCC等編譯器使用,提升編譯器的編譯效率。
雖然PGO可以提高編譯效率,但它並沒有被廣泛使用。
原因很簡單:
1. 它繁雜的雙編譯模型和有限的使用場景,讓PGO顯得很雞肋
2. 在有了opcache這樣的產品出現後,PGO帶來的性能提升並不是很明顯。
<source lang="xml" collapse="false" first-line="1"> #php-fpm.conf listen = /dev/shm/php-fcgi.sock #php-fpm2.conf listen = /dev/shm/php-fcgi2.sock #/usr/local/php/sbin/php-fpm --fpm-config /usr/local/php/etc/php-fpm.conf #/usr/local/php/sbin/php-fpm --fpm-config /usr/local/php/etc/php-fpm2.conf #代理 upstream backend{ server unix:/dev/shm/php-fcgi.sock; server unix:/dev/shm/php-fcgi2.sock; } </source>
HugePage(提升2%-3%)
<source lang="xml" collapse="false" first-line="1"> opcache.enable=1 opcache.enable_cli=1 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 opcache.save_comments=0 opcache.fast_shutdown=1 opcache.huge_code_pages=1 opcache.file_cache=/dev/shm/opcache/ </source>
<source lang="xml" collapse="false" first-line="1"> listen = /dev/shm/php-fcgi.sock pm = static pm.max_children = 320 pm.max_requests = 10240 </source>
以上是一分鐘了解PHP7性能的蛻變(性能提升4倍)的詳細內容。更多資訊請關注PHP中文網其他相關文章!