关于Stone
Stone是一个优化Laravel框架性能的方案， 能大幅提升基于Laravel的程序性能，使Laravel能轻松应对高并发的使用场景。
优化原理
PHP每次请求结束， 都会释放掉执行中所创建的资源。这样有一个很大的好处：PHP程序员基本不用费神去考虑资源释放的问题。诸如内存，IO句柄，数据库连接等，请求结束时PHP将全部释放。PHP程序员几乎不用关心资源释放的问题，也很难写出内存泄露的程序。这让PHP变得更加简单容易上手， 直抒心意。但是同时也带来了一个坏处：PHP很难在请求间复用资源， 类似PHP框架这种耗时的工作， 每次请求都需要反复做——即使每次都在做同样的事情。特别是在高并发的场景，框架快速的初始化和释放，简直就是性能灾难。也正因为如此，在PHP发展过程中，关于是否使用框架的争论也从未停止过。
Stone主要优化的就是这个问题。 它作为独立的进程单独启动，在框架资源初始化结束后再开启FastCGI服务。这样， 新的请求过来是直接从资源初始化结束后的状态开始，避免每次请求去做资源初始化的事情。本质上， Stone运行时是常驻内存的，它和PHP-FPM一样，是一个FastCGI的实现，不同的是， FPM每次执行请求都需要重新初始化框架， Stone直接使用初始化的结果， 可以极大地提高框架性能。
同样，事情总是有好有坏。使用Stone带来的缺点是：PHP编程变得更难了。你需要考虑内存的释放，需要关心PHP如何使用内存。甚至， 你需要了解使用的框架，以免『不小心』写出让人『惊喜』的效果。同时， PHP的调试变得更难， 因为每次修改程序后需要重启进程才能看到效果。当然，开发Stone时针对调试这方面做了不少工作，基本可以避免这个问题。而使用Stone的好处是：程序的性能得到极大的提高， 可以轻松应对高并发的场景。
没有完美的架构， 只有需求，时间和成本的平衡， 任何架构都是平衡的结果。
当然， 客观上的一些利好因素是：
- PHP的内存回收已经相当稳定和高效
- Swoole稳定性已经在相当多的项目中得到验证
- Laravel代码质量相当高
正是因为有了这些条件， 才使得Stone的出现成为可能， 感谢这个伟大的开源时代！
性能对比
| 应用类型 | 原始Laravel | Stone-Web | Stone-Server | 原生php直接echo |
|---|---|---|---|---|
| laravel5 默认页面 | 150 | 3000 | -- | -- |
| laravel5 简单接口 | 150 | 3000 | 8500 | 9500 |
| laravel4 实际项目简单页面 | 70 | 1000 | -- | -- |
| laravel4 简单接口 | 120 | -- | 8200 | 9500 |
| laravel4 实际项目首页 | 35 | 380 | -- | -- |
- 以上单位全部为RPS
- Stone相对于原始的Laravel有相当可观的提升
- 即使和一个简单的echo相比， Stone性能损失仅10%左右
测试环境如下：
PHP 5.6.17-0+deb8u1 (cli) (built: Jan 13 2016 09:10:12)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies
Linux office 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux
16核 Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz
16G 内存
Laravel 4.2
Laravel 5.2
如果你对stone感兴趣， 进入下一章节了解如何5分钟快速使用Stone吧。