编制网络程序，我一直以为isapi是效率最高的，谁有不同的看法？也请高手针对.net,java,corba等作一下对比。(300分)

  • 主题发起人 主题发起人 李衍智
  • 开始时间 开始时间
demo/midas/pooler展示了如何在3层结构中利用pooler共享数据库模块的实例。
（15个数据库模块的实例可以服务100多个client。而不是一个client连接就新建一个数据模块。。。）
服务器使用exe，dcom连接。
由于dcom不能控制对象实例化的个数，所以demo/midas/pooler里面用很多实现了pooler功能。。
我想：能不能把数据模块写成dll，放到com+环境管理，只用指定pool的大小，减少开发的难度？？

用interbase6 + ibx，
新建一个tranactional data module，线程选boath（用在com+中），
放入IBTable1: TIBTable;
IBDatabase1: TIBDatabase;
IBTransaction1: TIBTransaction;
DataSetProvider1: TDataSetProvider;
设置。
编译并安装进入com+ 环境，启用pooler（最大池化数目为3）和jita

client用dcom连接
由于开启jita，可以支持4个以上的client
只用在com+中指定池化数目，就可以实现不再产生实例。。。
不开启jita的时候，client超过上限要等待。
开启jita后，client不用等待，好爽，完全的rad开发
开启jita和pooler可以简化开发。。。。


 
zzsczz:
我的程序是无状态的，即使是分页浏览也是把上次的状态传回服务器应用程序。应该是每次连接后马上断开。因此我觉得问题应该集中在isapi上面。
第一层：服务器应用程序。.exe
第二层：isapi
第三层：htm、javascript、xml
 
还可以这么做：
服务器应用程序写成dll，放到com+中，开启pooler和jita
 
zzsczz:
我们俩的概念好像没搞清，我问的是isapi（我程序的第二层）,你说的是com+，相当于我程序的第一层（也是我概念上的模糊）。但你的回答使我想到了另外的问题（com+）。现在不谈isapi了，在这里利用isapi是最好的选择（当然你也首肯了）。
那么就谈谈com+,利用com+代替我的服务器应用程序（midas），效果当然会好一些，下面是我的结论：
1、com+的内部机制很复杂，利用com+会牺牲效率。但它的事物机制、jit及pool可以弥补，两下打平，但com+会更安全。
2、com+需要建立很多的数据模块，否则就会影响效率，如果业务逻辑比较复杂的话，这样做到底是好是坏，不好评判。
3、服务器程序（包含数据模块）两者都可以编译为dll,com+程序大小要大一倍以上，不知好坏，不敢评判。
4、com+符合潮流。
5、其他方面二者相同。
 
IISFilter效率最高，不过也算ISAPI范畴。
 
我們作OA系統一般用 Apache,
然後在Apache 上面開發 Module,
這樣效率偏高點， 安全性也能得到保障。
 
ISAPI程序崩溃会导致IIS一起崩溃，是IIS的致命弱点，听说IIS6解决了该问题，效率最高的个人认为还是Apache的DSO，安全方面DSO也比isap好，即使一个DSO崩溃了，也不会导致整个Apache停止，而且如果DSO有问题Apache会拒绝启动。
那个冲击波病毒就是利用了com+的一个漏洞M$的一贯特色。
美国勇气号上有一部分功能使用了JAVA。
 
.net效率高
 
单纯谈效率，当然是isapi。
 
以前学了一点,可惜开发项目太慢了,所以放弃了.
 
to 楼主，请问，是否对ISAPI开发很有研究？如果是的话，可否留下联系办法。小弟有问题请教，谢谢！！！
 
Java 趋势很好
 
如果是开发商业化系统,一般会选择bsd, linux等系统,减少系统的投入成本及安全,当然,选择2000也是为了方便维护.
大系统方面,客户们一般提出J2ee架构,虽然他们不懂,但是客户是上帝.市场决定技术.
另一方面就是,假如一个开发团队接了项目,大家都用熟了asp,就没必要为了技术上的效率问题而换其他语言.除非其他情况.只要能解决问题,能完成客户的需求,能达到预期效果,这已经很好的了.至于效率低,加几台服务器就解决了.
用什么语言开发对你自己及自己的团队来说,最方便及快捷,就用什么.
VC是强大过VB,但是软件是你自己开发,如果你只熟悉VB,那么,选择VC来开发会导致你开发上拖期,及软件的不确定因素.
 
doll_paul:
不是很有研究，如有问题可以互相切磋。
liboy.com：
老兄说得不错，但我只要isapi执行效率高就可以了。至于开发效率，常规意义上isapi是效率最低的。不过isapi也不是没有办法提高效率。不有这样一段话么：“人有多大胆，地有多大产；不怕作不到，就怕想不到。”，呵呵，与大家共勉。
 
来自：zzsczz, 时间：2003-12-23 13:26:00, ID：2371338
to 李衍智
简单一点：
开发一个要连接数据库的web应用，
如果只用isapi，每个client都有一个线程，在该线程中建立数据库一个连接。
2000个client就要2000个数据库连接。数据库服务器就垮了。
web服务器上，windows要管理2000个线程，当物理内存不足时，线程切换时要和在虚拟内存和物理内存之间搬运数据，2000个线程并发，搬运频率非常高，产生“thread thrash”，web服务器忙都忙死了。
每个client的连接和退出，服务器都会产生，初始化，执行，结束一个线程，也很浪费
----------------------------
开发一个要连接数据库的web应用，
如果只用isapi，每个client都有一个线程，在该线程中建立数据库一个连接。--- 不一定吧？这要看你的ISAPI是怎么写的。完全可以做到所有客户端的访问共用一个连接啊。只不过，要综合考虑效率的问题，可以考虑多个连接，连接池等。
其实，想象一下ASP/PHP这样的解释程序是如何运作的，就可以知道ISAPI该怎么写了。
如果ISAPI不直接连接数据库，而是通过COM+去获取数据，更可以利用COM+的数据库缓冲池和对象缓冲池，效率就更有提高的空间了。
我做的服务器都是ISAPI+COM+来实现的。效率很高，很稳定。
至于ISAPI崩溃导致IIS崩溃的问题，那自然是程序写得不好导致的。程序写得不好，还会导致OS崩溃呢。
想想ASP/PHP等解释执行的程序，解释执行它们的真正的可执行代码是什么？那些可执行代码如果写得不好，同样也会把IIS搞死的啊。只不过，那些可执行代码一般都写得很不错罢了。
 
to:pcplayer
很同意你的观点！！！
另外，我看过李维的书，说com+最好每个任务有一个数据模块，否则影响效率，不知老兄如何看待这个问题？
 
但就执行速度来说ISAPI是最快的
但是Dot Net的服务端缓存计数很大程度上提高的Web的速度，其实Web程序往往慢在DB访问上，除非有巨大的运算的时候才会显示ISAPI的优势
 
COM+每个任务一个数据模块？什么意思？
一般做COM+，可能要做多个COM+数据模块。其实也就是多个COM+对象。划分的标准大概是：
1、一个（或多个）让ISAPI或其它客户端来调用的协调对象。协调对象内部其实啥事也不干，仅仅是将客户端的调用转为对其它几个COM+对象的调用。这样客户端就可以在执行一次函数调用的时候同时去连接多个COM+对象。协调对象要有对象POOL，这样N多的客户端来调用的时候，其实真正跑起来的COM+对象并不是那么多。因此效率就有了改善。
2、按业务划分COM+对象，也就是所谓的面向对象的设计。
3、直接操作数据库的COM+对象。这里就要处理数据库的连接POOL。有了数据库连接POOL，不用每次都建立数据库连接，效率也会提高很多的。
根据我自己做的ISAPI/COM+/MS SQL 这样的系统的观察，这样做，系统效率还是很高的。而且对数据库的连接数的压力比较小。也就是相同的硬件资源可以支持更多的客户端的访问。因为WEB访问的一般模式是刷一次页面，读一次数据库/处理数据---ISAPI生成页面，然后就断开了。
估计现在。NET已经把这些都在系统层实现了，也不用自己来写COM+那么麻烦了。但实际上用DELPHI来写COM+也是很简单的。
 
.net的重点不在效率上，它有isapi所不具备有优势，单比效率的话，.net确实没有优势.
两者没有可比性，因为目的不同．
 
to pcplayer:
是的，我说错了，就是每个com+对象都对应一个数据模块，我想问的就是这样是不是太繁琐了。
 
您必须登录或注册才可回复。

Similar threads

S
[原]Delphi2010中DataSnap高级技术(7)—TDSServerClass中Lifecycle生命周期三种属性说明
回复
0
查看
899
SUNSTONE的Delphi笔记
S
S
[原]Delphi2010中DataSnap高级技术(7)—TDSServerClass中Lifecycle生命周期三种属性说明
回复
0
查看
921
SUNSTONE的Delphi笔记
S
S
[原]详解Variant 的相关函数
回复
0
查看
1K
SUNSTONE的Delphi笔记
S
S
[原]详解Variant 的相关函数
回复
0
查看
900
SUNSTONE的Delphi笔记
S
S
[转]ClientDataSet加上TDataSetProvider的数据保存问题
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
后退
顶部