我用 Kohana 建立的一个网站昨天被大量的流量猛烈抨击,让我退后一步并评估一些设计。我很好奇优化基于 Kohana 的应用程序的一些标准技术是什么?
我也对基准测试感兴趣。我是否需要为每个控制器方法设置Benchmark::start()
并Benchmark::stop()
查看所有页面的执行时间,或者我是否能够在全球范围内快速应用基准测试?
我将在以后更多地使用缓存库,但我愿意接受更多建议,因为我确信我可以做很多我现在根本不知道的事情。
我用 Kohana 建立的一个网站昨天被大量的流量猛烈抨击,让我退后一步并评估一些设计。我很好奇优化基于 Kohana 的应用程序的一些标准技术是什么?
我也对基准测试感兴趣。我是否需要为每个控制器方法设置Benchmark::start()
并Benchmark::stop()
查看所有页面的执行时间,或者我是否能够在全球范围内快速应用基准测试?
我将在以后更多地使用缓存库,但我愿意接受更多建议,因为我确信我可以做很多我现在根本不知道的事情。
我在这个答案中要说的并不是 Kohana 特有的,并且可能适用于许多 PHP 项目。
以下是我在谈到性能、可扩展性、PHP 时想到的一些要点……
我在从事多个项目时使用了许多这些想法——它们有所帮助;所以他们可能也可以在这里提供帮助。
首先,在表演方面,有很多方面/问题需要考虑:
可能真正有用的第一件事是在您的网络服务器前面使用反向代理,如varnish:让它缓存尽可能多的东西,因此只有真正需要 PHP/MySQL 计算的请求(当然还有其他一些请求,当它们不在代理的缓存中时)将其发送到 Apache/PHP/MySQL。
关于使用反向代理作为缓存,例如,对于 PHP 应用程序,您可以查看Benchmark Results Show 400%-700% increase In Server Capabilities with APC and Squid Cache。
(是的,他们正在使用 Squid,我说的是清漆——这只是另一种可能性 ^^ 清漆更新,但更专注于缓存)
如果您做得足够好,并且设法一次又一次地停止重新生成太多页面,那么您甚至不必优化任何代码;-)
至少,也许不会急于求成...当您没有太大压力时,执行优化总是更好...
作为旁注:您在 OP 中说:
我用 Kohana 建立的一个网站昨天被大量的流量猛烈抨击,
这是一种突然的情况,如果您的网站可以处理不及时更新的情况,反向代理实际上可以节省一天的时间:
关于那个,我怎样才能发现并在“Slashdotted”中幸存下来?可能是一个有趣的阅读。
首先:您使用的是最新版本的 PHP吗?随着新版本的推出,速度会定期得到改进;-)
例如,请查看PHP 分支 3.0 到 5.3-CVS 的基准测试。
请注意,性能是使用 PHP 5.3 的一个很好的理由(我已经做了一些基准测试(法语),结果很好) ......
当然,另一个很好的理由是 PHP 5.2 已经到了生命的尽头,并且不再维护!
[apc.stat](https://php.net/manual/en/apc.configuration.php#ini.apc.stat)
可能有利于系统负载;但这意味着除非您刷新整个操作码缓存,否则不会考虑对 PHP 文件所做的修改;关于这一点,有关更多详细信息,请参阅例如To stat() Or Not To stat()?尽可能避免一遍又一遍地做同样的事情。
我在想的主要事情当然是 SQL 查询:您的许多页面可能执行相同的查询,其中一些的结果可能几乎总是相同的......这意味着很多“无用”的查询数据库,它必须花时间一遍又一遍地提供相同的数据。
当然,对于其他事情也是如此,例如 Web 服务调用、从其他网站获取信息、繁重的计算……
您可能会很有趣地确定:
并将这些数据/结果存储在某种缓存中,因此它们更容易获得——更快——而且您不必“无所事事”地访问您的 SQL 服务器。
伟大的缓存机制是,例如:
我很确定您的框架带有一些与缓存相关的东西;您可能已经知道,正如您在 OP 中所说的“我将在未来更多时间使用缓存库”;-)
现在,一件好事是使用Xdebug扩展来分析您的应用程序:它通常可以很容易地找到几个弱点——至少,如果有任何功能需要花费大量时间的话。
配置得当,会生成profiling文件,可以用一些图形工具来分析,比如:
例如,这里有几个 KCacheGrind 的截图:
(来源:pascal-martin.fr)(来源:pascal-martin.fr)
(顺便说一句,如果我没记错的话,第二个屏幕截图上显示的调用图通常是 WinCacheGrind 和 Webgrind 都不能做的事情^^)
(感谢@Mikushi 的评论)我没有使用太多的另一种可能性是xhprof扩展:它还有助于分析,可以生成调用图——但比 Xdebug 更轻,这意味着你应该能够将它安装在生产服务器。
您应该能够与 XHGui 一起使用它,这将有助于数据的可视化。
既然我们已经谈到了 PHP,请注意,您的瓶颈很可能不是 PHP 方面的,而是数据库方面的......
这里至少有两三件事:
EXPLAIN
log_slow_queries
以获取花费“过多”时间的请求列表,并通过这些请求开始优化。不过,最重要的两件事是:
如果你还在阅读,还有什么可以优化的?
好吧,还有改进的空间......一些面向架构的想法可能是:
好吧,也许其中一些想法在你的情况下有点矫枉过正^^
但是,仍然......为什么不研究一下,以防万一?;-)
您最初的问题是关于优化使用 Kohana 的应用程序...好吧,我已经发布了一些适用于任何 PHP 应用程序的想法...这意味着它们也适用于 Kohana
;-)(即使不是特定于它^^)
我说:使用缓存;Kohana 似乎支持一些缓存的东西 (你自己说过,所以这里没有什么新东西......)
如果有什么可以快速完成的,试试吧 ;-)
我还说你不应该做任何不必要的事情;Kohana 中是否有任何您不需要的默认启用的功能?
浏览网络,似乎至少有一些关于XSS过滤的东西;你需要那个吗?
不过,这里有几个可能有用的链接:
最后,一个简单的想法:
我并不是说你不应该优化:你绝对应该!
但是,请进行“快速”优化,这将首先为您带来丰厚的回报:使用一些操作码缓存可能会帮助您减少 10% 到 50% 的服务器 CPU 负载……而且只需几分钟即可设置;- ) 另一方面,花 3 天时间获得 2%...
哦,顺便说一句:在做任何事情之前:把一些监控的东西放在适当的位置,这样你就知道做了哪些改进,以及如何改进!
如果没有监控,您将不知道您所做的事情的效果......即使它是否是真正的优化也不知道!
例如,您可以使用RRDtool + cacti之类的东西。
向你的老板展示一些 CPU 负载下降 40% 的漂亮图形总是很棒的 ;-)
无论如何,要真正得出结论:玩得开心!
(是的,优化很有趣!)
(呃,我不认为我会写那么多......希望至少其中的某些部分有用......我应该记住这个答案:可能在其他时候有用。 ..)
使用XDebug和WinCacheGrind或WebCacheGrind来分析和分析缓慢的代码执行。
(来源:jokke.dk)
使用XDebug 分析代码。
使用大量缓存。如果您的页面是相对静态的,那么反向代理可能是最好的方法。
Kohana 开箱即用的速度非常快,除了使用数据库对象。引用 Zombor “您可以通过确保使用数据库结果对象而不是结果数组来减少内存使用量。” 这在被抨击的网站上产生了巨大的性能差异。它不仅会使用更多内存,还会减慢脚本的执行速度。
另外 - 您必须使用缓存。我更喜欢 memcache 并在我的模型中使用它,如下所示:
public function get($e_id)
{
$event_data = $this->cache->get('event_get_'.$e_id.Kohana::config('config.site_domain'));
if ($event_data === NULL)
{
$this->db_slave
->select('e_id,e_name')
->from('Events')
->where('e_id', $e_id);
$result = $this->db_slave->get();
$event_data = ($result->count() ==1)? $result->current() : FALSE;
$this->cache->set('event_get_'.$e_id.Kohana::config('config.site_domain'), $event_data, NULL, 300); // 5 minutes
}
return $event_data;
}
这也将显着提高性能。上述两种技术将站点性能提高了 80%。
如果您提供更多关于您认为瓶颈在哪里的信息,我相信我们可以提供一些更好的想法。
另请查看 yslow (google it) 以了解其他一些性能提示。
与 Kohana 密切相关(您可能已经这样做了,或者没有这样做):
在生产模式下:
只是我的 2 美分 :)
我完全同意 XDebug 和缓存的答案。在确定最大的速度和规模瓶颈之前,不要查看 Kohana 层进行优化。
XDebug 会告诉您您是否花费了大部分时间并识别代码中的“热点”。保留此分析信息,以便您可以基线和衡量性能改进。
示例问题和解决方案:如果您发现每次都从数据库中构建昂贵的对象,而这些对象并不经常更改,那么您可以考虑使用 memcached 或其他机制缓存它们。所有这些性能修复都需要时间并增加系统的复杂性,因此在开始修复它们之前请确保您的瓶颈。