[性能] 个人观点，谈谈提高论坛性能的问题

spiceboy

awstats.www.****.com.conf中：
NotPageList="css js class gif jpg jpeg png bmp ico swf xml rdf cgi mp3 pl wmv"

结果
14 Jan 2006        49113        2491544           9022369        34.72 GB

访问集中在下午1:00-5:00
请大家帮我估计一下那天最高有多少人在线吧。

[ 本帖最后由 spiceboy 于 2006-1-18 14:04 编辑 ]

geel

估算一下
1、带宽
2、平均建立一个tcp连接要耗费的资源（繁忙时期的慢速连接比较闹心）
3、连接之后的处理
a) 程序解析执行速度？
b) 程序本身产生的IO压力？
c) 程序的内存压力？
d) 连接数据库所需要的资源消耗
e) 数据库产生的资源消耗包括cpu和IO？

很多方面综合考虑的，很难说什么什么能承受多大压力之类，应用情况不一样，如何有效减少瓶颈，平衡资源利用才是需要考虑的，如果该做的都做了还没法提高负载，那就升级硬件吧

北京野狼

原帖由 spiceboy 于 2006-1-18 14:02 发表
awstats.www.****.com.conf中：
NotPageList="css js class gif jpg jpeg png bmp ico swf xml rdf cgi mp3 pl wmv"

结果
14 Jan 2006        49113        2491544           9022369        34.72 GB

访问集中在下午1:00- ...

兄弟你是否真的理解什么叫做 pageview ,
css js class gif jpg jpeg png bmp这些和pv毫无关系。

常常我也反思我是否真的了解我身边的事物，无论好恶。就象你曾经非常愤愤不满
的和我讨论gmail问题一样，你是否真的了解邮件系统。
——我没特别意思，人人都应该认识自我

spiceboy

原帖由 北京野狼 于 2006-1-19 12:40 发表



兄弟你是否真的理解什么叫做 pageview ,
css js class gif jpg jpeg png bmp这些和pv毫无关系。

常常我也反思我是否真的了解我身边的事物，无论好恶。就象你曾经非常愤愤不满
的和我讨论gmail问题一样 ...

别激动。
那个变量是NotPageList
不是PageList
awstats软件的一个配置。
什么叫PV，我做了几年程序员和网管，稍微懂一点。

spiceboy

另外，邮件系统我真的不怎么懂，只安装配置过邮件服务器，二度开发了igenus的webmail，改造过qmail的源代码，这还只限于qmail+vpopmail的。

sendmail，postfix的源代码都没有读过。

现眼了我。

北京野狼

原帖由 spiceboy 于 2006-1-19 18:06 发表
另外，邮件系统我真的不怎么懂，只安装配置过邮件服务器，二度开发了igenus的webmail，改造过qmail的源代码，这还只限于qmail+vpopmail的。

sendmail，postfix的源代码都没有读过。

现眼了我。

有这样的经验，我就更无法理解你那些话了。

hotmail的机制和传统mail有什么不同吗？
gmail又有何不同？
gmail是先推出web信箱再推出pop3的。
你开发的邮箱，没有pop3和smtp，能收发信吗

到底有什么不同吗？

wangyih

老狼就是喜欢计较这个，以前在c语言版，和无数的人吵的不可开交

休息吧。

qingmedia

没有偏执狂的精神，成不了优秀的程序员。
不过

北京野狼

程序员也只是人的一个基本的工作而已,干吗非偏执狂.

搞IT的总喜欢把技术神圣化,看看无聊的google,linux的崇拜狂,

记住自己干的仅仅是一份普通的工作,和所有的老苦大众一样,没什么特别的.

BTW:人在郑州,希望能平安回北京

[ 本帖最后由 北京野狼 于 2006-1-21 16:30 编辑 ]

toplee

呵呵，很久没来，没想居然有这么多回复了！

我曾经在yahoo&3721工作，日常工作负责实名引擎左右帧的一些开发工作，mop也待过，具体的情况很清楚，在我手里mop的dzh经历过一次大规模的程序和架构性能改造升级，大家讨论来讨论去开始争论并发这个话题了，和我当初的初衷有些不一致，这篇文章是我当初还没有进3721工作时非典前夕写的，但是有些东西我现在看来还是很浅显的，其实有个比较简单的计算QPS的方法，不知道大家是否同意。

首选你先得到您的服务器每日或者某个时段的PV值，然后利用PV除以总的秒数，就可以知道某一秒内的同时并发数QPS，这个基本上比较准确，当然，峰值并发（就是访问高峰时候的并发），我们一般认为应该是全天平均值的1.6倍左右，比如全天平均QPS=300，那么峰值的QPS大致该500左右，也就是说我们设计系统的时候，如果设计支持每日PV3000万，那么平均QPS＝3000万/96400=347 左右，等于平均每秒的并发为347左右，峰值我们应该支持到555左右，那么设计系统的时候就要至少支持600的QPS才能保证系统在访问高峰的时候不会产生雪崩或者性能下降。这个最典型的应用就是我当初负责的3721地址栏实名引擎左右帧搜索，当时大致就是3000万左右的pv，我们的服务器（自攒的普通1U）经过测试一台基本能满足峰值QPS不到100，所以最后有10多台服务器来提供实名搜索服务，保证了系统有一定的冗余和一段时间内的业务增长支持。

[ 本帖最后由 toplee 于 2006-2-8 23:14 编辑 ]