我可以对 Symfony + Doctrine 进行哪些性能改进？答案

【问题标题】：What performance improvements can I make to Symfony + Doctrine?我可以对 Symfony + Doctrine 进行哪些性能改进？
【发布时间】：2012-07-02 22:20:18
【问题描述】：

我最近为一所处理近 200 个表的大学构建了一个相当复杂的数据库应用程序。一些表（例如 Publications）可以包含 30 个或更多字段并存储 10 个一对一 FK 关系和最多 2 或 3 个多对多 FK 关系（使用交叉引用-ref 表）。我自始至终都使用整数 ID，规范化一直是每一步的关键。 AJAX 是最小的，大多数页面都是标准的 CRUD 表单/流程。

我使用过 Symfony 1.4、Doctrine ORM 1.2、MySQL、PHP。

虽然开发时间和易于维护的好处是巨大的（在使用 MVC 和 ORM 时），但我们一直在速度方面遇到问题。也就是说，当我们有多个用户在任何时候登录并处于活动状态时，应用程序会显着变慢（保存或编辑记录最多需要 20 秒）。

我们目前正在与我们的系统管理员进行讨论，但他们说我们应该拥有足够的权力。当有 6 个或更多用户参与活动时，我们最终会在虚拟服务器环境中将 4 个 CPU 排队，而内存使用率很低（没有出血）。

当然，我们正在考虑对我们的 mySQL 应用程序进行多线程处理（如果这会有所帮助），优化我们的代码（尽管其中大部分是由 MVC 生成的）并优化我们的缓存使用（这可能会更好，尽管使用的大部分屏幕是用户登录特定和动态的）；我们已经安装了 APC、额外的内存、对我们的数据库进行了碎片整理、我已经尝试取消设置所有记录集（尽管我知道这现在在 ORM 中是自动的）、发起手动垃圾回收......

但我要问的问题是，mySQL、PHP 和 Symfony MVC 一开始对于开发这种规模的应用程序是否真的是一个糟糕的选择？如果是这样，对于这种规模/复杂性的基于 Web 的数据库界面应用程序，人们通常使用/推荐什么？

【问题讨论】：

对不起，也许我的意思是多通道我们的 mySQL 数据库..
那么您确定是哪个进程占用了资源吗？如果没有看到内存和 CPU 崩溃的原因，进行优化是没有意义的。另外，您有什么保证您的查询是最佳的？表的数量无关紧要，重要的是数据的大小，它的索引方式决定了 b 树的大小和内存消耗（假设您使用的 InnoDB 具有足够大的 buffer_pool_size）。所以回答你的问题很困难，任何人都可以猜出问题所在。将其归咎于学说或php还为时过早，请检查哪个进程先吃资源。
如果您对自己的系统感到满意，我会在放弃之前对其进行优化。有很多因素。首先想到的是，对于正在运行的查询，您的数据库中可能没有正确的索引。打开你的慢查询日志，检查你在那里找到的查询，使用解释命令来判断慢查询是否正在执行未索引的搜索。根据需要添加索引。
亲爱的NB和 AllInOne，我已经索引了所有 FK 关系。没有任何未编入索引的查询。关于慢查询，是的，您是对的，但其中大多数是由 Symfony 构建的。我确实将 table_methods 应用于大多数具有根别名扩展的列表查询，并且我确实倾向于使用代数语法进行 SQL 连接（这真的很糟糕吗？？）。
然而，我的问题实际上比要求精确定位可能出现的问题更为笼统。我以前没有自己构建过这么大的系统，我想知道是否有更好/更值得推荐的技术来做这种事情？也许不是..

标签： php mysql orm symfony1 cpu-speed

【解决方案1】：

我对 Symfony 或 Doctrine 没有任何经验。但是，肯定有比您更大的网站是建立在这些项目上的。例如，DailyMotion 两者都使用，而且它服务的远不止几个同时的用户。

同样，PHP 和 MySQL 也用于 Wikipedia 等大型网站，因此可扩展性应该不是问题。（顺便说一句，默认情况下 MySQL 应该是多线程的——每个连接一个线程。）

当然，合理的表现是相对的。如果您尝试在壁橱中的米色盒子上运行一个处理 200 个并发请求的站点，那么您可能需要优化代码，而不是拥有自己的数据中心的财富 500 强公司。

显而易见的事情是实际分析您的应用程序并查看瓶颈在哪里。分析 MySQL 查询非常简单，还有各种 PHP profiling tools，如 Xdebug。从那里您可以确定是否应该切换框架、ORM（或完全放弃 ORM）、数据库或重构一些代码，或者只是投资更多的处理能力。

【讨论】：

谢谢你，Lese。这很有帮助。这是我第一次构建这种规模的东西，我不确定瓶颈是软件（php、ORM 或 mySQL）还是硬件（服务器）。
我现在正在考虑将 kcachegrind 安装到我们的开发服务器上。看起来应该可以解决问题。

【解决方案2】：

加速复杂数据库操作的最佳方法是不调用它们:)。

因此，请分析您可以缓存应用程序的哪些部分。
Symfony 有一个非常好的缓存系统（在 symfony2 中甚至更好），可以非常精细地使用。

在数据库方面，另一种方法是使用视图或嵌套集来存储聚合数据。
尝试找到合适的部分。

【讨论】：

谢谢你，伊沃巴。一般来说，我对缓存并不感兴趣。是时候更多地研究它了。我猜 Symfony 文档是最好的来源..