如何扩展PHP应用程序(服务器,mysql,memcache)

时间:2021-10-29 20:12:17

I'm currently creating a website for a social project in switzerland.

我目前正在为瑞士的一个社交项目创建一个网站。

And before there is an overflow of user, I want to prepare the application to scale.

在用户溢出之前,我想准备应用程序以进行扩展。

I answered by myself many questions but some are left.

我自己回答了许多问题,但有些问题仍未解决。

I explain what I want to do.

我解释一下我想做什么。


First

第一

at the beginnning, the Application will have only one server (short time) with DNS, PHP, Mysql, Data, and memcache.

在开始时,应用程序将只有一个服务器(短时间)与DNS,PHP,Mysql,数据和内存缓存。


Second

第二

Then I will split them in two

然后我将它们分成两部分

  1. DNS, Mysql, memcache
  2. DNS,Mysql,memcache
  3. Data, PHP
  4. 数据,PHP

Third

第三

Here is the problem, I don't know how to do it exactly here to keep the application running well.

这是问题,我不知道如何在这里做到这一点,以保持应用程序运行良好。

I could do :

我可以 :

  1. Front : Load Balancer, memcache, DNS
  2. 前端:负载均衡器,内存缓存,DNS
  3. Web 1 : PHP, DATA
  4. Web 1:PHP,DATA
  5. Web 2 : PHP, DATA
  6. Web 2:PHP,DATA
  7. Mysql
  8. Mysql的

This would be the scheme, all PHP sessions are kept in the DB.

这将是方案,所有PHP会话都保存在DB中。

BUT, how do I sync the data? do I run a Rsync to keep them up to date. do I put them on a separate disk (network disk) to be sure ? but in this case, how can I do in case of user uploads ?

但是,我如何同步数据?运行Rsync以使其保持最新状态。将它们放在单独的磁盘(网络磁盘)上以确定吗?但在这种情况下,如果用户上传,我该怎么办?

and if the website gets more success and we have to go on greater structures, would'nt it create some latency on updates ?

如果网站获得更多成功,我们必须继续更大的结构,它会不会在更新上产生一些延迟?

or would it be a good thing to go directly to amazon's web services ?

或者直接访问亚马逊的网络服务会是一件好事吗?

some infos I use codeigniter as Framework. I use linux as webserver (distribution not chosen now, but should be Debian)

一些信息我使用codeigniter作为框架。我使用linux作为webserver(现在没有选择发布,但应该是Debian)

Thanks in advance for your answers.

提前感谢您的回答。

4 个解决方案

#1


15  

According to Wikipedia, Switzerland has 4.6 million German speakers, 1.5 million French speakers, and .5 million speakers of Italian, Romansch and other languages. So I suspect you'll find that a single server will fit your needs. Guess what percentage of the population will visit your site every month or every day to get a sense of how big you can get before running into scaling issues.

据*称,瑞士有460万德语人士,150万法语人士和0.5百万意大利语,罗曼什语和其他语言。所以我怀疑你会发现一台服务器符合你的需求。猜猜每个月或每天会访问您网站的人口百分比,以了解在遇到扩展问题之前您可以获得多大的收益。

So, I don't think you need to worry about scaling yet! Bonus: The time you don't spend worrying about this problem, you can use to solve other problems for your users.

所以,我认为你还不用担心缩放!奖励:您不必担心此问题的时间,您可以用来为您的用户解决其他问题。

#2


8  

There are a few common paths to scaling web services up, in order of what sites like Flickr and Facebook seem to use:

根据Flickr和Facebook等网站似乎使用的顺序,有一些扩展Web服务的常用途径:

  • Split servers based on concepts (API, login, media files, ads, static pages, dynamic pages)
  • 根据概念拆分服务器(API,登录,媒体文件,广告,静态页面,动态页面)
  • Split databases based on concepts that don't need to be JOINed (logins, long term reporting, page data, etc.)
  • 根据不需要加入的概念拆分数据库(登录,长期报告,页面数据等)
  • Compile/optimize your PHP and other resources (sprites, compiled css, zend)
  • 编译/优化您的PHP和其他资源(sprite,编译的css,zend)
  • Add caching (front end, back end)
  • 添加缓存(前端,后端)
  • Add delegation (round robin, etc.)
  • 添加授权(循环等)

But, before scaling, measure. Set of tests, calculate your capacity, and don't optimize before you need to.

但是,在缩放之前,请测量。一组测试,计算您的容量,并在您需要之前不进行优化。

#3


2  

I see some questionable things:

我看到一些有问题的事情:

  • You have one SQL server, and you are storing sessions in a database on a site where you expect extremely high volume. How many queries does that take to produce a single page if someone is logged in and what is the expected slow down when you eventually employ MySQL replication?

    您有一个SQL服务器,并且您将会话存储在您期望极高容量的站点上的数据库中。如果有人登录,那么生成单个页面需要多少查询?当您最终使用MySQL复制时,预期的速度会减慢多少?

  • If using a cluster FS, everything is 'just kept' in sync. You won't end up with build A on webserver 1 while build B on webserver 2 breaks. If you are really expecting that much traffic, in the time it takes to upload a change, then sync all nodes, you just pissed off a thousand people.

    如果使用群集FS,一切都“保持”同步。当Web服务器2上的构建B中断时,您将不会在Web服务器1上建立构建A.如果你真的希望有那么多的流量,在上传更改所需的时间内,然后同步所有节点,你只会生气一千人。

I've deployed apps running on clusters using OCFS2 with over 40 nodes without issue, and OCFS2 is not exactly the 'best' cluster FS available. Check out Lustre and consider keeping sessions on disk.

我已经使用OCFS2部署了在集群上运行的应用程序,其中有40多个节点没有问题,而OCFS2并不是可用的“最佳”集群FS。查看Lustre并考虑将会话保留在磁盘上。

#4


0  

Remember you can mount/share folders.

记住你可以挂载/共享文件夹。

What data would you be syncing?

你会同步什么数据?

You might consider putting data on the database machine or other machine. The db machine is usually a good idea at first since it is likely to have greater IO than a regular web server.

您可以考虑将数据放在数据库计算机或其他计算机上。 db机通常是一个好主意,因为它可能比常规Web服务器具有更大的IO。

It is probably a good idea to setup a SAN or similar so your data stays in one place. Multiple copies of data is a pain to deal with. Going this route means you can put the db files there too.

设置SAN或类似设备可能是个好主意,因此您的数据可以放在一个地方。多个数据副本很难处理。走这条路线意味着您也可以将db文件放在那里。

#1


15  

According to Wikipedia, Switzerland has 4.6 million German speakers, 1.5 million French speakers, and .5 million speakers of Italian, Romansch and other languages. So I suspect you'll find that a single server will fit your needs. Guess what percentage of the population will visit your site every month or every day to get a sense of how big you can get before running into scaling issues.

据*称,瑞士有460万德语人士,150万法语人士和0.5百万意大利语,罗曼什语和其他语言。所以我怀疑你会发现一台服务器符合你的需求。猜猜每个月或每天会访问您网站的人口百分比,以了解在遇到扩展问题之前您可以获得多大的收益。

So, I don't think you need to worry about scaling yet! Bonus: The time you don't spend worrying about this problem, you can use to solve other problems for your users.

所以,我认为你还不用担心缩放!奖励:您不必担心此问题的时间,您可以用来为您的用户解决其他问题。

#2


8  

There are a few common paths to scaling web services up, in order of what sites like Flickr and Facebook seem to use:

根据Flickr和Facebook等网站似乎使用的顺序,有一些扩展Web服务的常用途径:

  • Split servers based on concepts (API, login, media files, ads, static pages, dynamic pages)
  • 根据概念拆分服务器(API,登录,媒体文件,广告,静态页面,动态页面)
  • Split databases based on concepts that don't need to be JOINed (logins, long term reporting, page data, etc.)
  • 根据不需要加入的概念拆分数据库(登录,长期报告,页面数据等)
  • Compile/optimize your PHP and other resources (sprites, compiled css, zend)
  • 编译/优化您的PHP和其他资源(sprite,编译的css,zend)
  • Add caching (front end, back end)
  • 添加缓存(前端,后端)
  • Add delegation (round robin, etc.)
  • 添加授权(循环等)

But, before scaling, measure. Set of tests, calculate your capacity, and don't optimize before you need to.

但是,在缩放之前,请测量。一组测试,计算您的容量,并在您需要之前不进行优化。

#3


2  

I see some questionable things:

我看到一些有问题的事情:

  • You have one SQL server, and you are storing sessions in a database on a site where you expect extremely high volume. How many queries does that take to produce a single page if someone is logged in and what is the expected slow down when you eventually employ MySQL replication?

    您有一个SQL服务器,并且您将会话存储在您期望极高容量的站点上的数据库中。如果有人登录,那么生成单个页面需要多少查询?当您最终使用MySQL复制时,预期的速度会减慢多少?

  • If using a cluster FS, everything is 'just kept' in sync. You won't end up with build A on webserver 1 while build B on webserver 2 breaks. If you are really expecting that much traffic, in the time it takes to upload a change, then sync all nodes, you just pissed off a thousand people.

    如果使用群集FS,一切都“保持”同步。当Web服务器2上的构建B中断时,您将不会在Web服务器1上建立构建A.如果你真的希望有那么多的流量,在上传更改所需的时间内,然后同步所有节点,你只会生气一千人。

I've deployed apps running on clusters using OCFS2 with over 40 nodes without issue, and OCFS2 is not exactly the 'best' cluster FS available. Check out Lustre and consider keeping sessions on disk.

我已经使用OCFS2部署了在集群上运行的应用程序,其中有40多个节点没有问题,而OCFS2并不是可用的“最佳”集群FS。查看Lustre并考虑将会话保留在磁盘上。

#4


0  

Remember you can mount/share folders.

记住你可以挂载/共享文件夹。

What data would you be syncing?

你会同步什么数据?

You might consider putting data on the database machine or other machine. The db machine is usually a good idea at first since it is likely to have greater IO than a regular web server.

您可以考虑将数据放在数据库计算机或其他计算机上。 db机通常是一个好主意,因为它可能比常规Web服务器具有更大的IO。

It is probably a good idea to setup a SAN or similar so your data stays in one place. Multiple copies of data is a pain to deal with. Going this route means you can put the db files there too.

设置SAN或类似设备可能是个好主意,因此您的数据可以放在一个地方。多个数据副本很难处理。走这条路线意味着您也可以将db文件放在那里。