在高负载站点中使用PHP的策略 [英] Tactics for using PHP in a high-load site

查看:90
本文介绍了在高负载站点中使用PHP的策略的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在回答这个问题之前,我还没有开发出足以达到高服务器负载的流行工具.把我当成是一个刚刚降落在地球上的外星人,尽管它知道PHP和一些优化技术.

Before you answer this I have never developed anything popular enough to attain high server loads. Treat me as (sigh) an alien that has just landed on the planet, albeit one that knows PHP and a few optimisation techniques.

我正在使用 PHP 开发一个工具,如果可以的话,该工具可以吸引很多用户.但是,尽管我完全有能力开发该程序,但是在编写可以处理大量流量的东西时却一无所知.因此,这里有一些问题(也可以将这个问题也变成资源线程).

I'm developing a tool in PHP that could attain quite a lot of users, if it works out right. However while I'm fully capable of developing the program I'm pretty much clueless when it comes to making something that can deal with huge traffic. So here's a few questions on it (feel free to turn this question into a resource thread as well).

目前,我计划在PHP5中使用MySQLi功能.但是,我应该如何设置与用户和内容相关的数据库?我实际上是否需要多个数据库?目前,所有内容都混杂在一个数据库中-尽管我一直在考虑将用户数据分发到一个数据库,将实际内容分发到另一个数据库,最后将核心站点内容(模板母版等)分发到另一个数据库.我这样做的原因是,将查询发送到不同的数据库将减轻它们的负载,因为一个数据库= 3个负载源.如果它们都在同一台服务器上,这是否仍然有效?

At the moment I plan to use the MySQLi features in PHP5. However how should I setup the databases in relation to users and content? Do I actually need multiple databases? At the moment everything's jumbled into one database - although I've been considering spreading user data to one, actual content to another and finally core site content (template masters etc.) to another. My reasoning behind this is that sending queries to different databases will ease up the load on them as one database = 3 load sources. Also would this still be effective if they were all on the same server?

我有一个用于构建页面和交换变量的模板系统.主模板存储在数据库中,每次调用模板时,都会调用其缓存副本(HTML文档).目前,这些模板中有两种类型的变量-静态变量和动态变量.静态变量通常是诸如页面名称,站点名称之类的东西-不会经常更改的东西.动态变量是在每次页面加载时都会更改的内容.

I have a template system that is used to build the pages and swap out variables. Master templates are stored in the database and each time a template is called it's cached copy (a html document) is called. At the moment I have two types of variable in these templates - a static var and a dynamic var. Static vars are usually things like page names, the name of the site - things that don't change often; dynamic vars are things that change on each page load.

我对此的疑问:

说我对不同的文章有评论.这是一个更好的解决方案:每次页面加载时都存储简单的注释模板并呈现注释(通过DB调用),或者将注释页面的缓存副本存储为html页面-每次添加/编辑/删除注释时页面被重新缓存.

Say I have comments on different articles. Which is a better solution: store the simple comment template and render comments (from a DB call) each time the page is loaded or store a cached copy of the comments page as a html page - each time a comment is added/edited/deleted the page is recached.

任何人都没有在PHP上运行高负载站点的任何提示/指针.我很确定这是一种可行的语言-Facebook和Yahoo!赋予它很高的优先级-但是我有什么需要提防的经验吗?

Does anyone have any tips/pointers for running a high load site on PHP. I'm pretty sure it's a workable language to use - Facebook and Yahoo! give it great precedence - but are there any experiences I should watch out for?

推荐答案

没有两个站点是相同的.您确实需要获得一个 jmeter 之类的工具和基准,以查看问题的根源.您可以花费大量时间进行猜测和改进,但是只有在衡量和比较更改后才能看到真正的结果.

No two sites are alike. You really need to get a tool like jmeter and benchmark to see where your problem points will be. You can spend a lot of time guessing and improving, but you won't see real results until you measure and compare your changes.

例如,多年来,MySQL查询缓存一直是我们所有性能问题的解决方案.如果您的网站运行缓慢,MySQL专家建议您打开查询缓存.事实证明,如果您的写入负载很高,则缓存实际上会瘫痪.如果您不进行测试就将其打开,您将一无所知.

For example, for many years, the MySQL query cache was the solution to all of our performance problems. If your site was slow, MySQL experts suggested turning the query cache on. It turns out that if you have a high write load, the cache is actually crippling. If you turned it on without testing, you'd never know.

并且不要忘记您从未完成缩放.处理10req/s的站点将需要更改以支持1000req/s.而且,如果您足够幸运,需要支持10,000req/s,那么您的体系结构可能看起来也将完全不同.

And don't forget that you are never done scaling. A site that handles 10req/s will need changes to support 1000req/s. And if you're lucking enough to need to support 10,000req/s, your architecture will probably look completely different as well.

  • 不要使用MySQLi- PDO 是现代"的OO数据库访问层.要使用的最重要功能是查询中的占位符.它足够聪明,可以为您使用服务器端准备和其他优化.
  • 您现在可能不想破坏数据库.如果您确实发现一个数据库无法满足需求,则有多种技术可以扩展,具体取决于您的应用程序.如果读取次数多于写入次数,则复制到其他服务器通常效果很好.分片是一种将数据拆分到多台计算机上的技术.
  • Don't use MySQLi -- PDO is the 'modern' OO database access layer. The most important feature to use is placeholders in your queries. It's smart enough to use server side prepares and other optimizations for you as well.
  • You probably don't want to break your database up at this point. If you do find that one database isn't cutting, there are several techniques to scale up, depending on your app. Replicating to additional servers typically works well if you have more reads than writes. Sharding is a technique to split your data over many machines.
  • 您可能不想缓存在数据库中.数据库通常是您的瓶颈,因此添加更多IO通常是一件坏事.有几种PHP缓存可以完成类似的事情,例如 APC 和Zend.
  • 通过打开和关闭缓存来测量系统.我敢打赌,您的缓存比直接提供页面要重.
  • 如果要花很长时间从数据库中构建评论和文章数据,请集成 memcache 进入您的系统.您可以缓存查询结果并将其存储在memcached实例中.重要的是要记住,从内存缓存中检索数据必须比从数据库中组装数据要快得多,以了解任何好处.
  • 如果您的文章不是动态的,或者您在生成文章后进行了简单的动态更改,请考虑将html或php写到磁盘上.您可能有一个index.php页面,该页面在磁盘上查找该文章,如果有的话,它会将其流式传输到客户端.如果不是,它将生成文章,将其写入磁盘,然后将其发送给客户端.从磁盘上删除文件将导致页面被重写.如果在文章中添加了评论,请删除缓存的副本-它将重新生成.
  • You probably don't want to cache in your database. The database is typically your bottleneck, so adding more IO's to it is typically a bad thing. There are several PHP caches out there that accomplish similar things like APC and Zend.
  • Measure your system with caching on and off. I bet your cache is heavier than serving the pages straight.
  • If it takes a long time to build your comments and article data from the db, integrate memcache into your system. You can cache the query results and store them in a memcached instance. It's important to remember that retrieving the data from memcache must be faster than assembling it from the database to see any benefit.
  • If your articles aren't dynamic, or you have simple dynamic changes after it's generated, consider writing out html or php to the disk. You could have an index.php page that looks on disk for the article, if it's there, it streams it to the client. If it isn't, it generates the article, writes it to the disk and sends it to the client. Deleting files from the disk would cause pages to be re-written. If a comment is added to an article, delete the cached copy -- it would be regenerated.

这篇关于在高负载站点中使用PHP的策略的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆