当前位置:   article > 正文

.NET应用访问数据库之数据库的开销问题 后续篇(二)通信量和通信次数的较量...

通信次数 每次通信数据量

 

  通信量是说一次通信传输的数据量,可以使用KB或者MB来衡量的量。通信次数是说一次打开数据库,执行数据库操作,然后返回数据(或者没有返回),算作一次通信。

  今天就这个问题在MSN中和几个人进行了交流,一个是MVP,一个是在群里,一个是和一位数据库方面的高手。具体内容如下:

  和MVP的交流内容,将MVP的姓名替换了。

  

ExpandedBlockStart.gif 代码
<!--<br/ /><br/ />Code highlighting produced by Actipro CodeHighlighter (freeware)<br/ />http://www.CodeHighlighter.com/<br/ /><br/ />--> 查看与此联系人的全部对话记录
  
MVP 说:
你看看对象定义应该就清楚了吧
 jorden008@hotmail.com 说:
用reflector
有这么个问题,通信量和通信次数,那个更重要呢?是一次通信的量大点,减少通信次数,
 还是每次通信量小点,通信次数多点没有关系呢
 来如何权衡呢
  
加密助手 说:
 
---  系统提示: 以下会话未被加密  ---
MVP 说:
 都重要
 一般远呈调用
 推荐做法是 少次数,多数据
 当然,这个数据量也不能太大
 jorden008@hotmail.com 说:
 远程调用是什么概念呢
MVP 说:
 不同机器
 不同进程
 jorden008@hotmail.com 说:
 我现在是一个互联网应用
 是不是就可以理解为远程调用呢?内网是不是不算远程调用了呢?
MVP 说:
 不是
 互联网应用时浏览器和服务器之间的调用
 远程调用
----- 服务器之间的,ok?
 jorden008@hotmail.com 说:
 C
/ S算不算远程调用呢
MVP 说:
 算
 jorden008@hotmail.com 说:
 那就是了,我现在是silverlight
+ wcf,一种在浏览器中运行的C / S
MVP 说:
 恩,算是吧
 jorden008@hotmail.com 说:
 B
/ S都是服务器在工作,在client端都是html
MVP 说:
 对的
 jorden008@hotmail.com 说:
 好的,谢谢建议兄
 具体这个量有没有什么大概的数值呢
 现在用httpwatch看的话,有100K之多
MVP 说:
 100K算正常吧
 jorden008@hotmail.com 说:
 大概多少算作上线呢
MVP 说:
 一般通讯量都算猪呢工程
 不知道
 凭经验
 jorden008@hotmail.com 说:
 猪??
 猪呢工程??

MVP 说:
 一般1M一下都算正常 吧
 jorden008@hotmail.com 说:
 主要是怕用户体验不好,响应的慢,好的谢谢
 还有就是互联网应用的数据库调用失败率大概多少呢
MVP 说:
 没这种说法吧
 jorden008@hotmail.com 说:
 因为有的时候本来可以在一个存储过程中搞一个事务的,但是担心失败,有一个是必须的,一个不是必须的,就想是不是应该分开了,不必须的失败了就算了,这样就造成了两次通信
 有的时候可以写一个存储过程,然后里面写上三个sql,一个事务搞定,但是怕失败,不敢了,就只要写三个存储过程,分三次调用
MVP 说:
 数据库?
 jorden008@hotmail.com 说:
 是的
MVP 说:
 三个存储过程也可以一个事物啊
 jorden008@hotmail.com 说:
 还是怕失败啊
MVP 说:
 事物失败不是正常的吗?
 不失败要事物干吗?
 jorden008@hotmail.com 说:
 原来一个事务怕失败,就搞成三个失误了
 我就是说这种失败的几率有多少呢
MVP 说:
 三个就不失败了?
 靠
 没这种说法吧
 jorden008@hotmail.com 说:
 这么说吧,第一个失败了,是业务不允许的,失败了就是要报错,客户要重新点击,但是第二个是记录日志,如果失败了,可以允许,客户就不用管的,只是给系统来用的
 但是这两个放在一个事务,是不是不好呢?
MVP 说:
 不好
 日志记录放在事物之外
 jorden008@hotmail.com 说:
 还有就是一些其他的,例如有一个表维护用户的最后通信时间,用来做超时自动下线的
 用户每次进行业务操作的时候,都会更新这张表 
 就说业务操作和更新在线用户表是不是该放在一个事务呢
MVP 说:
 这个也可以事物之外
 jorden008@hotmail.com 说:
 事务之外就变成两次通信了
MVP 说:
 不是
 你不是C
/ S
 吗?
 C
/ S要避免client和server的多次通讯
 jorden008@hotmail.com 说:
 C
/ S就不是两次通信了吗
MVP 说:
 server 和db之间该怎么干就怎么干
 你不是在sliverlight中调ado吧?
 jorden008@hotmail.com 说:
 server是说application server吧
MVP 说:
 yes
 jorden008@hotmail.com 说:
 silveright也不让我调用ado啊
MVP 说:
 恩
 jorden008@hotmail.com 说:
 silveright不能直接连接数据库,只能通过服务,例如webservice、wcf这些东西
MVP 说:
 server和db的多次通讯不是用一个connection?
 clinet
- server 通讯次数要少
 jorden008@hotmail.com 说:
 server和db的多次通信应该不是一个吧
MVP 说:
 server
- db通讯次数要少
 但是,有时候性能跟功能是不可兼得的
 向你的场景,显然要用三次数据库通讯
 jorden008@hotmail.com 说:
 通信次数还是应该优先的,要少,就是在通信量允许的情况下,尽量减少通信次数,是不是可以这么理解呢
MVP 说:
 恩
 在功能允许的情况下,尽量减少通讯次数
 一般的业务,数据量问题可以忽略的,除非是一次加载大量数据的场景
 jorden008@hotmail.com 说:
 就想你说的1M应该可以算作正常
MVP 说:
 看什么场景
 没有绝对的标准
 jorden008@hotmail.com 说:
 视情况而定

 

  在群中的交流信息

  

ExpandedBlockStart.gif 代码
<!--<br/ /><br/ />Code highlighting produced by Actipro CodeHighlighter (freeware)<br/ />http://www.CodeHighlighter.com/<br/ /><br/ />--> 查看与此联系人的全部对话记录
  
  
 jorden008@hotmail.com 说:
 有这么个问题,通信量和通信次数,那个更重要呢?是一次通信的量大点,减少通信次数,
 还是每次通信量小点,通信次数多点没有关系呢
 来如何权衡呢

用户1 说:
 你的通信量大是不是说每次交互的时间很长啊
 要不然这两个应该是同一个概念啊
 jorden008@hotmail.com 说:
 不是的,是交互的数据量大,怕传输时间长,响应慢,显示就慢
 怎么会是一个概念呢
 一个是每次10M,就两次通信
 一个是每次1M,需要通信20词
加密助手 说:
 
---  系统提示: 以下会话未被加密  ---
用户1 说:
 那就一次10M啦,这样应该会比每次1M的快吧
 jorden008@hotmail.com 说:
 10M这个量如何控制呢,也许5M更合适吧,就是个问题
加密助手 说:
 
---  系统提示: 以下会话未被加密  ---
用户1 说:
 这个,没有太过经验.....
 呵呵
Mog 说:
 是数据传输粒度问题吧。我觉得小一点好,够客户端一次显示用就行了
 粒度大的话,我想会不会出现某时刻并发量过大,造成阻塞
 jorden008@hotmail.com 说:
 粒度小才会并发过大吧
 粒度小导致通信量增大,并发的几率就大了
用户1 说:
 这个可以采用一种折中的数据量啊
Mog 说:
 粒度大的话,处理时间长。
 jorden008@hotmail.com 说:
 对
 就是那个更优先一点
Mog 说:
 我想设计时把粒度控制设为可配置吧,根据以后运行环境来调整
Gary.Chen 说:
 Yo
 Yo Yo Yo
 jorden008@hotmail.com 说:
 不是什么都可以做成配置的
Gary.Chen 说:
 jorden哥
 jorden008@hotmail.com 说:
 我这个又不是硬件,做流量控制的
 这个是方法调用,然后传输实体类,如何配置呢
 what GaryChan
Gary.Chen 说:
 你在说什么
? 分享一下
 jorden008@hotmail.com 说:
  有这么个问题,通信量和通信次数,那个更重要呢?是一次通信的量大点,减少通信次数,
 还是每次通信量小点,通信次数多点没有关系呢
 来如何权衡呢

Gary.Chen 说:
 看你应用场合了
 我碰到跟你一样的问题
 我昨天跟PM讨论过,采取了频繁请求来做
 但是我害怕频繁请求会导致通道故障,宿主会不会废掉
 我个人建议的做法是少量通信次数
+ 分段获取数据
 你可以用分段字节流来获取
 我这里有个demo,上次发过了
 Fred Xu.DBSC 说:
 demo在哪里可以下载
Gary.Chen 说:
 我上次发给过你们吧
 Fred Xu.DBSC 说:
 重发一下吧
Gary.Chen 说:
 ......
 这个是针对大数据量传输的解决方案
 jorden008@hotmail.com 说:
 哦
 请给我一个吧
 谢谢了
Gary.Chen 说:
 要的人发EMAIL
 Fred Xu.DBSC 说:
 fred_xu666@hotmail.com
 jorden008@hotmail.com 说:
 是不是那个拆解为byte【】,然后在客户端组合的办法呢
Gary.Chen 说:
 对


 

  和数据库开发方面的高手的交流内容

  

ExpandedBlockStart.gif 代码
<!--<br/ /><br/ />Code highlighting produced by Actipro CodeHighlighter (freeware)<br/ />http://www.CodeHighlighter.com/<br/ /><br/ />--> 查看与此联系人的全部对话记录
  
数据库开发高手 说:
现在硬件完全能应付的来
 jorden008@hotmail.com 说:
好吧,谢谢了,回头交流
数据库开发高手 说:
好的。
8
  
 jorden008@hotmail.com 说:
 有这么个问题,通信量和通信次数,那个更重要呢?是一次通信的量大点,减少通信次数,
 还是每次通信量小点,通信次数多点没有关系呢
 来如何权衡呢
加密助手 说:
 
---  系统提示: 以下会话未被加密  ---
数据库开发高手 说:
 这个都跟网络有关系吧

 感觉应该是量大点 

 jorden008@hotmail.com 说:
 因为是互联网应用,网络就是平均水平算
lye2000000_super@hotmail.com 说(
10 : 46 ):
 通信次数还要等待的

 jorden008@hotmail.com 说:
 通信次数要等待是什么意思
加密助手 说:
 
---  系统提示: 以下会话未被加密  ---
数据库开发高手 说:
 每次连接可能会等待啊

 jorden008@hotmail.com 说:
 哦,那就是说两者可以量优先,在量允许的范围内,尽量减少通信次数
数据库开发高手 说:
 对 

 jorden008@hotmail.com 说:
  还有就是互联网应用的数据库调用失败率大概多少呢
 因为有的时候本来可以在一个存储过程中搞一个事务的,但是担心失败,有一个是必须的,一个不是必须的,就想是不是应该分开了,不必须的失败了就算了,这样就造成了两次通信
加密助手 说:
 
---  系统提示: 以下会话未被加密  ---
数据库开发高手 说:
 提交到服务器了。怎么会出现你说 情况呢?

 jorden008@hotmail.com 说:
 有的时候可以写一个存储过程,然后里面写上三个sql,一个事务搞定,但是怕失败,不敢了,就只要写三个存储过程,分三次调用
数据库开发高手 说:
 呵呵呵。怎么会这样呢?调要了存储过程了。那么就会一起执行。都是在数据里执行
 貌似这个是理解错了吧
 分三次出错 几率不是更大?

 jorden008@hotmail.com 说:
 这么说吧,第一个失败了,是业务不允许的,失败了就是要报错,客户要重新点击,但是第二个是记录日志,如果失败了,可以允许,客户就不用管的,只是给系统来用的
 但是这两个放在一个事务,是不是不好呢?

 还有就是一些其他的,例如有一个表维护用户的最后通信时间,用来做超时自动下线的
 用户每次进行业务操作的时候,都会更新这张表 
 就说业务操作和更新在线用户表是不是该放在一个事务呢

数据库开发高手 说:
 都放在存储过程里不就行了吗?

 提交之后都在服务器运行

 你说 这种状况很难出现吧

 运行着就出问题了。挺难出现 

 那样第一个存储过程也会出这种事情 
 jorden008@hotmail.com 说:
 所以我问题你存储过程出错的几率有多大呢?
数据库开发高手 说:
 呵呵。不会太大

 比网络出错 几率要小
 jorden008@hotmail.com 说:
 那就是小很多恶劣
数据库开发高手 说:
 是啊。
 如果要求不严格。那就分开。这个对整体影响不大 
 jorden008@hotmail.com 说:
 恩

 

 

  结论

  通信次数还是应该优先考虑的,要少,但是要在通信量允许的情况下,尽量减少通信次数,通信量1M应该还算正常。这个也要考虑网络环境等外界因素。

本文内容由网友自发贡献,转载请注明出处:【wpsshop博客】
推荐阅读
相关标签
  

闽ICP备14008679号