blocks|key|1414641|text|如果您希望您的站点扩展到超出单个服务器的能力范围，则需要仔细规划。设计以使以下各项成为可能：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1414642|1414643|使您的数据库可以位于单独的服务器上。这通常并不太难。|unordered-list-item|1414644|确保您的所有静态内容都可以移动到CDN，因为这通常会从您的服务器上卸下大量负载。|1414645|准备好在硬件上花费大量资金。更多的内存和更快的磁盘有很大帮助。|1414646|当你需要将数据库或php从一台服务器拆分到多台服务器时，这会变得困难得多，所以优化一切，从你的代码，你的数据库模式，你的服务器配置和任何你能想到的尽可能长时间推迟这最后一步。|1414647|1414648|除此之外，您所能做的就是对您的站点进行压力测试，找出瓶颈所在，并尝试设计它们。|1414649|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|V|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

If you expect your site to scale beyond the capabilities of a single server you will need to plan carefully. Design so the following will be possible:-

<ul>
<li>Make it so your database can be on a separate server. This isn't normally too hard.</li>
<li>Ensure all your static content can be moved to a CDN, as this will normally pull a lot of load off your servers.</li>
<li>Be prepared to spend a lot of money on hardware. More RAM and faster disks help a LOT.</li>
<li>It gets a lot harder when you need to split either the database or the php from a single server to multiple servers, so optimise everything, from your code, your database schema, your server config and anything else you can think of to put this final step off for as long as possible.</li>
</ul>

Other than that, all you can do is stress test your site, figure out where the bottlenecks are and try and design them away.

blocks|key|4316374|text|在高负载下测试网站。修复所有statistics|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4316375|Find瓶颈|unordered-list-item|4316376|ordered-list-item|4316377|4316378|4316379|Go+to+1|4316380|<代码>G211|4316381|4316382|祝好运|4316383|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|S|8|@]|9|@]|A|$]]|$1|E|3|-4|5|F|7|T|8|@]|9|@]|A|$]]|$1|G|3|-4|5|F|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|F|7|V|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|W|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|X|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Z|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|Q|$]]

<ol>
<li>Test your website under heavy load.</li>
<li>Monitor all statistics</li>
<li>Find bottleneck</li>
<li>Fix bottleneck</li>
<li>Go back to 1</li>
</ol>

good luck

blocks|key|113319|text|查看Rasmus+Lerdorf的this+talk+(PHP的创建者)|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|113320|特别是第8页及以上。|113321|entityMap|0|LINK|mutability|MUTABLE|url|http://talks.php.net/show/zagreb2/0^0|H|9|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Check out <a href="http://talks.php.net/show/zagreb2/0" rel="nofollow noreferrer">this talk</a> by Rasmus Lerdorf (creator of PHP)

Specially Page 8 and beyond.

blocks|key|4316399|text|您可能需要查看此资源-+highscalability.com。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4316400|entityMap|0|LINK|mutability|MUTABLE|url|http://highscalability.com/^0|C|J|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You might want to look at this resource- <a href="http://highscalability.com/" rel="nofollow noreferrer">highscalability.com</a>.

blocks|key|113394|text|许多人提到了识别瓶颈的工具，这当然是必要的。你不能在不知道它在哪里慢的情况下，就把高效的时间花在加速上。但您需要知道的另一件事是您的目标可伸缩性在哪里。如果人力资源部门有三个人使用你的网站，那么花几个月的时间让你的网站扩展到与Twitter相同的用户数量，这值吗？您是否已知产品需求中的事务率、响应延迟或用户数？如果是这样的话，将这些数字作为优化策略的目标。如果不是，请在追逐性能耗子之前找出它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|113395|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

A number of people have mentioned tools for identifying bottlenecks, and that is of course necessary. You can't spend productive time speeding something up without knowing where it's slow. But the other thing you need to know is where your target scalability lies. Is it value for money to spend a couple of months making your site scale to the same number of users as Twitter if it's going to be used by three people in HR? Do you have a known rate of transactions, or response latency, or number of users, in the requirements of the product? If so, target those numbers with your optimisation strategy. If not, find those out before chasing the performance rat down the hole.

blocks|key|4316594|text|非常相似：How+Is+PHP+Done+the+Right+Way?|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4316595|可伸缩性不是一个小问题，而且肯定比一个问题中可以合理涵盖的材料更多。|4316596|例如，对于某些类型的应用程序，joins+(在SQL中)不能伸缩，这带来了各种缓存和分片策略。|4316597|Beanstalk是高性能PHP站点中的另一个可伸缩性和性能工具。memcache也是如此(不同类型)。|4316598|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/694246/how-is-php-done-the-right-way^0|5|U|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

Very similar: <a href="https://stackoverflow.com/questions/694246/how-is-php-done-the-right-way">How Is PHP Done the Right Way?</a>

Scalability is no small subject and certainly more material than can be reasonably covered in a single question.

For instance, with some kinds of applications, joins (in SQL) don't scale, which brings up all sorts of caching and sharding strategies.

Beanstalk is another scalability and performance tool in high-performance PHP sites. As is memcache (different kind).

blocks|key|1412554|text|按重要性排序：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1412555|PHP|1412556|如果你运行PHP，使用一个像APC这样的操作码缓存。(这一点非常重要，可以内置于下一代PHP中。)|unordered-list-item|offset|length|1412557|
|1412558|使用YSlow或Google+Page+Speed来识别瓶颈。(这将揭示网站的结构问题，这些问题同时影响客户端和服务器performance.)|1412559|1412560|Ensure，即您的web服务器为静态内容(图像、Javascript、CSS)发送适当的Expires标头，以便浏览器可以正确缓存这些内容。(YSlow也会对此发出警告。)|1412561|1412562|使用超文本传输协议加速器，如Varnish。(This+picture说了一切--他们已经有了一个超文本传输协议加速器。)|1412563|1412564|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/List_of_PHP_accelerators#Alternative_PHP_Cache|1|http://developer.yahoo.com/yslow/|2|http://code.google.com/speed/page-speed/|3|http://www.varnish-cache.org/|4|http://perbu.livejournal.com/6895.html^0|0|0|E|3|0|0|0|2|5|1|8|H|2|0|0|0|0|E|7|3|N|C|4|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1A|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1B|8|@]|9|@$G|1C|H|1D|1|1E]]|A|$]]|$1|I|3|J|5|6|7|1F|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1G|8|@]|9|@$G|1H|H|1I|1|1J]|$G|1K|H|1L|1|1M]]|A|$]]|$1|M|3|J|5|6|7|1N|8|@]|9|@]|A|$]]|$1|N|3|O|5|F|7|1O|8|@]|9|@]|A|$]]|$1|P|3|J|5|6|7|1P|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|1Q|8|@]|9|@$G|1R|H|1S|1|1T]|$G|1U|H|1V|1|1W]]|A|$]]|$1|S|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10]]|11|$5|W|X|Y|A|$Z|12]]|13|$5|W|X|Y|A|$Z|14]]|15|$5|W|X|Y|A|$Z|16]]|17|$5|W|X|Y|A|$Z|18]]]]

In order of importance:

<ol>
<li>If you run PHP, use an opcode cache like <a href="http://en.wikipedia.org/wiki/List_of_PHP_accelerators#Alternative_PHP_Cache" rel="nofollow noreferrer">APC</a>. (This is important enough to be built-in in the next generation of PHP.)</li>
<li>Use <a href="http://developer.yahoo.com/yslow/" rel="nofollow noreferrer">YSlow</a> or <a href="http://code.google.com/speed/page-speed/" rel="nofollow noreferrer">Google Page Speed</a> to identify bottlenecks. (This will reveal structural problems with your website that affect both client and server performance.)</li>
<li>Ensure that your web server sends a proper Expires header for static content (images, Javascript, CSS), such that the browser can cache it properly. (YSlow will warn you about this, too.)</li>
<li>Use an HTTP accelerator, such as <a href="http://www.varnish-cache.org/" rel="nofollow noreferrer">Varnish</a>. (<a href="http://perbu.livejournal.com/6895.html" rel="nofollow noreferrer">This picture</a> says it all – and they already had an HTTP accelerator in place.)</li>
</ol>

blocks|key|1412594|text|可伸缩性最大的问题通常是像DBMS这样的共享资源，因为DBMS通常没有办法放松一致性保证。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1412595|如果您想在使用诸如MySQL之类的东西时提高可伸缩性，则必须更改您的模式设计以放松一致性。|1412596|例如，您可以分离您的数据库模式，使您的规范化数据模型用于写入，而复制的只读非规范化部分用于90%25的读取操作。只读数据可以分布在多个服务器上。|1412597|提高数据库可伸缩性的另一种方法是对数据进行分区，例如，将每个部门的数据分离到一个数据库中，并在ORM或DBMS中聚合它们。|1412598|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The biggest problem for scalability is usually shared resources like DBMS's. The problem arises because DBMS's usually have no way to relax consistency guarantees. 

If you want to increase scalability when you use something like MySQL you have to change your schema design to relax consistency. 

For instance, you can separate your database schema to have your normalized data model for writes, and a replicated read only denormalized part for the 90% of read operations. The read only data can be spread over several servers.

Another way to increase scalability of a database is to partition the data, e.g. separate the data into a database for every department and aggregate them either in the ORM or in the DBMS.

blocks|key|1414583|text|使用可靠的OOP技术开发您的站点。你需要你的网站模块化，因为并不是所有的性能瓶颈在一开始都是显而易见的。准备好随着流量的增加而重构站点的某些部分。我写的第一句话将帮助你更容易、更安全地做到这一点。此外，使用测试驱动的开发，因为重构意味着新引入的bug，并且好的TDD在它们进入生产之前很好地捕获它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1414584|尽可能多地将客户端代码与服务器端代码分开，因为它们很可能是从不同的服务器提供的，如果您的站点流量证明了这一点。|1414585|阅读文章(例如，阅读YSlow提示)。|1414586|总帐|1414587|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Develop your site using solid OOP techniques. You will need your site to be modular as not all performance bottlenecks are obvious at the start. Be ready to refactor parts of your site as traffic increases. The first sentence I wrote will help you do it more easily and safely. Also, use test driven development, As refactor means new introduced bugs, and good TDD is good in catching them before they go into production. 
Separate as much as possible client side code from server side code, as they will likely to be served from different servers, if your site traffic justify this. 
Read articles (read the YSlow tips for instance). 

GL

blocks|key|1100036|text|除了其他建议之外，请考虑将站点拆分为多个层，就像在multitier+architecture中一样。如果处理得当，您可以在每个层使用一台服务器。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1100037|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Multitier_architecture^0|P|M|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

In addition to the other suggestions, look into splitting your sites into tiers, as in <a href="http://en.wikipedia.org/wiki/Multitier_architecture" rel="nofollow">multitier architecture</a>. If done right, you can then use one server per tier.

I am new in the website scalability realm. Can you suggest to me some the techniques for making a website scalable to a large number of users?

Techniques for writing a scalable website

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我是网站可伸缩性领域的新手。你能向我推荐一些让网站可扩展到大量用户的技术吗？

问编写可伸缩网站的技术
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问编写可伸缩网站的技术EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问编写可伸缩网站的技术
EN