订阅云计算RSS CSDN首页> 云计算

为Symfony2和Redis正名,基于PHP的10亿请求/周网站打造

发表于2014-08-04 13:39| 次阅读| 来源Octivi Labs| 0 条评论| 作者Jared Tarbell

摘要:Octivi当下网站每周请求数已达10亿次,然而出人意料的是,他们仍然使用着Symfony2这个通常被认为低性能的PHP Framework。除此之外,他们更使用了Redis作为主要储存。

【编者按】如果你还在Symfony2和Redis使用中存在这样的错误观念——不能使用Redis作为主要存储;Symfony2的功能很多,以至于它的运行很慢,那么不妨看向Octivi的高请求网站打造。虽然没有底层细节,但详细展示基于两者应用的宏观特性,以及开发时的Symfony2特征。


免费订阅“CSDN大数据”微信公众号,实时了解最新的大数据进展!

CSDN大数据,专注大数据资讯、技术和经验的分享和讨论,提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、机器学习、智能算法等相关大数据观点,大数据技术,大数据平台,大数据实践,大数据产业资讯等服务。


以下为译文:


有人说Symfony2像其它的复杂框架一样,很慢,但是我们认为这一切都取决用户的本身。本文将介绍基于Symfony2,每周执行10亿多个请求的应用的软件架构细节。

下面将展示tweeting之后的社交反馈:


本文将介绍基于Symfony2和Redis的应用。在此不会有过多的细节描述,相反我们将给你展示这些应用的宏观特性,以及开发时的Symfony2特征。

对于低层次的Symfony2性能优化实践,我们写了专门的文章——掌握Symfony2性能系列——InternalsDoctrine

首先是关于所描述应用的一些数据。

来自单个程序节点的性能统计:

  • Symfony2实例每秒处理700个请求,每个请求平均响应时间30毫秒
  • Varnish每秒处理12000多个请求(通过压力测试获得)

注意,如下面所描述的,整个平台包括许多这种节点

Redis度量:

  • 1.6亿多个键(其中98%是永久存储);
  • 89% hits—也就是说,只有11%的交易到达MYSQL服务器。

栈结构

应用

所有的流量都会流入HAProxy,HAProxy将流量分配给应用服务器。

应用实例前是Varnish Reverse Proxy。

我们保持Varnish在每个应用的服务器都保持高度可用性——没有单点故障。单个Varnish分配流量可能导致风险。分离的Varnish实例可能降低缓存hit,不过我们可以接受这个。我们对可用性的需求高于对性能的需要,不过你可以从这些数字中看到,性能也不是什么问题。

应用的服务器配置:

  • Xeon E5-1620@3.60GHz, 64GB RAM, SATA
  • Apache2 (我们甚至不用nginx)
  • PHP 5.4.X以PHP-FPM运作,伴随APC

数据存储

我们使用Redis和MySQL存储数据,它们的数字还挺大的:

  • Redis
  1. 1.5万次撞击/秒
  2. 1.6亿个键

  • MySQL:

  1. 多于400 GB的数据
  2. 3亿份记录

我们即使用Redis作为永久存储(用的最多的资源),又使用Redis作为MySQL上的缓存层。与典型的缓存相比,Redis存储数据的比率很高——我们存储1.55亿多个永久类型键和仅500万个缓冲键。实际上,我们可以使用Redis作为主要的数据存储。

Redis配有主从设置。通过这种方式我们获得HA——如果发生运行中断我们可以很快的将主节点切换到某一个从节点。一些管理任务如升级也需要这些配置。在升级节点时,我们可以选择新的主节点,然后升级先前的主节点,最后交换两个节点。

我们仍在等待生产就绪的Redis集群,这些集群可以提供类似自动故障恢复(升级节点时即使是手动故障恢复也会方便的多)的功能。不过目前还没有任何关于官方发布日期的消息。

MySQL通常用作非耗尽资源的第三层缓存层(Varnish > Redis > MySQL)。所有的表都是InnoDB,最多的查询是简单的

SELECT ... WHERE 'id'={ID}
这个查询返回单个结果。我们还没有发现这么设置会有什么性能问题。

Redis设置不同,MySQL运行在主配置上,除高可用性外,这还提供了更好的写性能(在Redis中这不是什么问题,因为我们不会耗尽性能特性。)


Application’s Architecture

Symfony2功能

Symfony有一些很棒的功能,这些功能使开发过程变得更容易,下面我们绍开发者最喜欢的一些功能:

注释

我们使用带注释的Symfony2标准分布:

  • 路由选择——路由定义了应用的URL—我们也测试了Apache的愚蠢的路由规则,但它没有任何的主要优化。
  • 服务容器——我们使用JMSDiExtraBundle的服务注释定义我们的DI容器—这加速了开发,允许我们用PHP代码处理服务定义,我们发现PHP代码更可读。

因为应用用作REST API,所以我们主要不使用模板(例如Twig)。我们保留模板主要是为了一些内部的仪表盘面板。

我们还没有发现不同的配置类型(YAML/XML)带来的性能影响。因为所有的注释都很好的存储下来了,所以没有什么令人费解的地方—最后所有的东西都是纯PHP代码。

下面是我们使用JMSDiExtraBundle获得的服务配置样例:

/**
 * Constructor uses JMSDiExtraBundle for dependencies injection.
 * 
 * @InjectParams({
 *      "em"         = @Inject("doctrine.orm.entity_manager"),
 *      "security"   = @Inject("security.context")
 * })
 */
function __construct(EntityManager $em, SecurityContext $security) {
    $this->em = $em;
    $this->security = $security;
}

通过这种方式,改变类依赖项只需要改变代码。

Symfony2监控—Monolog和Stopwatch

应用使用Monolog记录意料之外的行为,捕获错误信息。我们使用多个信道获取不同应用模块的分离的日志。

因为FingersCrossed handler使用较多内存(可能导致内存泄漏),所以我们不再使用它。我们选用适当的StreamHandler。使用这种方式时我们需要在单行日志信息添加冗余和额外的内容。

我们也在很多地方使用Stopwatch组件以控制一些典型的应用方法。通过这种方式我们可以发现客制化逻辑一些大块中的弱点。

例如,我们追踪一些外部网络服务的请求次数:

if (null !== $this->stopwatch) {
    $this->stopwatch->start('my_webservice', 'request');
}

// Makes a CURL request to some my_webservice
$response = $this->request($args);

if (null !== $this->stopwatch) {
    $this->stopwatch->stop('my_webservice');
}

控制台组件

开发和维护时,我们特别喜欢Symfony控制台组件,这个组件为创建CLI工具提供了很好的面向对象接口。应用大概添加了50%的新功能,这些新功能基于CLI指令,主要用作管理或分析应用内部构件。

控制台组件妥善的处理命令语句或选项—你可以设置默认值,可选值或所需的值。好的实践总是将这些恰当的记录为代码—你可以给命令和选项设置主要描述。命令通常是自我文档的,因为添加--help选项便能生成格式化的指令描述。

$ php app/console octivi:test-command --help
Usage:
 octivi:test-command [-l|--limit[="..."]] [-o|--offset[="..."]] table

Arguments:
 table                 Database table to process

Options:
 --limit (-l)          Limit per SQL query. (default: 10)
 --offset (-o)         Offset for the first statement(default: 0)

我们必须牢记在准确设置的环境下运行指令。默认的dev可能会导致一些问题,如内存泄漏(因为更多冗长的日志存储和保存调试信息)。

$ php app/console octivi:test-command --env=prod

想要更好的信息显示,添加-v选项。

$ php app/console octivi:test-command --env=prod -vvv

进度条是一个很好的帮手。进度条甚至考虑了信息显示详细程度,当程度比较低时,只显示基本信息,程度比较高时,还可以显示运行时间,内存消耗等信息。

此外,我们还有一些耗时大约两天的迁移过程—0内存泄漏—没有进度条,监控它们将是灾难。

数据层

对于Redis,数据层我们使用PredisBundle。

我们拒绝Doctrine ORM,因为它将添加额外费用,而且我们不需要任何高级的面向对象操作。我们使用Doctrine DBAL代替,Doctrine DBAL特征如下:

  • 查询生成器
  • 预处理语句

使用PredisBundle和Doctrine Bundle也允许我们在大量使用分析工具的时候监控弱查询。

总结

多亏Symfony2,这种设置在保持高性能和高可用性的同时保持了友善的开发环境——可维持,稳定。实际上这是用作电商网站的关键子系统的关键业务需求。

因此本文的最后我们可以纠正一些错误观点:

  • 不能使用Redis作为主要存储——如我们先前所说的,当然是可以的!Redis是一项很稳定的技术,有一些持续性机制,你不会丢失关键数据。
  • Symfony2功能很多以至于它很慢——当你不使用例如ORM的一些耗时/内存的工具时,你可以获得和Silex(是的,我们测试过它)微框架类似的性能。

原文链接:Handling 1 Billion requests a week with Symfony2(编译/ 蔡仁君 责编/仲浩)

0
0
  • CSDN官方微信
  • 扫描二维码,向CSDN吐槽
  • 微信号:CSDNnews
程序员移动端订阅下载

微博关注

相关热门文章