大并发数:
至少也要到10k一级
AJAX意味着更平凡的服务器请求。虽然每次的数据量不大，但是对于AJAX站点来说，每个用户的服务器请求次数将增加。而降低请求开销的一个重要办法是使用 HTTP persistent connection。
不过对于大型站点来说，普通web服务器其实基本上不能从 HTTP connection persistent 上得到好处，因为向apache之类的服务器能够同时处理的连接数目有限。当用户数目巨大时，服务器必须断开旧客户的连接来处理新客户的请求。
越来越多的协作系统要求更高的实时性。像writely,google web talk...
writely使用普通的ajax方式，别人的修改要过10-30后才会出现。这可以说是用户能够忍受的极限了，但同时也是普通web服务器所能忍受的极限。:) 。对于此类应用，最好的方案是使用服务器推的方法。但这就要求客户和服务器之间有一条persistent connection.
异步脚本支持:
语言引擎对web server的性能影响很大，目前常用的两类包括:
.net, java （可以在运行时编译成本机代码，直接运行）
php,asp ,javascript（在运行时编译成字节码，由执行器执行）
这两类的性能差别非常明显，第二类语言的执行速度一般不会超过第一类语言的50%，而第一类语言的执行速度和编码的风格关系很大，使用固定类型的代码一般比使用通用类型的代码快10到100倍，这一点是可以理解的，因为固定类型的代码编译器可以编译成高效的本机代码，直接使用cpu指令运算，而通用类型的代码每次运算时都必须检测变量类型，然后通过计算函数计算。
但是对于web服务语言来说，由于基本上都是IO相关的事务，例如访问数据库，读写文件等， 很少进行科学运算的工作，而大运算量的工作一般被包装的底层支持库中执行。使用编译形语言所带来的性能提升其实并不是非常显着。
另外目前语言的一个显着特点是没有在语言级别提供类似于系统调用的异步接口。所有的外部函数调用必须同步完成，这导致了每个系统线程同时只能运行一个脚本函数。这种结构非常不利于系统的扩展。
这里所说的系统调用是指当调用一个函数时，停止脚本的执行，退出脚本上下文，当系统执行完需要的操作时继续进入脚本上下文执行。这非常类似于OS中的系统调用，OS的内核可以挂起进行系统调用的线程，等操作完成后再继续执行。
etechi server的脚本引擎接口必须提供这方面的支持。
接口：
希望能够提供的接口包括：
ecom
通过vm/ecom 对象模型提供的接口，
自家的东西，当然是100%的兼容性和性能 ^_^
IIS
ISAPI Extension
ISAPI Filter
纯粹的回调函数接口，没有附带的支持库，比较简单
Apachi
Apache 2.0 handler
Apache 2.0 filter
也是通过回调函数实现，但是apache提供apr底层库的支持，可能会有麻烦