我最近为一所处理近 200 个表的大学构建了一个相当复杂的数据库应用程序。某些表(例如 Publications)可以容纳 30 个或更多字段，并存储 10 个一对一 FK 关系和最多 2 或 3 个多对多 FK 关系(使用交叉引用引用表)。我自始至终都使用整数 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 的数据库接口(interface)应用程序，人们通常使用/推荐什么？
最佳答案
我没有任何 Symfony 或 Doctrine 的经验。但是，肯定有比您的网站更大的网站是基于这些项目构建的。例如，DailyMotion 就同时使用这两种方法，而且它所服务的用户数量远远多于少数几个同时用户。
同样，像维基百科这样大的网站都使用 PHP 和 MySQL，因此可扩展性应该不成问题。 (顺便说一句，MySQL 默认情况下应该是多线程的——每个连接一个线程。)
当然，合理的性能是相对的。如果您尝试运行一个在壁橱里的米色盒子上为 200 个并发请求提供服务的网站，那么您可能需要比拥有自己数据中心的财富 500 强公司更多地优化代码。
显而易见的事情是实际分析您的应用程序并查看瓶颈在哪里。分析 MySQL 查询非常简单，而且还有各种 PHP profiling tools像Xdebug 。从那里你可以弄清楚是否应该切换框架、ORM(或完全放弃 ORM)、数据库，或重构一些代码，或者只是投资更多的处理能力。
关于php - 我可以对 Symfony + Doctrine 进行哪些性能改进？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11294747/