基于eXtremeDB/eXtremeWS的主动式B/S架构的实时数据显示系统

lmx66768

INSERT 应用测试。//虽然是应用，但是是个简单插入的测试。


1．        虚拟用户数为1
ALTIBASE 中循环1000次
Transaction Name        Minimum        Average        Maximum        　//单位为应该是秒吧，你可以用loadruner 测试看看。
Action_Transaction　　　0.006        0.017        0.227       

Altibase
        操作系统        AIX 5.3 64bit
        CPU        1.2 G *4
        内存        8 G

tomcat
       操作系统        Windows xp
       CPU        Inter 3.0G
       内存        1 G

// 仅供参考，因为拿别人的B/S应用改的，比较粗糙。只能想说明B/S架构其他WEBSERVER 应该也能达到10毫秒级。

个人认为主要还是网络瓶颈。

-------------------------------------------------------------------------------------------------------------------------------

另外您一直在说0维护！

其实很多系统上线稳定后，都只是做一些基本的监控，也是7*24小时运行，没有什么可维护的。
除非系统发生变化，可能需要对系统的一些参数进行配置、维护。

datamann

上面的时间数据是altibase每事务1000条的情形吗？这是很正常的。实时数据库达到毫秒级是理所当然的，尤其是在服务器上。

eXtremeWS还可以把速度提高上去，但应用中不需要更高的速度，所有没有去做。（这是通信卫星监控的一个示例，实际上要复杂得多）。确实，受限于网络和http协议，速度不可能提得过高；并且，人眼分辨率有限，实际中显示的速度也不必太快。
这里说的免维护，和您说的免维护是有区别的。您说的免维护是系统稳定工作后就不必维护了；我说的免维护是完全没有提供可维护的条件（就是此前我说的场景了）。所有，整个设计的出发点是以这个场景为基础的。
我把这个贴出来，是给大家一个参考，就是在这样的场景下，通过eXtremeDB/eXtremeWS的主动B/S架构能够达到我们的目的。不是为了炫耀eXtremeDB有多快、eXtremeWS有多快，而是为了说明这个方案可以在多么苛刻的条件下达到让人满意的效果。
在电信计费系统的场景下，B/S架构也是有意义的，但不是唯一的，可能也不是首选的；在我说的场景下，这可能是唯一的或首选的了。
看起来您做了不少工程。

lmx66768

不是每个事物1000条，是逐条提交。总共就做了1000条的简单测试。

-------------------------------------------------

你说的0维护，我听着很玄！
听起来，一挥而就。
简单想一下，Oracle 这么优秀的数据库，也是需要维护的，你不用维护？！

希望以后有机会亲自了解一下！！！！

datamann

在这个问题上，我就说一些题外话了。您技术还是挺好的，但对这种场景的可能接触不多：航电、舰电等等很大硬实时设备的本身就没有显示终端，而数据又很大、很复杂（比如非表格结构化数据），就要用到实时数据库。这样的场景就要求数据库在逻辑上就不必进行维护。
这种类型的实时数据库，我们是称为普适性实时数据库。eXtremeDB在普适性数据管理方面是非常优秀的。

datamann

INSERT 应用测试。//虽然是应用，但是是个简单插入的测试。


1．        虚拟用户数为1
ALTIBASE 中循环1000次
Transaction Name        Minimum        Average        Maximum        　//单位为应该是秒吧，你可以用loadruner 测试看看。
Action_Transaction　　　0.006        0.017        0.227        

Altibase
        操作系统        AIX 5.3 64bit
        CPU        1.2 G *4
        内存        8 G

tomcat
       操作系统        Windows xp
       CPU        Inter 3.0G
       内存        1 G

// 仅供参考，因为拿别人的B/S应用改的，比较粗糙。只能想说明B/S架构其他WEBSERVER 应该也能达到10毫秒级。

大问题！同一个insert测试，1000次里面时间可以相差38倍！这是什么实时数据库啊？！！！实时数据库的“实时性”的定义是期限内完成，是在“准”的基础上的“快”。请您说明一下altibase是怎么理解实时数据库的实时性的。

[ 本帖最后由 datamann 于 2008-1-14 19:40 编辑 ]

lmx66768

那个测试主要瓶颈在网络，webserver的性能。
临时在比较乱的网络上做的。
我只想告诉你，你们的b\s结构性能并不比别人的快！！！






[ 本帖最后由 lmx66768 于 2008-1-15 09:19 编辑 ]

lmx66768

我做过很多测试，有很多不确定因素，所以其中的max 有很多不确定性。
我为了说明extremeDB 并不比别人的快，这样的系统结构影响性能的瓶颈是网络，草草的做了个测试说明问题。
但是有人却拿这个做文章！

本来以为这个人还说点技术，还贴出一些有用的东西，跟这个人答茬实在是一个失误。

lmx66768

这个是我刚刚做的测试，两个节点间sock的发包的测试。
这个比我上次测试的环境要好。两台aix 机器间，1000m网。

测试数据为每秒发包的个数。每个包大小128k 。
大家可以看到下面网络性能跳跃的地方。
最快发包数为668个/s ,最慢为68个/s
最快1/668 s 一个包  ,最慢1/68 s一个包
他们间的性能差距是9倍多。

-------------------------------------------
DATA SIZE = 131072
DATE = [20080114174438] [515] : ACK
DATE = [20080114174439] [667] : ACK
DATE = [20080114174440] [667] : ACK
DATE = [20080114174441] [643] : ACK
DATE = [20080114174442] [668] : ACK
DATE = [20080114174443] [666] : ACK
DATE = [20080114174444] [667] : ACK
DATE = [20080114174445] [666] : ACK
DATE = [20080114174446] [667] : ACK
DATE = [20080114174447] [665] : ACK
DATE = [20080114174448] [663] : ACK
DATE = [20080114174449] [664] : ACK
DATE = [20080114174450] [662] : ACK
DATE = [20080114174451] [552] : ACK
DATE = [20080114174452] [164] : ACK
DATE = [20080114174453] [68] : ACK
DATE = [20080114174454] [500] : ACK

-----------------------------------------------
我测试是网络并不是我独自用的，我也没有刻意在其他人用的忙得时候去测试。
性能发生跳跃根据测试系统，测试环境不同，有很多变数。

我已经尽力说明了。也有点累！ 希望您能从技术角度认真思考！

lmx66768

我只是说明网络并不稳定，这个并不一定是网络忙，也有可能是其他因数。
我以前就碰到过，两个节点，专线1000m网络，但是性能跳跃的很厉害，又IBM工程师请求了更高级别的支持才解决的问题。

还有我做的测试，128k 发一个包，并不能模仿b/s 测试环境真正的网络跳跃差距。

datamann

altibase有没有本地编程模式？就是eXtremeDB所说的“嵌入”或timesten所说的“直链”模式？在这个模式下，网络不确定性可以被踢出。在这个模式下，性能晃动性可以降低到什么程度？如果没有本地编程模式，将C/S放到同一个机器，看看晃动性情况如何。
多谢您了！