只显示主题贴
gigix 写道pi1ot 写道gigix 写道聊天这个东西，真想做大规模的话，长连接是免不了的
反了吧，有限成本内，如果想做大的话，长连接应该是尽量避免的
p2p嘛
发贴的看描述是irc那样的群聊，是群p
- 进入论坛 Ruby 版
gigix 写道聊天这个东西，真想做大规模的话，长连接是免不了的
反了吧，有限成本内，如果想做大的话，长连接应该是尽量避免的
- 进入论坛 Ruby 版
searching 写道每个访客的平均动态请求如下：
每隔3秒获取最新的聊天记录；
每隔5秒提交自己的聊天内容；
每隔10秒获取在线的聊天用户列表；
也就是每秒每人0.63次动态请求
平均每个请求的执行的sql查询为调用4次，包括权限验证、非法验证等。
假如在线100人的话，每秒会有60多次的动态请求，200多次的数据库查询。
由于服务器有另外应用所以部署环境为windows2003，apache，mongrel，mysql，硬件为2.6g双核，2G内存。
不知这样的应用可否？另外linux和windwos部署性能差距有多大？
权限验证、非法验证没有必要每次都查数据库吧
- 进入论坛 Ruby 版
robertlyc 写道Readonly 写道dearwolf 写道
或许，真有那么一天，曾经的玩笑会成为现实："你才敏捷！你全家都敏捷！"
这个玩笑已经过时了，现在流行的是：“你才SNS！你全家都SNS！”
一年之后的流行语“你才云计算，你全家都云集算！”
好像现在web x.0都已经算史前词汇了。
- 进入论坛 海阔天空 版
ztka 写道这不是多线程那么简单的，如果你的下一句sql依赖这句sql，那么你如果不执行完这句就要出错的。
如果上一句sql update没有执行完毕，被操作的表自然会处于lock状态，下一句update中如果有依赖被操作表的数据，读取时也会被写操作阻塞直到上一句完成。 怎么会出错？
- 进入论坛 综合技术 版
ztka 写道mysql的replication读binlog的时候是一个一个执行的，当你一条执行没有完成，不会执行另外一条。
是，只是我很奇怪为什么没有实现成多线程更新，结合update锁表机制，多线程更新理应不会有数据歧义性问题。
mysql 5.1的RBR说明中提到“基于RBR，也给replication slave端多线程更新机制提供了基础”，可见他们也是想这么做的，只是出于什么原因没有实现。
这两天正在看5.0的repl代码，基本上只涉及到3个cpp文件，揣摩中。
- 进入论坛 综合技术 版
http://junior.vox.com/library/post/talk-9-the-future-of-mysql-replication.html
The Future of MySQL Replication
Jul 27, 2006 at 5:17 PM
2 comments
This talk is by Dr. Lars Thalmann regarding where MySQL replication is going.
First bit is about why and how replication works as it stands. People ...
- 进入论坛 综合技术 版
theone 写道引用这时一旦有个耗时update操作，尽管只涉及一个表，但是整个slave库的更新都会被阻塞住
如果仅仅是update单条或者几条记录，请你告诉我，为什么会耗时？
这是mysql replication slave端的实现模式，我认为可能是避免同时维护多个更新动作队列，降低复杂度，提高稳定性。再说一遍，这和mysql的update动作本身的执行模式无关。
耗时的update操作有很多，譬如alter table add index
- 进入论坛 综合技术 版
评论排行榜