g***p
发帖数: 139 | 1 3G ram， linux os， dual core
everyone has a session. 或者推荐一下什么样的机器和带宽能抗住。
tkx |
c**t
发帖数: 2744 | 2 server is ok;you need dedicated bandwidth
【在 g***p 的大作中提到】
: 3G ram， linux os， dual core
: everyone has a session. 或者推荐一下什么样的机器和带宽能抗住。
: tkx
|
n****m
发帖数: 18 | 3 depend on what kind of the application the users require |
r*********i
发帖数: 32 | |
c***c
发帖数: 21374 | 5 你自己算算即可
看看你的每个session要写多少kb的内容，乘一下
再把机器本身程序，OS，web，db等等加一下
【在 g***p 的大作中提到】
: 3G ram， linux os， dual core
: everyone has a session. 或者推荐一下什么样的机器和带宽能抗住。
: tkx
|
l*******9
发帖数: 177 | 6 session里面会装什么大东西？：）我觉得最耗的是
和 DB 的interactions，后台程序计算生成网页的效率
和Server自己的硬件设备如网络带宽...
【在 c***c 的大作中提到】
: 你自己算算即可
: 看看你的每个session要写多少kb的内容，乘一下
: 再把机器本身程序，OS，web，db等等加一下
|
c***c
发帖数: 21374 | 7 每次DB操作都直接对DB操作显然是很差的设计
持久数据库对象，SQL缓存，等等，这些在大规模并发的时候都是要考虑的
此外SQL自身的优化也很重要
【在 l*******9 的大作中提到】
: session里面会装什么大东西？：）我觉得最耗的是
: 和 DB 的interactions，后台程序计算生成网页的效率
: 和Server自己的硬件设备如网络带宽...
|
l*******9
发帖数: 177 | 8 cache当然是很重要的，但是对于很多随时更新的东西
不即时 interact DB 是不行的。我说的DB连接一般比较耗时
所以是应考虑优化的重点，不是要OP每个HTTP request都建
个新的 db handler 或读写操作。。。 ：）
【在 c***c 的大作中提到】
: 每次DB操作都直接对DB操作显然是很差的设计
: 持久数据库对象，SQL缓存，等等，这些在大规模并发的时候都是要考虑的
: 此外SQL自身的优化也很重要
|
|
