2

我最近为一所处理近 200 个表的大学构建了一个相当复杂的数据库应用程序。一些表（例如 Publications）可以保存 30 个或更多字段并存储 10 个一对一的外键关系和最多 2 或 3 个多对多的外键关系（使用交叉引用引用表）。我自始至终都使用整数 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 的数据库界面应用程序，人们通常使用/推荐什么？

4

2 回答 2

3

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

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

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

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

于 2012-07-02T14:46:24.473 回答
1

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

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

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

于 2012-07-03T07:07:13.500 回答