论坛首页 综合技术论坛

如此部署!? 征集点信心 or 判个死刑

浏览 23868 次
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2009-01-18  
是要在服务器上安装LoadRunner测试么?(为什么会涉及64位系统安装LoadRunner的问题)
只要在你自己的电脑上安装上loadrunner,跟服务器直连(这样网络延迟方面的影响就很小了),这样测就可以了。
0 请登录后投票
   发表时间:2009-01-18  
装东西是要有许可的。这个很麻烦。
不过晚上同事在家跑了一下。500并且去操作我们的日常业务。服务器都不卡~~~~
之前在内网有试过是会很卡。
怀疑loadrunner版本有问题,角本没录对。

额额……有空再去处理这些好了。烦哪。
神经病一样,哎。快受不了了。
0 请登录后投票
   发表时间:2009-01-19  
逻辑场景疑问一:

如果用户访问B地主机,并新增业务,熟料刚新增完,B地地震(或其他灾害),但是用户新增的业务刚入库,还没有同步到A地主机。

用户无奈转而访问A地主机,发现先前新增的数据看不到,于是又新增了相同的业务,按楼主的策略,B地主机恢复后,两地一同步,是否会出现两条一模一样的业务数据呢?
0 请登录后投票
   发表时间:2009-01-19  
icewubin 写道
这其实是就是把复杂度转嫁到开发中去了,原本不需要考虑这些问题的,但是因为愚蠢的BOSS搞出来的方案,导致系统的业务从设计到编码到测试都得考虑数据同步的可行性,你可以说业务天生就是如此,但是这“天生就是如此”这个结果就是要通过耗费人工评估得出的结果,这些无谓的成本大多是隐含的。

再有,很多人的想法是,同等成本(人力、物力)下,肯定有更好的整体方案,这是前提。
而楼主的大前提是BOSS下了命令,必须要那么整。
所以你的“未尝不可”基于哪个前提呢?


恕我直言,开发者觉得其他人(比如用户、销售、甚至搭档,当然也包括老板)愚蠢是很大的毛病!

其实从业务设计到编码测试本来就要考虑数据同步的可行性,只是技术人员有了一些现成的工具可用而已,系统设计就那几板斧,OO的结果就是大量的框架、模式、结构可以套用,过惯了衣来伸手、饭来张口的懒日子,就觉得永远不用考虑煮饭了。成本不是技术人员应该考虑的东西,这么说的技术人员只是怕麻烦而已。不得不提醒的是,怕麻烦,就没有机会吃更好的,就这么简单,成功不是随便来的。

我说“未尝不可”的前提是,这是一个新思路,LZ如果能证明这个方案可以成功,就做到了别人做不到的事情。你能做到别人做不到,或者你能先于别人做到,换句话说,就是竞争力!竞争力不用解释吧?吃的好些不难理解吧?何蠢之有?

觉得这个BOSS蠢的人,是否问过当年YAHOO和GOOLE创始人是否也蠢?当年Gates,Jobs哪个不蠢?
0 请登录后投票
   发表时间:2009-01-19  
eyeqq 写道

但问题就是,我们是小区宽带,两条宽带都是从一个小区的大路由?/集线器?接进来了,那样这样的话跟我之前测试的走我们自己路由的感觉没什么差别。并我们这这一片区的电信服务器就在距离我们机房300多米的地方(宽带小伙跟我们讲的)...-_-!相对来讲,这样的测试还是不能够说明真实的生产环境的效果的。等两天机器在客户那边架起来了再来看最终的结果吧~~~


不了解你的宽带设备是什么,两台MODEM?还是直接是RJ45头直用根网线就能跑?
有没有测过两台机之间真实可用带宽是多少?PING值是多少?
如果能够验证带宽确实只有2M的话,那么现阶段至少可以获得结论:这个方案在指标充足、性能稳定的小区宽带线路上可用,具体性能要拿到A、B地链路性能实测数据之后才可以验证。
网络性能有两个指标,一个是带宽,一个是响应(各种尺寸数据包的ping值),前一个决定最大数据流量,下一个决定响应速度。

这个方案还是有风险,做为技术人员必须把握的是要充分预计风险,如实向BOSS表达进展情况以及风险,不要夸口,这样才不会把自己弄的很难受。
0 请登录后投票
   发表时间:2009-01-19  
icewubin 写道
逻辑场景疑问一:

如果用户访问B地主机,并新增业务,熟料刚新增完,B地地震(或其他灾害),但是用户新增的业务刚入库,还没有同步到A地主机。

用户无奈转而访问A地主机,发现先前新增的数据看不到,于是又新增了相同的业务,按楼主的策略,B地主机恢复后,两地一同步,是否会出现两条一模一样的业务数据呢?


在发生灾难的时候,应该在双向热备中做选择一个(例如A)做主,抛弃其中一方(B),通告用户复核特定时间段(如12小时内)的所有业务并补录。恢复时直接通过A->B方式重建B,之后启动双向。
0 请登录后投票
   发表时间:2009-01-19   最后修改:2009-01-19
cocal 写道

恕我直言,开发者觉得其他人(比如用户、销售、甚至搭档,当然也包括老板)愚蠢是很大的毛病!

其实从业务设计到编码测试本来就要考虑数据同步的可行性,只是技术人员有了一些现成的工具可用而已,系统设计就那几板斧,OO的结果就是大量的框架、模式、结构可以套用,过惯了衣来伸手、饭来张口的懒日子,就觉得永远不用考虑煮饭了。成本不是技术人员应该考虑的东西,这么说的技术人员只是怕麻烦而已。不得不提醒的是,怕麻烦,就没有机会吃更好的,就这么简单,成功不是随便来的。

我说“未尝不可”的前提是,这是一个新思路,LZ如果能证明这个方案可以成功,就做到了别人做不到的事情。你能做到别人做不到,或者你能先于别人做到,换句话说,就是竞争力!竞争力不用解释吧?吃的好些不难理解吧?何蠢之有?

觉得这个BOSS蠢的人,是否问过当年YAHOO和GOOLE创始人是否也蠢?当年Gates,Jobs哪个不蠢?

1.愚蠢不愚蠢,这个就不深入了,大家都知道,yahoo和google是不是大家都认为愚蠢自有公论。退一步说,即使boss剥削员工,如果方案和设计的好,员工还是会说好的,即使应该3个人做的事情,压倒一个人身上,也不能否认方案本或设计本身就是好的。

2.我说的愚蠢还包含一层意思就是,楼主的BOSS表面上认为这样做能节省硬件成本,但是间接的是浪费公司的人工。当然BOSS可能知道这点,硬件成本相对是固定的,人工么,可以压榨剥削的啊。

3.愚蠢主要还包括方法论上的问题,低带宽下的实验调研还没有做,就开始实施方案,有这么实施项目的么?
0 请登录后投票
   发表时间:2009-01-19   最后修改:2009-01-19
楼主有条件的话,用蓝牙就能测试了,两台机器用蓝牙对联。

蓝牙理论1Mbps带宽,加上一些无线传输的损耗,差不多就可以模拟512Kbps的真实情况了。
0 请登录后投票
   发表时间:2009-01-20  
icewubin 写道

1.愚蠢不愚蠢,这个就不深入了,大家都知道,yahoo和google是不是大家都认为愚蠢自有公论。退一步说,即使boss剥削员工,如果方案和设计的好,员工还是会说好的,即使应该3个人做的事情,压倒一个人身上,也不能否认方案本或设计本身就是好的。

2.我说的愚蠢还包含一层意思就是,楼主的BOSS表面上认为这样做能节省硬件成本,但是间接的是浪费公司的人工。当然BOSS可能知道这点,硬件成本相对是固定的,人工么,可以压榨剥削的啊。

3.愚蠢主要还包括方法论上的问题,低带宽下的实验调研还没有做,就开始实施方案,有这么实施项目的么?


怎么聊到人际关系上去了,再说下去有些跑题了,哈哈。
最后再说几句,如果觉得和老板合不来,找机会换个老板试试,如果换来换取都遇不到好老板,那你绝对是个做老板的材料,创业吧...
(其实哪个老板不是从工仔做起来的?也许等到你当了老板,才会发现原来事情不是那样,但不做老板,又如何能知老板之苦呢?)

给LZ和各位讨论的朋友拜个年吧,祝大家工作开心,新春大吉,牛年牛气冲天
0 请登录后投票
   发表时间:2009-01-20   最后修改:2009-01-20
cocal 写道
icewubin 写道
这其实是就是把复杂度转嫁到开发中去了,原本不需要考虑这些问题的,但是因为愚蠢的BOSS搞出来的方案,导致系统的业务从设计到编码到测试都得考虑数据同步的可行性,你可以说业务天生就是如此,但是这“天生就是如此”这个结果就是要通过耗费人工评估得出的结果,这些无谓的成本大多是隐含的。

再有,很多人的想法是,同等成本(人力、物力)下,肯定有更好的整体方案,这是前提。
而楼主的大前提是BOSS下了命令,必须要那么整。
所以你的“未尝不可”基于哪个前提呢?


恕我直言,开发者觉得其他人(比如用户、销售、甚至搭档,当然也包括老板)愚蠢是很大的毛病!

其实从业务设计到编码测试本来就要考虑数据同步的可行性,只是技术人员有了一些现成的工具可用而已,系统设计就那几板斧,OO的结果就是大量的框架、模式、结构可以套用,过惯了衣来伸手、饭来张口的懒日子,就觉得永远不用考虑煮饭了。成本不是技术人员应该考虑的东西,这么说的技术人员只是怕麻烦而已。不得不提醒的是,怕麻烦,就没有机会吃更好的,就这么简单,成功不是随便来的。

我说“未尝不可”的前提是,这是一个新思路,LZ如果能证明这个方案可以成功,就做到了别人做不到的事情。你能做到别人做不到,或者你能先于别人做到,换句话说,就是竞争力!竞争力不用解释吧?吃的好些不难理解吧?何蠢之有?

觉得这个BOSS蠢的人,是否问过当年YAHOO和GOOLE创始人是否也蠢?当年Gates,Jobs哪个不蠢?


   
引用
其实从业务设计到编码测试本来就要考虑数据同步的可行性

    不是吧,我所接触过的项目,从设计到编码,考虑的充其量就是数据的单向同步、集中式的。像这种分布的、双向同步的。你们要是从开始就这样考虑了,那除非是系统有特殊的需求。否则,那真是太过了。如果做实习作品,我倒会考虑一下。

    楼主在标题中说了“or 判个死刑”,说明大家也是可以投反对票的。是吧?

   
引用
恕我直言,开发者觉得其他人(比如用户、销售、甚至搭档,当然也包括老板)愚蠢是很大的毛病!

    不是什么毛病,我猜测只有两种人从来没提过其他人“愚蠢”,一种是很油的(滴水不漏),另一种是很“老”的(爱咋的咋的)。
   
    不是懒不懒的事,实施本身相对来说要保守一些,而且楼主也传达了这样一个信息——他们需要保守一些。

    成本一定就低了么?除非你不把人力、时间以及维护成本算进去。我在前面的留言已经说了,业务楼主最清楚,这种双向同步倒底有多麻烦,怎么样的测试才算完备,这得知道业务的人才知道。当然,后来楼主说了,他们两块儿客户的业务的数据相交很小。

    很喜欢楼主的分享精神。
    最后楼主可能测通了,而且系统也好好的跑着。但我认为这只能说明这样做没问题,并不能证明可靠性就一定比单机的高了。成本就一定低了。
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics