我在LAMP设置上有共享主机。显然，每页对Db的调用越少越好。但有多少太多了？二？十？一百？好奇人们的想法。
我在LAMP设置上有共享主机。显然，每页对Db的调用越少越好。但有多少太多了？二？十？一百？好奇人们的想法。
这实际上取决于您的（db）服务器设置。尝试尽可能缓存大部分信息，并将db调用降至最低。数据库（几乎在所有情况下）都是您服务的瓶颈 - 您的网站使用率越高。所以无论你做什么都试图避免激发查询，就好像不是真的有必要。
我尽量不要在每页上使用超过10个db的调用，但这实际上取决于您的基础架构和您想要提供的信息。
我会说这取决于服务器负载。如果您每分钟有1个访问者，那么每页1-10个db调用就可以了。如果您的服务器负载高于每秒10个页面请求，那么您应该考虑使用缓存来最小化数据库服务器上的负载。
当我在.com热潮中的www.boxman.com项目上工作时，他们有一个网站在不同的域名下出现了9个不同的语言/国家网站。每一段文本都是从数据库中提取出来的以及产品等常见的东西......每个页面通常会涉及200多个DB请求，但主要是返回单个id，字符串组合。我们一次有100个用户在系统上。
DB在16路RS6000 unix盒上运行DB2 SQL。这可能与现代3ghz QUAD核心英特尔盒相当。
系统工作......随着数量的增加，我实现了一个缓存，其中包括编写一个同步过程，将每天静态的数据移动到网络服务器的驱动器上，这样它就不再能够访问数据库了。
基本上我会说如果表现还不错那么没关系！但是你应该允许扩大需求，并在它发生时做好准备。
只要服务器（Web和数据库）可以处理您的所有请求并在可接受的时间内返回页面，我认为您当前的查询数量是可以的。这取决于服务器的大规模。 尽管如此，使用尽可能少的查询仍然是一个很好的规则。
一段绳子有多长？一个男人的腿应该多久？您应该在页面加载上进行多少个数据库查询？
没有一个答案。显然，进行不必要的查询是个坏主意。启动过多的DB连接会更糟。缓存不变的值是好的。除此之外，你不能在页面上任意说“你应该只使用$ N查询” - 这取决于你想要做什么以及你的表现目标是什么。
从理论上讲，任何应用程序都可以编写为使用单个数据库查询 - 即使该查询是涉及未编制索引的全表扫描的大规模20向连接，并返回数千个主要为空的行，这些行将占用大量的内存和时间进入应用程序后进行处理。显然，这将是一件非常糟糕的事情。一般来说，避免做一些明显浪费的事情（比如在循环中做一堆单行查询）并且稍后担心性能。
用唐纳德克努特的话来说“我们应该忘记小的效率，大约97％的时间说：过早的优化是所有邪恶的根源”。每个人都在谈论“可扩展性”，就像他们真的会成为下一个推特，但实际上，如果Twitter专注于像现在一样大，那么他们可能永远不会在第一个推出产品。地点。
它最终将取决于您的用户期望的体验。如果他们期望在页面上显示全面的数据，则必须有一些期望：1）无论从数据库中提取的数据量是多少，网站都能够在负载下运行，以及2.）加载页面的时间成本将取决于该特定页面的数据加载，而不是整个服务器负载。
可接受数量的db调用的一个巨大支持者也必须是基础数据库设计。由于底层数据库结构的复杂性，那里有企业级电子商务网站，每个（未缓存）页面加载经常会产生超过100个调用。
总的来说，查看数据库调用的一个好方法是确定特定页面是否在可接受的时间内加载，并从那里查看优化加载时间和CPU和内存使用情况的策略。
除缓存之外的另一个重要问题是使用预准备语句。执行查询时，db必须1）分析查询并2）执行它。如果使用预准备语句，db可以缓存上次使用的查询计划，因此每个查询对dbms的负担较小。不计算您执行的查询数量的负载，但是您对dbms施加了多少压力。执行100个准备好的查询可能比执行代码中ad-hoc生成的50个查询更快。
记住，在24小时内，100,000个页面请求仅超过1秒。只要他们都不立刻请求。
别忘了
托尼
一个或更少总是最好的。两个通常是一个太多。
如果您可以在单个查询中返回多个结果集，那么请执行此操作。如果信息是相当静态的，则将其缓存并从缓存中拉出。
10个单独的数据库调用并不好，但它不会杀死低使用率的站点。