如何重写/重新编码网站以使其可扩展?

发布于 2024-08-23 04:38:41 字数 103 浏览 11 评论 0原文

如何重写一个可扩展的网站?(流量)我主要使用 PHP 和一些 Ruby on Rails,我知道这是一个普遍问题。我只是想增加我的知识,所以任何建议都会有用。

先感谢您 ;-)

How do you rewrite a website to be scalable?(traffic) I work with mainly PHP and some Ruby on rails and i know its a generic question. I'm just looking to increase my knowledge so any advice would be useful.

Thank you in advance ;-)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

丑疤怪 2024-08-30 04:38:41

这是一个相当广泛的问题,很难给你一个明确的答案——但有几个想法:

  • 首先,不要预先优化!
    • 确保您的应用程序有效;这是最重要的事情。
    • 并且,只有在必要时才开始优化。
  • PHP 本身通常具有良好的扩展性:
    • 添加更多 Apache+PHP 服务器,对用户进行负载平衡
    • 而且这往往非常容易实现
  • 文件系统不能很好地/那么容易地扩展:
    • 它不会跨服务器共享
    • 共享文件系统(例如,使用 NFS)有时会导致问题。
  • 在扩展方面,数据库通常是最难的部分:
    • 拥有多个“写入”服务器很困难
    • 拥有多个“读取”服务器(通常使用复制)可能会给维护带来麻烦
    • 如果复制还不够,您有一天或另一天必须考虑分片。
  • 使用大量缓存:可以使用的缓存越多,对数据库进行的查询越少,效果就越好
    • memcached 很棒,并且扩展性良好:只需添加几台服务器,您的缓存集群中就会获得更多 GB 或内存
  • 使用反向代理,您的 Apache+PHP 服务器的工作量就会减少这样做,也有帮助。

还有一些可能会给您一些想法的快速链接:

This is a quite wide question, and it's going to be pretty difficult to give you a definite answer -- but a couple of ideas :

  • First of all, do not pre-optimize !
    • Make sure your application works ; that's the most important thing.
    • And, only when it becomes necessary, start optimizing.
  • PHP by itself generally scales well :
    • Add a couple more Apache+PHP servers, load-balance your users
    • And this tends to work really easily
  • Filesystem doesn't scale that well / that easily :
    • it's not shared accross servers
    • sharing filesystem (with NFS, for instance) can sometimes cause problems.
  • The database is generally the hardest part, when it comes to scaling :
    • Having more than one "write" server is hard
    • Having more than a couple of "read" servers, generally using replication, can become a pain for maintenance
    • You'll have to think about sharding, one day or another, if replication is not enough.
  • Use lots of caching : the more cache you can use, the less queries you'll make to the DB, the better it'll be
    • memcached is great, and scales well : just add a couple of servers, and you get a couple of more GB or memory in your caching-cluster
  • Using a reverse-proxy, so your Apache+PHP servers have less work to do, helps too.

And a quick couple of links that might give you some ideas :

最美不过初阳 2024-08-30 04:38:41

一个技巧 - 使用 memcached 或同等版本,而不是直接查询数据库。

此外,扩展最困难的部分是超越单个 Web 服务器。一旦您可以扩展到两个 Web 服务器,那么扩展到更多服务器就不会有太大问题。

One tip - cache data using memcached or an equivalent, instead of querying the database directly.

Also, the most difficult part of scaling is moving beyond a single web server. Once you can scale to two web servers, you should not have much trouble scaling to many more.

乱世争霸 2024-08-30 04:38:41

获得 PHP 加速器,您的性能绝对会得到显着提升,Wikipedia 有一个很好的列表从中选择。正如 Justin 所说,使用 memcached,这太棒了。

Get a PHP accelerator, you will definatly have a noticable performance increase, Wikipedia has a nice list to choose from. And as Justin said get memcached, it is amazing.

只是我以为 2024-08-30 04:38:41

“规模”不是一个普遍的、具体的现象,而是在一组特定标准下对绩效和能力的相对衡量。因此,您需要一组标准和一些指标,以使此对话具有任何意义。

我发现 Apdex 是思考和推理所需指标的非常有用的机制:

Apdex(应用程序性能指数)
是一个开放标准,由
公司联盟定义了
标准化报告方法,
基准测试和跟踪应用
性能。

像 Apdex 指数这样的系统的优点在于,它与用户对满意的应用程序响应能力的看法直接相关。在任何关于规模和性能的讨论中,这些是唯一真正重要的事情。

因此,例如,当以这种方式考虑您的系统时,您可以确定满足用户对响应能力的期望所需的响应率,估计需要支持的流量水平,然后添加容量以满足您的目标。

"Scale" isn't a universal, concrete phenomena, but a relative measure of performance and capacity under a specific set of criteria. So you need a set of criteria and some metrics in order for this conversation to have any meaning at all.

I have found Apdex to be a very useful mechanism for thinking and reasoning about the metrics required:

Apdex (Application Performance Index)
is an open standard developed by an
alliance of companies that defines a
standardized method to report,
benchmark, and track application
performance.

The beauty of a system like an Apdex Index is that it is directly related to users' perceptions of satisfactory application responsiveness. These are the only things that actually matter in any discussion of scale and performance.

So, for example, when thinking about your system in this way, you determine the response rate required to meet your user's expectation of responsiveness, you estimate the level of traffic you will need to support, then add capacity to meet your targets.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文