标签归档：php

php 7.2 安装 mcrypt 扩展

升级 php 7.2 后，使用微信提供的加解密代码时，提示 call to undefined function mcrypt_module_open() ；大脑疯狂运转1秒钟后，得出结论：php 7.2的扩展有变动；查阅相关资料知晓，mcrypt 扩展从 php 7.1.0 开始废弃；自 php 7.2.0 起，会移到 pecl。还好，安装过程不复杂。

环境：centos 7

yum 安装依赖包：

yum install libmcrypt libmcrypt-devel mcrypt mhash

在 php 官网下载 mcrypt 包，php 扩展官网

# wget http://pecl.php.net/get/mcrypt-1.0.3.tgz

# tar xf mcrypt-1.0.3.tgz

# cd mcrypt-1.0.3

编译安装 mcrypt

# /usr/local/php/bin/phpize

# ./configure –with-php-config=/usr/local/php/bin/php-config && make && make install

在php.ini加上扩展即可

extension=mcrypt.so

重启 php-fpm

/etc/init.d/php-fpm restart

权威的5.6、7.0、7.1、7.2、7.3和7.4 PHP基准性能测试（2020）

每年，我们都会在各种平台上发布深入的性能基准测试，以了解不同版本的PHP如何相互竞争。这次我们再次全力以赴，将22个不同平台/配置的6个不同PHP版本标记为基准;包括WordPress，Drupal，Joomla！，Laravel，Symfony等。我们还测试了流行的电子商务解决方案，例如WooCommerce，Easy Digital Downloads，Magento，Grav CMS和October CMS。

我们一直在鼓励WordPress用户利用最新支持的PHP版本。它们不仅更安全，而且还提供了其他性能改进。我们也不是只在谈论WordPress，这在所有平台上都是如此。今天我们将向您展示PHP 7.4如何帮助我们克服一切挑战！ ?

我们在6个不同的PHP版本上测试了22个平台/配置的性能，而#PHP 7.4在17/17（5 N / A）上获得了金牌。 ??

点击鸣叫

社区和Kinsta中PHP的状况

PHP是一种开放源代码的服务器端脚本和编程语言，主要用于网络开发。大部分WordPress核心软件都是用PHP编写的，这使PHP成为WordPress社区非常重要的语言。

只需移至Kinsta，即可将WordPress网站的速度提高200％。

今天免费迁移

有人可能会争辩说PHP已经死了。但是，即使开发人员喜欢声明这一点，PHP仍然比以往更活跃，更快，更好。根据W3Techs的说法，使用服务器端编程语言的所有网站中有超过78.9％使用PHP。那是很多依赖PHP的网站。

但是，社区中的一个大问题是，许多人仍在使用旧的不受支持的PHP版本。根据WordPress统计，仅38.3％的版本在受支持的PHP版本（7.2或更高版本）上运行。这引入了性能和安全性问题。

为什么会这样呢？以下是一些我们通常会看到的常见原因：

缺乏对社区进行有关PHP是什么及其在WordPress如何发挥作用方面的重要作用的教育。并非每个人都精通技术，这还可以。
在较新版本的PHP上运行的插件和主题的兼容性问题。
WordPress托管提供商不愿推出新版本，因为担心会出现问题。

为了尝试帮助社区向前发展，Kinsta采用了与PHP相同的寿命终止（EOL）时间表。这有助于确保您的WordPress网站尽可能快且安全。

Kinsta客户如何与普通WordPress社区对抗？我们自己很好奇，所以我们看了一些数字。

Kinsta托管的网站的PHP版本

这是摘要：

Kinsta的WordPress网站中有25.8％运行的是PHP 7.2。
Kinsta上有68.6％的WordPress网站正在运行PHP 7.3。
Kinsta的4.7％WordPress网站都在运行PHP 7.4。
我们正在努力实现最终的<1％。 ?

我们为发现这些数字感到骄傲和兴奋。这意味着Kinsta客户中PHP的采用率非常高！远远高于一般的WordPress人口。

在Kinsta托管的所有WordPress网站中，高达73.3％运行的是PHP 7.3或更高版本！ ?

点击鸣叫

PHP基准测试（2020）

即使不再正式支持PHP 5.6、7.0和7.1，仍然有许多WordPress网站在运行。因此，我们决定测试所有六个不同的PHP版本，以便您可以看到较新的版本可以在性能方面给您带来多少好处。

对于每个测试，我们使用每个平台的最新版本，并以15个并发用户为基准对主页进行一分钟的基准测试。以下是我们测试环境的详细信息。

使用的计算机：英特尔（R）至强（R）CPU（30 CPU，120 GB RAM，1TB SSD）。这是由Google Cloud Platform提供支持的“计算优化”（C2）计算机，在隔离的容器中运行。所有Kinsta托管计划都提供C2机器。
操作系统：Ubuntu 18.04.3 LTS（GNU / Linux 5.0.0-1026-gcp x86_64）
堆栈：Nginx 1.17.6，MariaDB 10.4.10
PHP版本：5.6、7.0、7.1、7.2、7.3、7.4。
注意：在某些CMS / Frameworks中，我们还安装了其他PHP软件包以满足其新要求或Composer依赖项要求。
页面缓存：在所有配置和平台上均禁用。
OPcache：对于WordPress，Joomla和Drupal，我们使用了官方的Docker映像。其余的我们使用相同的映像设置，并使用以下推荐的php.ini设置启用了OPcache，但opcache.max_accelerated_files的值从4,000增加到50,000。

opcache.memory_consumption = 128
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 50000
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1
opcache.enable_cli = 1

OPcache通过将预编译的脚本字节码存储在共享内存中来提高PHP性能，从而消除了PHP在每个请求上加载和解析脚本的需求。

这些测试是由Kinsta的WordPress贡献者和Web开发人员Thoriq Firdaus执行的。

经过测试的平台和配置

我们的测试包括以下22种平台/配置。在某些情况下，由于缺乏对特定PHP版本的支持，我们不得不测试多个版本。单击下面的一个可直接跳至其测试说明和结果。数据以每秒请求数衡量。请求越多越好。

WordPress 5.3
WordPress 5.3 + WooCommerce 3.8.1
WordPress 5.3 +简易数字下载2.9.20
Drupal 8.8.0
Joomla！ 3.9.13
Magento 2（CE）2.2.10 + 2.3.3
Grav CMS 1.6.19
十月CMS 1.0.458
Laravel 5.8.35 + 6.7.0
Symfony 4.4.2 + 5.0.1
CodeIgniter 3.1.11 + 4.0-rc.3
CakePHP 3.8.7 + 4.0.0
PyroCMS 3.7
Pagekit 1.0.17
螺栓CMS 3.7.0
Craft CMS 3.4.0-beta.4
ExpressionEngine 5.3.0

由于每个平台上的演示内容可能会发生很大变化，因此，我们决定测试新的准系统安装的原始性能。

WordPress 5.3

当然，我们测试的第一个平台是我们最喜欢的平台之一：WordPress（我们每天都会生活和呼吸CMS，这可能会有点偏bias）。 WordPress的核心是开源软件，您可以使用它来创建漂亮的网站，博客或应用。实际上，WordPress占Internet上所有网站的35.2％。是的-您访问的网站中，有超过三分之一是由WordPress提供支持的。

我们从WordPress 5.3开始，它是撰写本文时的最新版本。我们使用了新的Twenty Twenty主题，并与15个并发用户对网站进行了基准测试一分钟。

经过测试的网址：/ hello-world /
注意：该页面包含1条注释，一个带有几个菜单的导航栏。侧边栏包含一些默认的WordPress小部件。
Docker镜像源自https://hub.docker.com/_/wordpress/。

WordPress 5.3 PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

WordPress 5.3 PHP 5.6基准测试：97.71 req / sec
WordPress 5.3 PHP 7.0基准测试结果：256.81 req / sec
WordPress 5.3 PHP 7.1基准测试结果：256.99 req / sec
WordPress 5.3 PHP 7.2基准测试结果：273.07 req / sec
WordPress 5.3 PHP 7.3基准测试结果：305.59 req / sec
WordPress 5.3 PHP 7.4基准测试结果：313.42 req / sec

PHP 7.4是赢家，被证明比PHP 7.3快一点。而且，如果将PHP 7.4与PHP 5.6进行比较，它每秒可处理的请求（事务）数量是3倍以上！

WordPress 5.3 + WooCommerce 3.5.2

WooCommerce是为WordPress构建的完全可自定义的开源电子商务平台。到目前为止，它也是WordPress社区中最受欢迎的电子商务解决方案之一，目前为互联网上所有电子商务网站中的14％以上的网站提供支持。

在下一个测试中，我们将WordPress和WooCommerce一起安装。我们利用了免费的Storefront eCommerce主题（2.5.3）。

经测试的网址：/ product / woo-ninja /
注意：此页面包含3个相关产品，1个产品评论/评论，“您可能也喜欢”部分中的1个产品以及下一个和上一个分页中的产品。
Docker镜像源自https://hub.docker.com/_/wordpress/。

WordPress 5.3 + WooCommerce PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

WordPress 5.3 + WooCommerce 3.8.1 PHP 5.6基准测试结果：49.29 req / sec
WordPress 5.3 + WooCommerce 3.8.1 PHP 7.0基准测试结果：117.35 req / sec
WordPress 5.3 + WooCommerce 3.8.1 PHP 7.1基准测试结果：117.52 req / sec
WordPress 5.3 + WooCommerce 3.8.1 PHP 7.2基准测试结果：125.85 req / sec
WordPress 5.3 + WooCommerce 3.8.1 PHP 7.3基准测试结果：141.68 req / sec
WordPress 5.3 + WooCommerce 3.8.1 PHP 7.4基准测试结果：146.07 req / sec?

在运行WooCommerce时，PHP 7.4远远超过了PHP 7.3。

WordPress 5.3 +简易数字下载2.9.20

由Pippin Williamson创建的Easy Digital Downloads（EDD）是一个免费的WordPress电子商务插件，主要致力于帮助创作者和开发者销售数字产品。

在了解了WooCommerce的表现之后，我们随后将WordPress和Easy Digital Downloads一起安装了。我们利用了免费的主题主题（1.0.7）。

经测试的网址：/ downloads / side-hustle /
注意：该页面是EDD的单一产品，包含图像，几段文字行，购买按钮和类别链接。
Docker镜像源自https://hub.docker.com/_/wordpress/。

WordPress 5.3 + Easy Digital下载PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

WordPress 5.3 + EDD 2.9.20 PHP 5.6基准测试结果：136.73 req / sec
WordPress 5.3 + EDD 2.9.20 PHP 7.0基准测试结果：323.84 req / sec
WordPress 5.3 + EDD 2.9.20 PHP 7.1基准测试结果：326.32 req / sec
WordPress 5.3 + EDD 2.9.20 PHP 7.2基准测试结果：346.51 req / sec
WordPress 5.3 + EDD 2.9.20 PHP 7.3基准测试结果：390.85 req / sec
WordPress 5.3 + EDD 2.9.20 PHP 7.4基准测试结果：400.78 req / sec

PHP 7.4也是使用WordPress和Easy Digital Downloads最快的。

当涉及WordPress，WooCommerce和Easy Digital Downloads时，事实证明，PHP 7.4的整体速度略快！

Drupal 8.8.0

Drupal是一个开源CMS，因其模块化系统和强大的开发人员社区而广受欢迎。它最初于2000年推出，根据W3Techs的说法，该网站为内容管理系统市场中3.0％的份额提供了1.7％的支持。

对于Drupal基准，我们使用了免费的Umami默认主题（8.8.0）。

经过测试的网址：/ zh-CN / articles / dairy-free-and-delicious-milk-chocolate
注意：Drupal安装有内置的虚拟数据“ Umami Food Magazine（实验性）”。
Drupal 8.8不再支持PHP 5.6，并且不兼容PHP 7.4（https://www.drupal.org/project/drupal/issues/3086374）。
Docker镜像源自https://hub.docker.com/_/drupal/。

Drupal PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

Drupal 8.8.0 PHP 5.6基准测试结果：不支持
Drupal 8.8.0 PHP 7.0基准测试结果：18.47请求/秒
Drupal 8.8.0 PHP 7.1基准测试结果：18.81req / sec
Drupal 8.8.0 PHP 7.2基准测试结果：19.38请求/秒
Drupal 8.8.0 PHP 7.3基准测试结果：21.56 req / sec?
Drupal 8.8.0 PHP 7.4基准测试结果：不支持

当运行Drupal时，PHP 7.3在性能上有了很大的提高。与以前的PHP版本相比，这是一个更大的飞跃。

Joomla！ 3.9.13

Joomla！是用于发布Web内容的免费开源CMS，最初于2005年8月17日发布。它基于模型-视图-控制器Web应用程序框架构建，根据W3Techs的统计，互联网上所有网站的使用率为2.6％。

对于Joomla！基准，我们利用了Joomla！中包含的免费Protostar（1.0）模板！ 3.x发行包。

经过测试的网址：/（首页）
注意：Joomla！随“默认英语（GB）示例数据”一起安装。它在主页上提供了基本的虚拟内容。主页在侧栏上包含几段内容，一个搜索输入表单以及一些基本小部件。
Docker镜像源自https://hub.docker.com/_/joomla/。

Joomla！ PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

Joomla！ 3.9.13 PHP 5.6基准测试结果：48.40 req / sec
Joomla！ 3.9.13 PHP 7.0基准测试结果：67.80 req / sec
Joomla！ 3.9.13 PHP 7.1基准测试结果：67.37 req / sec
Joomla！ 3.9.13 PHP 7.2基准测试结果：68.53 req / sec
Joomla！ 3.9.13 PHP 7.3基准测试结果：71.63 req / sec
Joomla！ 3.9.13 PHP 7.4基准测试结果：76.31 req / sec?

在Joomla上！我们可以看到整体表现有些差。从PHP 5.6到7.0+的性能有了巨大的提高。并快速前进到PHP 7.4，无疑是Joomla的赢家！

Magento 2（CE）2.2.10 + 2.3.3

Magento是使用PHP编写的流行的开源电子商务平台，于2008年3月31日发布。截至2018年，Magento现在是Adobe公司。据W3Techs称，它为互联网上所有网站的0.8％提供支持。

对于Magento 2基准，我们使用了免费的Luma主题。由于2.2.10仅支持PHP 7.2，所以我们使用了两个版本。对于其他测试，我们使用2.3.3。

经测试的URL：/lifelong-fitness-iv.html
注意：禁用了生成静态HTML页面的页面缓存。经测试的URL是单个产品。它包含一个图像产品，一个导航栏，面包屑导航，并且没有评论。
Magento 2不再支持PHP 5.6，并且与PHP 7.4不兼容。
http://pubfiles.nexcess.net/magento/ce-packages/

Magento 2 PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

Magento 2（CE）2.2.10 PHP 5.7基准测试结果：不支持
Magento 2（CE）2.2.10 PHP 7.0基准测试结果：28.33 req / sec
Magento 2（CE）2.2.10 PHP 7.1基准测试结果：28.51 req / sec
Magento 2（CE）2.2.10 PHP 7.2基准测试结果：29.58 req / sec
Magento 2（CE）2.2.10 PHP 7.3基准测试结果：不支持
Magento 2（CE）2.2.10 PHP 7.4基准测试结果：不支持
Magento 2（CE）2.3.0 PHP 5.6基准测试结果：不支持
Magento 2（CE）2.3.0 PHP 7.0基准测试结果：不支持
Magento 2（CE）2.3.0 PHP 7.1基准测试结果：25.33 req / sec
Magento 2（CE）2.3.0 PHP 7.2基准测试结果：27.01 req / sec
Magento 2（CE）2.3.0 PHP 7.3基准测试结果：29.97 req / sec?
Magento 2（CE）2.3.0 PHP 7.4基准测试结果：不支持

Magento 2 PHP基准测试的差异不大。但是好消息是，Magento的最新版本以及受支持的最新PHP版本（7.3）是最快的。

Grav CMS 1.6.19

Grav是易于使用但功能强大的开源CMS，不需要数据库。有时也称为平面文件CMS。

对于Grav CMS基准，我们使用了免费的Clean Blog框架包。

经测试的URL：/ home / the-urban-jungle
Grav CMS不再支持PHP 5.6和7.0。
注意：内容是一个简单的单栏博客文章，没有侧边栏。 Core GravCMS缓存已禁用。

Grav CMS PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

Grav CMS 1.6.19 PHP 5.6基准测试结果：不支持
Grav CMS 1.6.19 PHP 7.0基准测试结果：不支持
Grav CMS 1.6.19 PHP 7.1基准测试结果：62.25 req / sec
Grav CMS 1.6.19 PHP 7.2基准测试结果：64.69 req / sec
Grav CMS 1.6.19 PHP 7.3基准测试结果：69.07 req / sec
Grav CMS 1.6.19 PHP 7.4基准测试结果：75.04 req / sec

通过Grav CMS，我们可以看到最新版本的PHP 7.4是冠军。

也很高兴看到这些较小的内容管理系统不再支持旧版本的PHP。尽管这是不那么大的一个优点。不幸的是，当涉及到具有很大市场份额的WordPress和其他平台时，由于兼容性问题，事情进展缓慢。

十月CMS 1.0.458

October CMS是基于Laravel PHP框架的免费，开源，自托管和模块化CMS平台。它最初于2014年5月15日发布。

对于十月CMS基准，我们使用了免费的Clean Blog主题。

经测试的URL：/ blog / post / first-blog-post
October CMS不再支持PHP 5.6，并且不兼容PHP 7.4（https://github.com/octobercms/october/issues/4381）。

十月CMS PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

十月CMS 1.0.458 PHP 5.6基准测试结果：不支持
10月CMS 1.0.458 PHP 7.0基准测试结果：44.83 req / sec
10月CMS 1.0.458 PHP 7.1基准测试结果：45.21 req / sec
10月CMS 1.0.458 PHP 7.2基准测试结果：46.71 req / sec
十月CMS 1.0.458 PHP 7.3基准测试结果：49.26 req / sec?
十月CMS 1.0.458 PHP 7.4基准测试结果：不支持

PHP 7.3是赢家，即使只是一点点。 PHP 7.4一旦受支持，也很有可能会进行改进。

Laravel 5.8.35 + 6.7.0

Laravel是一个非常流行的开源PHP框架，用于开发Web应用程序。它是由泰勒·奥特威尔（Taylor Otwell）创建的，于2011年6月发布。

对于Laravel基准测试，我们使用了普通的HTML主题。

经过测试的网址：/（首页）
该帖子包含标题，作者姓名和主要内容。该数据库包含1个表“ posts”。该表包含6列“ post_title”，“ post_content”，“ post_author”，“ created_at”和“ updated_at”。
经测试的URL连接到数据库，并在表上显示所有帖子。此外，Laravel应用程序包含1条路线和1个控制器来显示这些内容。
Laravel 5.8.35不再支持PHP 5.6或PHP 7.0。 Laravel 6.7.0不再支持PHP 5.6、7.0或7.1。

Laravel PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

Laravel 5.8.35 PHP 5.6基准测试结果：不支持
Laravel 5.8.35 PHP 7.0基准测试结果：不支持
Laravel 5.8.35 PHP 7.1基准测试结果：380.52 req / sec
Laravel 5.8.35 PHP 7.2基准测试结果：382.80 req / sec
Laravel 5.8.35 PHP 7.3基准测试结果：400.22 req / sec
Laravel 5.8.35 PHP 7.4基准测试结果：402.39 req / sec?
Laravel 6.7.0 PHP 5.6基准测试结果：不支持
Laravel 6.7.0 PHP 7.0基准测试结果：不支持
Laravel 6.7.0 PHP 7.1基准测试结果：不支持
Laravel 6.7.0 PHP 7.2基准测试结果：383.21 req / sec
Laravel 6.7.0 PHP 7.3基准测试结果：392.74 req / sec
Laravel 6.7.0 PHP 7.4基准测试结果：394.96 req / sec

在这两个版本上，PHP 7.4都是明显的赢家。但是，有趣的是，带有PHP 7.4的Laravel 5.8.35似乎比Laravel 6.7.0快。

Symfony 4.4.2 + 5.0.1

Symfony是一组可重用的PHP组件和一个PHP框架，用于构建Web应用程序，API，微服务和Web服务。它于2005年10月22日发布。

对于Symfony基准，我们将Symfony演示版与MySQL配合使用（默认为SQLite）。

经过测试的网址：/ en / blog / posts / hello-world
帖子包含标题，日期，作者姓名，2个标签和5条评论。
Symfony 4.4.2不再支持PHP 5.6或PHP 7.0。 Symfony 5.0.1不再支持PHP 5.6、7.0或7.1。

Symfony PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

Symfony 4.4.2 PHP 5.6基准测试结果：不支持
Symfony 4.4.2 PHP 7.0基准测试结果：不支持
Symfony 4.4.2 PHP 7.1基准测试结果：295.84 req / sec
Symfony 4.4.2 PHP 7.2基准测试结果：309.26 req / sec
Symfony 4.4.2 PHP 7.3基准测试结果：327.61 req / sec
Symfony 4.4.2 PHP 7.4基准测试结果：338.18 req / sec?
Symfony 5.0.1 PHP 5.6基准测试结果：不支持
Symfony 5.0.1 PHP 7.0基准测试结果：不支持
Symfony 5.0.1 PHP 7.1基准测试结果：不支持
Symfony 5.0.1 PHP 7.2基准测试结果：229.09 req / sec
Symfony 5.0.1 PHP 7.3基准测试结果：239.96 req / sec
Symfony 5.0.1 PHP 7.4基准测试结果：252.22 req / sec

我们可以看到Symfony版本4.4.2和PHP 7.4是最快的。

CodeIgniter 3.1.11 + 4.0-rc.3

CodeIgniter是一个功能强大的PHP框架，占地面积很小，是为需要简单优雅的工具箱来创建功能齐全的Web应用程序的开发人员而构建的。

经过测试的网址：/（首页）
注意：帖子包含标题，作者姓名和主要内容。该数据库包含1个表“ posts”。该表包含6列“ post_title”，“ post_content”，“ post_author”，“ created_at”和“ updated_at”。
经测试的URL连接到数据库，并在表上显示所有帖子。此外，CodeIgniter应用程序包含1个路由和1个控制器来显示这些内容。
CodeIgniter 4.0-rc.3不支持PHP 5.6、7.0或7.1。

CodeIgniter PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

CodeIgniter 3.1.11 PHP 5.6基准测试结果：292.81 req / sec
CodeIgniter 3.1.11 PHP 7.0基准测试结果：358.40 req / sec
CodeIgniter 3.1.11 PHP 7.1基准测试结果：369.93 req / sec
CodeIgniter 3.1.11 PHP 7.2基准测试结果：383.24 req / sec
CodeIgniter 3.1.11 PHP 7.3基准测试结果：392.28 req / sec
CodeIgniter 3.1.11 PHP 7.4基准测试结果：394.96 req / sec?
CodeIgniter 4.0-rc.3 PHP 5.6基准测试结果：不支持
CodeIgniter 4.0-rc.3 PHP 7.0基准测试结果：不支持
CodeIgniter 4.0-rc.3 PHP 7.1基准测试结果：不支持
CodeIgniter 4.0-rc.3 PHP 7.2基准测试结果：319.68 req / sec
CodeIgniter 4.0-rc.3 PHP 7.3基准测试结果：322.90 req / sec
CodeIgniter 4.0-rc.3 PHP 7.4基准测试结果：333.08 req / sec

与Laravel和Symfony一样，运行CodeIgniter时PHP 7.4是最快的。有趣的是CodeIgniter 3.1.11的速度明显快于4.0-rc.3。但是，请记住，它是一个候选发布版本。

CakePHP 3.8.7 + 4.0.0

CakePHP是一个开放源代码的Web快速开发框架，它使构建Web应用程序更简单，更快并且需要更少的代码。它于2005年4月发布。

经过测试的网址：/（首页）
注意：帖子包含标题，作者姓名和主要内容。该数据库包含1个表“ posts”。该表包含6列“ post_title”，“ post_content”，“ post_author”，“ created_at”和“ updated_at”。
经测试的URL连接到数据库，并在表上显示所有帖子。此外，CodeIgniter应用程序包含1个路由和1个控制器来显示这些内容。
CakePHP 4.0.0不支持PHP 5.6、7.0或7.1。

CakePHP基准

嵌入您的网站：

图src：金斯塔

基准结果

CakePHP 3.8.7 PHP 5.6基准测试结果：134.09 req / sec
CakePHP 3.8.7 PHP 7.0基准测试结果：254.58 req / sec
CakePHP 3.8.7 PHP 7.1基准测试结果：267.29 req / sec
CakePHP 3.8.7 PHP 7.2基准测试结果：270.94 req / sec
CakePHP 3.8.7 PHP 7.3基准测试结果：290.25 req / sec
CakePHP 3.8.7 PHP 7.4基准测试结果：294.06 req / sec?
CakePHP 4.0.0 PHP 5.6基准测试结果：不支持
CakePHP 4.0.0 PHP 7.0基准测试结果：不支持
CakePHP 4.0.0 PHP 7.1基准测试结果：不支持
CakePHP 4.0.0 PHP 7.2基准测试结果：245.49 req / sec
CakePHP 4.0.0 PHP 7.3基准测试结果：260.84 req / sec
CakePHP 4.0.0 PHP 7.4基准测试结果：259.58 req / sec

对于CakePHP，运行PHP 7.4的3.8.7版本是赢家。

PyroCMS 3.7

PyroCMS是一个开源软件，从本质上讲是Laravel的扩展，它使您可以更快地在框架上构建网站和应用程序。

对于PyroCMS基准测试，我们使用了免费的入门主题。

经过测试的网址：/ posts / welcome-to-pyrocms
PyroCMS 3.7不支持PHP 5.6或7.0。
注意：在PHP 7.4上运行时，我们遇到了错误。很可能是因为尚不支持。因此，我们无法将其纳入基准测试。

PyroCMS PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

PyroCMS 3.5.3 PHP 5.6基准测试结果：不支持
PyroCMS 3.5.3 PHP 7.0基准测试结果：不支持
PyroCMS 3.5.3 PHP 7.1基准测试结果：91.45 req / sec
PyroCMS 3.5.3 PHP 7.2基准测试结果：94.77 req / sec
PyroCMS 3.5.3 PHP 7.3基准测试结果：103.35 req / sec
PyroCMS 3.5.3 PHP 7.4基准测试结果：不支持

由于PyroCMS尚未使用PHP 7.4，因此PHP 7.3在这里赢得了少量测试。

Pagekit 1.0.17

Pagekit是由YOOtheme创建的开源模块化，轻量级CMS。它为您提供了创建漂亮网站的工具。它于2016年春季发布。

pagekit“ width =” 310“ height =” 79“ srcset =” https://kinsta.com/wp-content/uploads/2018/02/pagekit.png 750w，https://kinsta.com/wp-content/ uploads / 2018/02 / pagekit-300x76.png 300w，https：//kinsta.com/wp-content/uploads/2018/02/pagekit-610x155.png 610w“ data-lazy-sizes =”（最大宽度： 310px）100vw，310px“ src =” https://kinsta.com/wp-content/uploads/2018/02/pagekit.png“></p>
<p>对于Pagekit基准测试，我们使用了免费的One主题（默认Pagekit主题）。</p>
<ul>
<li>经过测试的网址：/ blog / 1
</li>
</ul>
<p><img decoding=

Pagekit PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

Pagekit 1.0.17 PHP 5.6基准测试结果：249.48 req / sec
Pagekit 1.0.17 PHP 7.0基准测试结果：401.77 req / sec
Pagekit 1.0.17 PHP 7.1基准测试结果：406.99 req / sec
Pagekit 1.0.17 PHP 7.2基准测试结果：419.56 req / sec
Pagekit 1.0.17 PHP 7.3基准测试结果：431.21 req / sec
Pagekit 1.0.17 PHP 7.4基准测试结果：438.39 req / sec

使用Pagekit进行测试时，PHP 7.4赢得了金牌。

螺栓CMS 3.7.0

Bolt CMS，即Bolt，是一种开源内容管理工具，力求尽可能简单明了。它基于Silex和Symfony组件，使用Twig和SQLite，MySQL或PostgreSQL。

对于Bolt CMS基准测试，我们使用了免费的Bolt Base 2018主题。

经过测试的网址：/ entry / hello-world
注意：使用内置虚拟内容生成器生成的内容。

Bolt CMS PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

Bolt CMS 3.7.0 PHP 5.6基准测试结果：50.91 req / sec
Bolt CMS 3.7.0 PHP 7.0基准测试结果：132.49 req / sec
Bolt CMS 3.7.0 PHP 7.1基准测试结果：134.55 req / sec
Bolt CMS 3.7.0 PHP 7.2基准测试结果：139.02 req / sec
Bolt CMS 3.7.0 PHP 7.3基准测试结果：147.03 req / sec
Bolt CMS 3.7.0 PHP 7.4基准测试结果：162.77 req / sec

当使用Bolt CMS进行测试时，PHP 7.4赢得了金牌。看到自PHP 5.6以来的性能改进也令人惊奇。

Craft CMS 3.4.0-beta.4

Craft CMS是面向开发人员，设计师和Web专业人员的重点内容管理系统，融合了灵活性，强大功能和客户易用性。

经过测试的网址：/ news / barrel-aged-digital-natives
Craft CMS不支持PHP 5.6。
使用https://github.com/craftcms/demo测试了演示应用

Craft CMS PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

Craft CMS 3.4.0-beta.4 PHP 5.6基准测试结果：不支持
Craft CMS 3.4.0-beta.4 PHP 7.0基准测试结果：140.81 req / sec
Craft CMS 3.4.0-beta.4 PHP 7.1基准测试结果：145.75 req / sec
Craft CMS 3.4.0-beta.4 PHP 7.2基准测试结果：151.15 req / sec
Craft CMS 3.4.0-beta.4 PHP 7.3基准测试结果：163.95 req / sec
Craft CMS 3.4.0-beta.4 PHP 7.4基准测试结果：169.11 req / sec

PHP 7.4在使用Craft CMS进行测试时获得了金牌。

ExpressionEngine 5.3.0

ExpressionEngine是一个灵活的，功能丰富的内容管理平台，它使世界各地成千上万的个人和组织可以轻松地管理其网站。

对于ExpressionEngine基准，我们使用了默认主题。

经测试的URL：/ blog / entry / super-old-entry
ExpressionEngine不支持PHP 5.6。
注意：页面包含带有3个小部件（搜索，类别列表和RSS feed链接）的侧栏。页面还包含面包屑导航。

ExpressionEngine PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

ExpressionEngine 5.3.0 PHP 5.6基准测试结果：不支持
ExpressionEngine 5.3.0 PHP 7.0基准测试结果：101.32 req / sec
ExpressionEngine 5.3.0 PHP 7.1基准测试结果：103.54 req / sec
ExpressionEngine 5.3.0 PHP 7.2基准测试结果：107.79 req / sec
ExpressionEngine 5.3.0 PHP 7.3基准测试结果：108.35 req / sec
ExpressionEngine 5.3.0 PHP 7.4基准测试结果：110.56 req / sec

用ExpressionEngine进行测试时，PHP 7.4赢得了金牌。

在Kinsta更新到PHP 7.4

如果上述结果无法说服您，我们不确定会怎样！只是一个善意的提醒。如果您是Kinsta客户端，则可以使用PHP 7.2、7.3和7.4。如果您希望获得性能方面的改进，则只需在MyKinsta仪表板中单击即可轻松更改为较新版本。

更改为PHP 7.4

如果您担心它与第三方插件不兼容（可能会发生），这正是我们拥有临时站点的原因。 ?您可以进行测试，而不必担心破坏生产现场。

从基准结果中总结

从上面的测试中可以清楚地看到，在所有平台的性能方面，PHP 7.4处于领先地位。

我们在6个不同的PHP版本上测试了22个平台/配置的性能，而#PHP 7.4在17/17（5 N / A）上大获全胜！ ?

点击鸣叫

在上面测试的22种配置中，PHP 7.4是17种中最快的引擎。一个原因并非不是赢家，仅仅是因为Drupal，Magento 2，十月CMS，PyroCMS尚未完全支持PHP 7.4或存在兼容性问题。
就WordPress而言，PHP 7.4是所有测试中最快的（WordPress站点有5.3，WooCommerce和Easy Digital Downloads）。
在许多基准测试结果中，您可以轻松地发现发布的每个新版本的PHP都可以提高性能。这就是为什么测试您的网站，插件等并坚持定期的升级计划如此重要的原因。您的访客和客户将感谢您，因为他们期望速度！
如果您的托管服务提供商不提供更新版本的PHP，那么也许您该考虑迁移了。
对于WordPress用户，除了升级到最新的PHP版本外，我们还收集了许多其他技术，可以帮助您进一步改善网站性能。请参阅我们的最终指南中有关如何加快WordPress网站速度的详细信息。

我们对PHP 7.4感到非常兴奋，希望您也是如此！我们很想听听您对基准测试的想法，甚至是您升级后的经验。将它们放在评论中。

1.5K分享

901
347
1个
93
0
1个
0
158

原文： https://wpjian.com/tips/2020010729805.html

php 7.2 安装 mcrypt 扩展

Mcrypt 简介

Mcrypt 库提供了对多种块算法的支持，包括：DES，TripleDES，Blowfish （默认）， 3-WAY，SAFER-SK64，SAFER-SK128，TWOFISH，TEA，RC2 以及 GOST，并且支持 CBC，OFB，CFB 和 ECB 密码模式

环境：centos 7

yum 安装依赖包：

yum install libmcrypt libmcrypt-devel mcrypt mhash

在 php 官网下载 mcrypt 包，php 扩展官网

# wget http://pecl.php.net/get/mcrypt-1.0.1.tgz

# tar xf mcrypt-1.0.1.tgz

# cd mcrypt-1.0.1

编译安装 mcrypt

# /usr/local/php/bin/phpize

# ./configure –with-php-config=/usr/local/php/bin/php-config && make && make install

在php.ini加上扩展即可

extension=mcrypt.so

重启 php-fpm

/etc/init.d/php-fpm restart

记一次 Laravel 应用性能调优经历

这是一份事后的总结。在经历了调优过程踩的很多坑之后，我们最终完善并实施了初步的性能测试方案，通过真实的测试数据归纳出了 Laravel 开发过程中的一些实践技巧。

0x00 源起

最近有同事反馈 Laravel 写的应用程序响应有点慢、20几个并发把 CPU 跑满… 为了解决慢的问题，甚至一部分接口用 nodejs 来写。

而我的第一反应是一个流行的框架怎么可能会有这么不堪？一定是使用上哪里出现了问题。为了一探究竟，于是开启了这次 Laravel 应用性能调优之旅。

0x01 调优技巧

这次性能测试方案中用到的优化技巧主要基于 Laravel 框架本身及其提供的工具。

关闭应用debug app.debug=false
缓存配置信息 php artisan config:cache
缓存路由信息 php artisan router:cache
类映射加载优化 php artisan optimize
自动加载优化 composer dumpautoload
根据需要只加载必要的中间件
使用即时编译器（JIT），如：HHVM、OPcache
使用 PHP 7.x

除了以上优化技巧之外，还有很多编码上的实践可以提升 Laravel 应用性能，在本文中暂时不会做说明。（也可以关注我的后续文章）

1. 关闭应用 debug

打开应用根目录下的 .env 文件，把 debug 设置为 false。

APP_DEBUG=false

2. 缓存配置信息

php artisan config:cache

运行以上命令可以把 config 文件夹里所有配置信息合并到一个 bootstrap/cache/config.php 文件中，减少运行时载入文件的数量。

php artisan config:clear

运行以上命令可以清除配置信息的缓存，也就是删除 bootstrap/cache/config.php 文件

3. 缓存路由信息

php artisan route:cache

运行以上命令会生成文件 bootstrap/cache/routes.php。路由缓存可以有效的提高路由器的注册效率，在大型应用程序中效果越加明显。

php artisan route:clear

运行以上命令会清除路由缓存，也就是删除 bootstrap/cache/routes.php 文件。

4. 类映射加载优化

php artisan optimize --force

运行以上命令能够把常用加载的类合并到一个文件中，通过减少文件的加载来提高运行效率。这个命令会生成 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json 两个文件。

通过修改 config/compile.php 文件可以添加要合并的类。

在生产环境中不需要指定 --force 参数文件也可以自动生成。

php artisan clear-compiled

运行以上命令会清除类映射加载优化，也就是删除 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json 两个文件。

5. 自动加载优化

composer dumpautoload -o

Laravel 应用程序是使用 composer 来构建的。这个命令会把 PSR-0 和 PSR-4 转换为一个类映射表来提高类的加载速度。

注意：php artisan optimize --force 命令里已经做了这个操作。

6. 根据需要只加载必要的中间件

Laravel 应用程序内置了并开启了很多的中间件。每一个 Laravel 的请求都会加载相关的中间件、产生各种数据。在 app/Http/Kernel.php 中注释掉不需要的中间件（如 session 支持）可以极大的提升性能。

7. 使用即时编译器

HHVM 和 OPcache 都能轻轻松松的让你的应用程序在不用做任何修改的情况下，直接提高 50% 或者更高的性能。

8. 使用 PHP 7.x

只能说 PHP 7.x 比起之前的版本在性能上有了极大的提升。

嗯，限于你的真实企业环境，这个也许很长时间内改变不了，算我没说。

0x02 测试方案

我们使用简单的 Apache ab 命令仅对应用入口文件进行测试，并记录和分析数据。

仅对应用的入口文件 index.php 进行测试，访问 “/” 或者 “/index.php” 返回框架的欢迎页面。更全面的性能测试需要针对应用的更多接口进行测试。
使用 Apache ab 命令。ab -t 10 -c 10 {url}。该命令表示对 url 同时发起 10 个请求，并持续 10 秒钟。命令中具体的参数设置需要根据要测试的服务器性能进行选择。
为了避免机器波动导致的数据错误，每种测试条件会执行多次 ab 命令，并记录命令执行结果，重点关注每秒处理的请求数及请求响应时间，分析并剔除异常值。
每次对测试条件进行了调整，需要在浏览器上对欢迎页进行访问，确保没有因为测试条件修改而访问出错。如果页面访问出错会导致测试结果错误。

服务器环境说明

所有脱离具体环境的测试数据都没有意义，并且只有在相近的条件下才可以进行比较。

这套环境运行在 Mac 上，内存 8G，处理器 2.8GHz，SSD 硬盘。
测试服务器是使用 Homestead 搭建的。虚拟机配置为单核 CPU、2G 内存。
服务器 PHP 版本为 7.1，未特殊说明，则标识开启了 OPcache。
测试的 Laravel 应用程序采用 5.2 版本编写。app\Http\routes.php 中定义了 85 个路由。
测试过程中除了虚拟机、终端及固定的浏览器窗口外，没有会影响机器的程序运行。

以上的数据，大家在自己进行测试时可以参考。

0x03 测试过程及数据

1. 未做任何优化

1.1 操作

按照以下检查项执行相应的操作。
运行 ab -t 10 -c 10 http://myurl.com/index.php

基础检查项

.env 文件中 APP_DEBUG=true
不存在 bootstrap/cache/config.php
不存在 bootstrap/cache/routes.php
不存在 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json
app/Http/Kernel.php 中开启了大部分的中间件
浏览器访问 Laravel 应用程序欢迎页确保正常访问

1.2 数据记录

2. 关闭应用debug

2.1 操作

在步骤 1 基础上修改 .env 文件中 APP_DEBUG=false。
浏览器访问 Laravel 应用程序欢迎页确保正常访问。
运行 ab -t 10 -c 10 http://myurl.com/index.php。

2.2 数据记录

2.3 对比结果

与步骤 1 结果比较发现：关闭应用 debug 之后，每秒处理请求数从 26-34 上升到 33-35，请求响应时间从大部分 300ms 以上下降到 290ms 左右，效果不太明显，但确实有一定的提升。

注意：这部分与应用中的日志等使用情况有比较大的关联。

3. 开启缓存配置信息

3.1 操作

在步骤 2 基础上，运行 php artisan config:cache，确认生成 bootstrap/cache/config.php。
浏览器访问 Laravel 应用程序欢迎页确保正常访问。
运行 ab -t 10 -c 10 http://myurl.com/index.php。

3.2 数据记录

3.3 对比结果

与步骤 2 结果比较发现：开启配置信息缓存之后，每秒处理请求数从 33-35 上升到 36-38，请求响应时间从 290ms 左右下降到 260ms 左右，效果不太明显，但确实有一定的提升。

4. 开启缓存路由信息

4.1 操作

在步骤 3 基础上，运行 php artisan route:cache，确认生成 bootstrap/cache/routes.php。
浏览器访问 Laravel 应用程序欢迎页确保正常访问。
运行 ab -t 10 -c 10 http://myurl.com/index.php。

4.2 数据记录

4.3 对比结果

与步骤 3 结果比较发现：开启路由信息缓存之后，每秒处理请求数从 36-38 上升到 60 左右，请求响应时间从 260ms 下降到 160ms 左右，效果显著，从 TPS 看，提升了 70%。

5. 删除不必要的中间件

5.1 操作

在步骤 4 基础上，注释掉不必要的中间件代码。
浏览器访问 Laravel 应用程序欢迎页确保正常访问。
运行 ab -t 10 -c 10 http://myurl.com/index.php。

注意：这次测试中我注释掉了所有的中间件。实际情况中应该尽量只留下必要的中间件。

5.2 数据记录

5.3 对比结果

与步骤 4 结果比较发现：删除了不必要的中间件之后，每秒处理请求数从 60 左右上升到 90 左右，请求响应时间从 160ms 下降到 110ms 左右，效果非常明显，从 TPS 看，提升了 50%。

6. 开启类映射加载优化

6.1 操作

在步骤 5 基础上，运行 php artisan optimize --force，确认生成 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json。
浏览器访问 Laravel 应用程序欢迎页确保正常访问。
运行 ab -t 10 -c 10 http://myurl.com/index.php。

6.2 数据记录

6.3 对比结果

与步骤 5 结果比较发现：做了类映射加载优化之后，每秒处理请求数从 90 上升到 110，请求响应时间从 110ms 下降到 100ms 以下，效果还是比较明显的。

7. 关闭 OPcache

7.1 操作

在步骤 6 基础上，关闭 PHP 的 OPcache，并重启服务器。通过 phpinfo() 的 Zend OPcache 确认 OPcache 已经关闭。
浏览器访问 Laravel 应用程序欢迎页确保正常访问。
运行 ab -t 10 -c 10 http://myurl.com/index.php。

7.2 数据记录

7.3 对比结果

与步骤 6 结果比较发现：关闭 OPcache 之后，每秒处理请求数从 110 下降到 15，请求响应时间从 100ms 以下上升到 650ms 以上。开启与关闭 OPcache，数据上竟有几倍的差别。

此后，我重新开启了 PHP 的 OPcache，数据恢复到步骤 6 水平。

0x04 踩过的坑

1. [LogicException] Unable to prepare route [/] for serialization. Uses Closure.

在运行 php artisan route:cache 命令时报这个错误。

原因：路由文件中处理“/”时使用了闭包的方式。要运行该命令，路由的具体实现不能使用闭包方式。

修改方案：将路由的具体实现放到控制器中来实现。

2. [Exception] Serialization of ‘Closure’ is not allowed.

在运行 php artisan route:cache 命令时报这个错误。

原因：路由文件中定义了重复的路由。

修改方案：排查路由文件中的重复路由并修改。尤其要注意 resource 方法很可能导致与其方法重复。

3. [RuntimeException] Invalid filename provided.

在运行 php artisan optimize --force 命名时报这个错误。

原因：在加载需要编译的类时没有找到相应的文件。5.2 版本的 vendor/laravel/framework/src/Illuminate/Foundation/Console/Optimize/config.php 中定义了要编译的文件路径，但不知道为什么 /vendor/laravel/framework/src/Illuminate/Database/Eloquent/ActiveRecords.php 没有找到，所以报了这个错误。

修改方案：暂时注释掉了以上 config.php 中的 ../ActiveRecords.php 一行。

4. InvalidArgumentException in FileViewFinder.php line 137: View [welcome] not found.

在运行 php artisan config:cache 之后，浏览器上访问 Laravel 应用程序欢迎页报这个错误。

原因：Laravel 应用程序服务器是通过 Homestead 在虚拟机上搭建的。而这个命令我是在虚拟机之外运行的，导致生成的 config.php 中的路径是本机路径，而不是虚拟机上的路径。所以无法找到视图文件。

修改方案：ssh 到虚拟机内部运行该命令。

0x05 实践技巧

坑也踩了，测试也做过了。这里针对这次经历做个实践技巧的简单总结。

1. 有效的 Laravel 应用程序优化技巧

关闭应用debug app.debug=false
缓存配置信息 php artisan config:cache
缓存路由信息 php artisan router:cache
类映射加载优化 php artisan optimize（包含自动加载优化 composer dumpautoload）
根据需要只加载必要的中间件
使用即时编译器（JIT），如：HHVM、OPcache

2. 编写代码时注意事项

路由的具体实现放到控制器中。
不定义重复的路由，尤其注意 resouce 方法。
弄清各中间件的作用，删除不必要的中间件引用。

0x06 下一步

以上的调优技巧及编码注意事项主要针对框架本身，在真正的业务逻辑编码中有很多具体的优化技巧，在此没有讨论。

后续的优化重点将会放在具体编码实践上：

使用 Memcached 来存储会话 config/session.php
使用专业的缓存驱动器
数据库请求优化
为数据集书写缓存逻辑
前端资源合并 Elixir

0x07 写在最后

网上看到很多框架性能对比的文章与争论，也看到很多简单贴出了数据。这些都不足以窥探真实的情况，所以有了我们这次的实践，并在过程中做了详实的记录。在各位读者实践过程中提供参考、比较、反思之用。对于这次实践有疑问的读者，也欢迎提出问题和意见。

不多说了，要学习更多技术干货，请关注微信公众号：up2048。

– EOF –

原文有图参考： https://segmentfault.com/a/1190000011569012

PHP7开启Opcode性能对比

Opcache 的前生是 Optimizer+ ，它是PHP的官方公司 Zend 开发的一款闭源但可以免费使用的 PHP 优化加速组件。 Optimizer+ 将PHP代码预编译生成的脚本文件 Opcode 缓存在共享内存中供以后反复使用，从而避免了从磁盘读取代码再次编译的时间消耗。同时，它还应用了一些代码优化模式，使得代码执行更快。从而加速PHP的执行。

PHP的正常执行流程如下

request请求（nginx,apache,cli等）–>Zend引擎读取.php文件–>扫描其词典和表达式 –>解析文件–>创建要执行的计算机代码(称为Opcode)–>最后执行Opcode–> response 返回

每一次请求PHP脚本都会执行一遍以上步骤，如果PHP源代码没有变化，那么Opcode也不会变化，显然没有必要每次都重新生成Opcode，结合在Web中无所不在的缓存机制，我们可以把Opcode缓存下来，以后直接访问缓存的Opcode岂不是更快，启用Opcode缓存之后的流程图如下所示：

Opcode cache 的目地是避免重复编译，减少 CPU 和内存开销。

下面介绍Opcache的安装

安装：

1、找到opcache的扩展，我的是php7.1
yum list php71*
2、安装扩展
yum install php71w-opcache.x86_64

配置：

zend_extension=opcache.so
[opcache]
;开启opcache
opcache.enable=1  

;CLI环境下，PHP启用OPcache
opcache.enable_cli=1

;OPcache共享内存存储大小,单位MB
opcache.memory_consumption=128  

;PHP使用了一种叫做字符串驻留（string interning）的技术来改善性能。例如，如果你在代码中使用了1000次字符串“foobar”，在PHP内部只会在第一使用这个字符串的时候分配一个不可变的内存区域来存储这个字符串，其他的999次使用都会直接指向这个内存区域。这个选项则会把这个特性提升一个层次——默认情况下这个不可变的内存区域只会存在于单个php-fpm的进程中，如果设置了这个选项，那么它将会在所有的php-fpm进程中共享。在比较大的应用中，这可以非常有效地节约内存，提高应用的性能。
这个选项的值是以兆字节（megabytes）作为单位，如果把它设置为16，则表示16MB，默认是4MB
opcache.interned_strings_buffer=8

;这个选项用于控制内存中最多可以缓存多少个PHP文件。这个选项必须得设置得足够大，大于你的项目中的所有PHP文件的总和。
设置值取值范围最小值是 200，最大值在 PHP 5.5.6 之前是 100000，PHP 5.5.6 及之后是 1000000。也就是说在200到1000000之间。
opcache.max_accelerated_files=4000

;设置缓存的过期时间（单位是秒）,为0的话每次都要检查
opcache.revalidate_freq=60

;从字面上理解就是“允许更快速关闭”。它的作用是在单个请求结束时提供一种更快速的机制来调用代码中的析构器，从而加快PHP的响应速度和PHP进程资源的回收速度，这样应用程序可以更快速地响应下一个请求。把它设置为1就可以使用这个机制了。
opcache.fast_shutdown=1

;如果启用（设置为1），OPcache会在opcache.revalidate_freq设置的秒数去检测文件的时间戳（timestamp）检查脚本是否更新。
如果这个选项被禁用（设置为0），opcache.revalidate_freq会被忽略，PHP文件永远不会被检查。这意味着如果你修改了你的代码，然后你把它更新到服务器上，再在浏览器上请求更新的代码对应的功能，你会看不到更新的效果
强烈建议你在生产环境中设置为0，更新代码后，再平滑重启PHP和web服务器。
opcache.validate_timestamps=0 

;开启Opcache File Cache(实验性), 通过开启这个, 我们可以让Opcache把opcode缓存缓存到外部文件中, 对于一些脚本, 会有很明显的性能提升.
这样PHP就会在/tmp目录下Cache一些Opcode的二进制导出文件, 可以跨PHP生命周期存在.
opcache.file_cache=/tmp

查看phpinfo：

测试结果：

同样的接口从以前的几百毫秒提升到现在的50ms左右

安装Composer PHP Warning: copy(): SSL operation failed with code 1.

报错信息

[root@localhost ~]# php -r "copy('https://install.phpcomposer.com/installer', 'composer-setup.php');" PHP Warning:  copy(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in Command line code on line 1 Warning: copy(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in Command line code on line 1 PHP Warning:  copy(): Failed to enable crypto in Command line code on line 1 Warning: copy(): Failed to enable crypto in Command line code on line 1 PHP Warning:  copy(https://install.phpcomposer.com/installer): failed to open stream: operation failed in Command line code on line 1 Warning: copy(https://install.phpcomposer.com/installer): failed to open stream: operation failed in Command line code on line 1

解决方法

应该是CA证书验证失败造成的错误，下载个CA证书

[root@localhost ~]# wget http://curl.haxx.se/ca/cacert.pem [root@localhost ~]# mv cacert.pem /usr/local/openssl/ssl/certs/cacert.pem [root@localhost ~]# vim /yourpath/php.ini

修改cafile路径，保存

[openssl]
; The location of a Certificate Authority (CA) file on the local filesystem
; to use when verifying the identity of SSL/TLS peers. Most users should
; not specify a value for this directive as PHP will attempt to use the
; OS-managed cert stores in its absence. If specified, this value may still
; be overridden on a per-stream basis via the "cafile" SSL stream context ; option.
;openssl.cafile=
openssl.cafile=/usr/local/openssl/ssl/certs/cacert.pem

使用nginx配置多个php-fastcgi负载均衡

配置还是非常简单的，充分体现了nginx的强大与配置的简单。

应用的最前端是一台nginx服务器，所有静态的内容都由nginx来处理，而将所有php的请求都分摊到下游的若干台

运行PHP fastcgi守护进程的服务器中，这样可以以一种廉价的方案来实现对系统负载的分摊，扩展系统的负载能力。

三台php-fastcgi服务器的ip地址分别为：

172.16.236.110 , 172.16.236.111, 172.16.236.112

运行php-fastcgi进程时，需要让php-cgi监听到服务器的局域网地址（分别如上所示），而不是之前一般都是监听的

本地地址（127.0.0.1）。

以 172.16.236.110这台服务器为例：

/usr/local/php5/bin/php-cgi -b 172.16.236.110:9000

或许你用spawn-fcgi来启动php-fcgi，那么就是这样（供参考，其实也就是修改监听的地址和端口即可）：

/usr/local/lighttpd/bin/spawn-fcgi -f /usr/local/php5/bin/php-cgi -a 172.16.236.110 -p 9000

又或许你是用php-fpm来管理php-fcgi，那么你需要修改php-fpm的配置：

vim  /usr/local/php5/etc/php-fpm.conf

找到这个配置项（其中的地址可能需要根据你自己环境来调整）

<value< span=”” style=”word-wrap: break-word;”> name=”listen_address“>127.0.0.1:9000>

修改为：

<value< span=”” style=”word-wrap: break-word;”> name=”listen_address“>172.16.236.110:9000>

修改完毕后，重启你的php-fpm进程。

然后按照上面的步骤，依次修改其他php fastcgi服务器。

php方面的工作暂时就是这些，下面修改nginx。

vim  /usr/local/nginx/conf/nginx.conf

在配置文件的http段内增加类似如下的配置：

upstream myfastcgi { server 172.16.236.110 weight=1; server 172.16.236.111 weight=1; server 172.16.236.112 weight=1; }

我这里三台php fastcgi服务器的权重是相同的，所以其中的weight值都是1，如果你的php fastcgi服务器需要分主次，那么

可以通过调整其weight值来达到目的。比如以第一台服务器为主，其他两台为辅，则就是这样：

upstream myfastcgi { server 172.16.236.110 weight=1; server 172.16.236.111 weight=2; server 172.16.236.112 weight=2; }

然后找到原来nginx关于php fastcgi配置的部分，比如：

location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }

将其中的fastcgi_pass那一段改为：

fastcgi_pass myfastcgi;

其中的myfastcgi也就是上面刚刚配置的php fastcgi均衡器的名字了。

完了以后，重启nginx即可。

简单吧，就通过这么几个简单的配置，就可以实现一个经济高效的nginx、多php-fcgi的负载均衡解决方案了。

当然了，这样的方案运用到实际项目中还需要进行一些细化的配置，主要是php方面还需要进一步配置

php连接mysql是否应该使用存储过程以及优劣势和使用场景

利弊是相对的，使用存储过程来实现不一定是什么“滔天大罪”，这完全取决于系统的规模，扩展性以及产品的发展方向。
通常情况来说，把业务逻辑写到存储过程中不利于系统分层设计和维护，更不利于数据库的迁移（当然没有谁总想着换个数据库玩儿玩儿），这么做的原因很可能是他认为可以提高性能（存储过程的性能确实优于SQL访问的性能），不过为了解决性能问题有很多种方案，这种方式可能会差一些。

先说一下优劣势，再说一下使用场景吧

1、存储过程的优势

（1）、减少连接数

（2）、调用相对程序方比较简单，由DB管理员加，程序方只是需要传递参数即可

（3）、方便DBA查看

2.使用存储过程的劣势

（1）、程序极大耦合，业务一旦更改，需要都进行更改

（2）、牵扯到复杂计算的情况下，需要数据库进行运算，而数据库的优势是存取，循环等逻辑判断服务的情况是数据库的一个硬伤

（3）、调试困难，无法知道运行sql的情况，尤其是数据库有专门DBA的情况

（4）、主从分离的情况无法使用

（5）、无法适应数据库的切割（水平或垂直切割）。数据库切割之后，存储过程并不清楚数据存储在哪个数据库中。

3、使用场景

存储过程只是适用在php和mysql都是同一个人管理的不太进行业务变更的小网站上。稍微复杂一点的网站并不适合存储过程

php安装IMAP依赖

[root@hexu.org imap]$ yum install -y libc-client-devel

[root@hexu.org imap]$ ln -s /usr/lib64/libc-client.so /usr/lib/libc-client.so

3. 进行安装

[root@hexu.org imap]$ /usr/local/php/bin/phpize

[root@hexu.org imap]$ ./configure –with-php-config=/usr/local/php/bin/php-config –with-imap –with-imap-ssl –with-kerberos

[root@hexu.org imap]$ make && make install

4. 最后调整php.ini

[root@hexu.org imap]$ vi /usr/local/php/lib/php.ini

##vi php.ini add following config

[imap]

extension = imap.so

5. 检查是否安装成功

[root@hexu.org imap]# php -v

PHP 5.3.23 (cli) (built: Apr 7 2013 23:20:21)

Copyright (c) 1997-2013 The PHP Group

Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies

[root@hexu.org imap]# php -m | grep imap

imap ## 看到这里，说明成功安装了

按上面顺序安装应该不会有报错，如果发现错误根据提示找相应的依赖包安装即可，下面举例安装过程遇到的2个error.

1. 没有安装libc-client-devel导致，按上面第一步安装即可, Error info:

checking for utf8_mime2text signature… new

checking for U8T_DECOMPOSE…

configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information.

2. 找不到libc-client.a library, 需要手动添加文件link, Errof info:

checking for crypt in -lcrypt… yes

configure: error: Cannot find imap library (libc-client.a). Please check your c-client installation.

解决方法：

# ln -s /usr/lib64/libc-client.so /usr/lib/libc-client.so

如果出现 Cannot find imap library (libc-client.a).

我们只要执行

# yum install libc-client-devel.x86_64

# ln -s /usr/lib64/libc-client.so /usr/lib/libc-client.so

Nginx负载均衡的优缺点

Nginx的优点是：
1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。
2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会；
3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。
3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。
4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。
5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。
6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。
7、Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比Nginx的就只有lighttpd了，不过lighttpd目前还没有做到Nginx完全的功能，配置也不那么清晰易读，社区资料也远远没Nginx活跃。
8、Nginx也可作为静态网页和图片服务器，这方面的性能也无对手。还有Nginx社区非常活跃，第三方模块也很多。
淘宝的前端使用的Tengine就是基于nginx做的二次开发定制版。
Nginx的缺点是：
1、Nginx仅能支持http、https和Email协议，这样就在适用范围上面小些，这个是它的缺点。
2、对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测。不支持Session的直接保持，但能通过ip_hash来解决。