你服务的站点有多少用户？
Ray Yu
连接供大家学习。
仅仅是调查文章，并非探听内幕。
bi xuan
最近看到很多问架构的帖子，我想问下，你们服务的网站有多少用户？你们的预计和实现的并发数是多少？你们一天的pv是多少？你们主服务多少台服务器？给
连接供大家学习。
仅仅是调查文章，并非探听内幕。
--
Ray Yu
On 12月28日, 下午9时42分, "bi xuan" <bix...@gmail.com> wrote:
> 我这边有个小频道每秒4W的request，我告诉你这个，你认为有多少意义？
> 2008/12/28 Ray Yu <coffeef...@gmail.com>
沈晓鹏
pi1ot
bi xuan
然后负载的评定标准是什么...比较乱了..
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
徐建红 Bixuan Xu
升东网络科技发展（上海）有限公司 运维中心
上海浦东新区张衡路180号3号楼5F 邮编 201204
Tel: +86(021)58815151-8046 Fax: +86(021)58815151-8335
MSN: jh...@hotmail.com
Email: xu...@mail.51.com
Visit us:http://www.51.com
Ray Yu
On 12月28日, 下午9时42分, "bi xuan" <bix...@gmail.com> wrote:
> 我这边有个小频道每秒4W的request，我告诉你这个，你认为有多少意义？
> 2008/12/28 Ray Yu <coffeef...@gmail.com>
IChocolateU
重点在后面。。。
chao lu
--
Terry Lu
Department of Service Science and Engineering
Peking University
M.P: 0086-134-886-90089
Email: luc...@pku.edu.cn
MSN Messenger: luch...@126.com
尤寒
bi xuan
案例1：
一个频道，特性如下：文件平均文件大小在10K左右，源数据1T左右，每秒请求4Wreq，根据这样特点的频道，大家来设计一下架构，请稍微详细点。比如：使用什么软件（具体到版本号），什么硬件（具体到什么型号的cpu，多大内存），什么操作系统（具体到版本号），请说明为什么要选择这些！
关于服务器负载，处理多少并发连接需要多少CPU资源，集群这些，有什么资料可以分享没，或者书？
--
pi1ot
On 12月29日, 下午9时46分, "bi xuan" <bix...@gmail.com> wrote:
> 这样吧，我们抛出一个案例来分析可能会比较好：
> 案例1：
> 一个频道，特性如下：文件平均文件大小在10K左右，源数据1T左右，每秒请求4Wreq，根据这样特点的频道，大家来设计一下架构，请稍微详细点。比如：使用 什么软件（具体到版本号），什么硬件（具体到什么型号的cpu，多大内存），什么操作系统（具体到版本号），请说明为什么要选择这些！
>
> 2008/12/29 尤寒 <coldl...@gmail.com>
bi xuan
pi1ot
On 12月29日, 下午9时57分, "bi xuan" <bix...@gmail.com> wrote:
> 这个就是你要考虑的问题了！
>
> 2008/12/29 pi1ot <pilot...@gmail.com>
bi xuan
更新：每天大概200W个文件更新，同名覆盖！
读取：（其实自己可以算了）
pi1ot
最简单的做法是找10台内存8G~16G的pc服务器用memcached拼出一个内存池，用文件名hash作key，每次文件更新时主动更新
mecached，或者文件更新只删除memcached中的数据，下次读取动作再被动触发cache动作，这取决于一个刚被更新的文件会有多大概率会
接下来被请求到。
另外如果这200W个文件的更新时间集中在一天的某个时段的话，必须要考虑一次集中更新是否会导致cache系统的恶性循环颠簸，具体问题具体解决。
剩下的焦点就是实现一个能处理4w/s的前端分派server，这方面我不是很在行，不发表意见。
你也看到了，大量的假设和前提，所以我说一个充分优化和适用的系统都是在完成详细需求分析前提下才能做到的。
On 12月29日, 下午10时15分, "bi xuan" <bix...@gmail.com> wrote:
> 那我补充一下：
> 更新：每天大概200W个文件更新，同名覆盖！
> 读取：（其实自己可以算了）
>
> 2008/12/29 pi1ot <pilot...@gmail.com>
pi1ot
这么多文件是肯定不能直接放fs上的，如果只有有限的服务器资源，无论怎么hash分散，文件系统都会死掉。
bi xuan
其实很多实际情况下，你完全不知道压力，更多的时候靠经验。
pi1ot
On 12月29日, 下午10时55分, "bi xuan" <bix...@gmail.com> wrote:
> 静态文件存在内存吗？如果机器宕机了怎么办？如何保证数据安全？
> 其实很多实际情况下，你完全不知道压力，更多的时候靠经验。
>
> 2008/12/29 pi1ot <pilot...@gmail.com>
pi1ot
交易系统和wiki/bbs系统的设计目标和实现方法完全不同，自然花费的成本和实现的效果也不一样。
最最happy的情况下，成本不限，每台mecached配2个实时更新的跨机房backup，来上1000台，啥也不说了，不过也只能在梦里。
On 12月29日, 下午10时55分, "bi xuan" <bix...@gmail.com> wrote:
> 静态文件存在内存吗？如果机器宕机了怎么办？如何保证数据安全？
> 其实很多实际情况下，你完全不知道压力，更多的时候靠经验。
>
> 2008/12/29 pi1ot <pilot...@gmail.com>
Jeffrey Zhao
Jeffrey Zhao
--------------------------------------------------
From: "pi1ot" <pilo...@gmail.com>
Sent: Monday, December 29, 2008 10:47 PM
To: "TopLanguage" <pon...@googlegroups.com>
Subject: [TopLanguage] Re: 你服务的站点有多少用户？
pi1ot
所以大家都在做假设，无非你我都各自假设了一个自己熟悉的语境而已，这个命题没有继续深入讨论的必要
On 12月29日, 下午11时38分, "Jeffrey Zhao" <je...@live.com> wrote:
> memcached主要用于后台使用编程的交互，看这说法更像是纯静态文件的host，那么一个典型的做法是前端做负载均衡到缓存服务器（例如经典的Squid ，现在好像Varnish有点慢慢替代Squid的样子）集群，使用一个合适的负载均衡策略（例如一个合适的hash函数）可以保证缓存的一定命中率，后端即是 FS或MogileFS这种"所谓的"分布式FS（没有贬义，MogileFS可是好东西）。至于负载均衡方案的选择，从数据上看尚在Nginx的承受范围内。
>
> Jeffrey Zhao
>
> --------------------------------------------------
> From: "pi1ot" <pilot...@gmail.com>
bi xuan
用mogilefs可能是不错的，但是多了db层的开销，比较浪费！
pi1ot
更新用户头像时他的好友是3分钟还是5分钟后看到更新消息也不重要，实时性要求也不高。
如果是客户端产品的话自己就能根据好友id算出其头像的hash分布节点，连前端那个分派服务都不需要了。
总结来说方案可以有很多，只要硬件资源不太拮据就不是什么问题。
On 12月30日, 下午4时02分, "bi xuan" <bix...@gmail.com> wrote:
> 简单的说吧，这个就是用户头像，刚才也说了，这个是静态文件，用memcache显然不可以。
> 用mogilefs可能是不错的，但是多了db层的开销，比较浪费！
>
> 2008/12/30 pi1ot <pilot...@gmail.com>
Davies Liu
Best regards,
Davies Liu
Hongzhang Liu
2008/12/30 Davies Liu <davie...@gmail.com>:
> 继续讨论，不对之处欢迎指正。
> 每秒钟4W请求的话，假设每个连接存活时间是10秒(网速慢，或者keepalived的因素导致)，则总体并发数是40W， 400k。
> 一台Linux服务器的本地端口数约是60k，至少需要7台前端Web服务器。
> LVS似乎不能处理超过60k的并发连接吧？那就需要采用至少7个域名，或者一个域名随机解析到7个IP上。
> 每个Web服务器都是同构的，每个处理约40k*10k/7（不到500MB）的流量。它其实是七层负载均衡器，根据URL的哈希将请求传递到后端的缓存服务器上(可以跟前端的Web服务器公用)。
> 假设这些请求的热点很好，95%的请求集中在5%的内容上。那么需要至少50G内存做缓存，每秒仍然要从硬盘读取2k个文件。一个普通SATA硬盘每秒钟能随机读100个小文件的话，需要约20个硬盘。系统缓存和memcached本身的效率会低于理想状况，100G内存会更合适。
> 那么10台16G内存2个500G
> SATA盘的集群，使用10个独立的IP进行轮询，每个上面用Nginx+mod_hash模块根据URL进行分配，后端用varnish(malloc,
> 10G), 最后是分布式存储系统，也是基于HASH规则，存储节点可以用WebDAV。
>
> Best regards,
> Davies Liu
>
> 2008/12/29 pi1ot <pilo...@gmail.com>
lxcypp
继续讨论，不对之处欢迎指正。每秒钟4W请求的话，假设每个连接存活时间是10秒(网速慢，或者keepalived的因素导致)，则总体并发数是40W， 400k。一台Linux服务器的本地端口数约是60k，至少需要7台前端Web服务器。
头像文件都很小，应该不需要10秒的连接存活时间，另外，如果采用UDP的协议就没有端口数限制。
LVS似乎不能处理超过60k的并发连接吧？那就需要采用至少7个域名，或者一个域名随机解析到7个IP上。每个Web服务器都是同构的，每个处理约40k*10k/7（不到500MB）的流量。它其实是七层负载均衡器，根据URL的哈希将请求传递到后端的缓存服务器上(可以跟前端的Web服务器公用)。假设这些请求的热点很好，95%的请求集中在5%的内容上。那么需要至少50G内存做缓存，每秒仍然要从硬盘读取2k个文件。一个普通SATA硬盘每秒钟能随机读100个小文件的话，需要约20个硬盘。系统缓存和memcached本身的效率会低于理想状况，100G内存会更合适。
如果有50G的热点内容，那么可以考虑使用SSD了，相对来说成本比较低了。
Hongzhang Liu
2008/12/30 lxcypp <lxc...@gmail.com>:
lxcypp
UDP不存在每个连接占用1个端口的问题。
Davies Liu
LS
有些问题没有一个感性的认识总是感觉不可捉摸
Hongzhang Liu
2008/12/30 lxcypp <lxc...@gmail.com>:
尤寒
闫永刚
给我一份，谢谢 |
|
|
Tiny fool
chao lu
--
Terry Lu
Department of Service Science and Engineering
Peking University
M.P: 0086-134-886-90089
Email: luc...@pku.edu.cn
MSN Messenger: luch...@126.com