smart—一种高效的web应用服务器

吴开超 何洪波

(中国科学院计算机网络信息中心，北京，100080)

摘要       本文提出了一种新的web应用服务体系结构SMART，给出其参考实现smart服务器。同时评测了smart服务器的性能，比较了smart与apache + cgi、resin等不同方案的性能结果。

关键词 web框架; SMART; CSP

全文下载：Smart—一种高效的Web应用服务器.doc

一、背景

Internet的蓬勃发展，使得Web技术越来越重要，作为Internet上最重要的应用，web日益进入人们的生活。越来越多的人开始通过web方式共享信息资源，人们对大规模、高效的web访问的需求在不断增长。当前网络技术发展突飞猛进，网络传输速度越来越快，这也就要求在网络上的web应用服务也能适应网络技术的快速发展和人们的需求。当前，Internet上的web应用服务建立在传统的网络技术的基础上，为了适应未来的网络技术发展，需要对web应用服务技术进行革新，以建立更加高效、快捷的web应用服务系统，使人们更加便利地利用Internet上的信息资源。

当前典型的基于Web的应用如下图所示：

Web浏览器通过HTTP（HyperText Transfer Protocol）协议读取位于Web服务器上的文档，并将文档在浏览器中解释显示，还可进一步通过文档在浏览器中显示的超链接，访问Internet上各种资源，真正实现全球网络资源共享— World Wide Web。

按照web文档性质的不同，对处理器、网络和输入/输出资源要求的差异，可以将web文档分为两种类型：静态文档和动态文档。

静态文档是实际存放在web服务器上的文档。当浏览器向web服务器发出HTTP访问请求，web服务器就直接将该静态文档传送回浏览器。这类文档包括普通的HTML文件、文本，以及图象、声音等静态多媒体数据，它们对处理器负载影响不大，造成的磁盘I/O负载与文档的大小成正比，主要对网络I/O造成压力。

动态文档，是一种在web服务器上并不实际存在文档。只有当浏览器向web服务器发出访问请求，web应用服务器才根据请求进行处理动态产生该文档，并通过web服务器将该文档返回浏览器。应用服务器的处理过程包括访问磁盘文件、操纵数据库、压缩解压缩多媒体文件等。与静态文档相比，这些请求的处理过程需要更多的处理器时间和磁盘I/O。

通过静态文档、动态文档的分析可以看出，静态文档通过web服务处理，而动态文档则通过web应用服务处理。高性能的web服务系统必须同时包含web服务和web应用服务的功能，能对静态文档、动态文档同时进行高效的处理。为了对Internet上日益增长的大并发量的、高效的web应用进行有效的支持，在本文中，我们提出了一种安全、高效、可靠、易于应用开发的web应用框架SMART(Simple Multi-threaded Architecture for Reliable Transfer )，该框架能较好地满足大规模并发访问的要求，并实现web服务和web应用服务的功能，同时支持动态文档、静态文档。在SMART框架的基础上初步实现了smart服务器（以下也简称为smart），smart中还实现了一种支持以C/C++语言作为脚本语言的web开发环境CSP（C/C++ Scripted Pages），CSP为web应用的开发过程和运行阶段都提供了较好地支持。

二、   SMART体系结构

SMART是一种通用web应用服务体系结构，其体系结构图如图二所示。

SMART在同一进程地址空间中同时支持web服务、web应用服务的基本功能。SMART支持IPv4及未来的IPv6，以适应未来Internet的发展；支持国际化，在其内部可采用Unicode/UTF-8形式表示国际字符，并可在国际化的基础上，支持本地化，支持对中文字符的处理；通过认证服务的支持，可实现基于HTTPS的加密传输；为保证系统的运行效率，SMART中采用类似于RISC的思想，取消对某些大规模并发系统中应用较少的、比较影响系统性能的或已有更好替代的web技术的支持，比如cgi、虚拟主机等，通过精简系统的功能来提高效率。

在SMART的体系结构中，通过文档处理引擎对静态文档、动态的CSP文档的处理提供了相应的支持。通过采用多线程技术、连接池技术、各种异步访问技术等大规模并发访问技术提高单台服务器的运行效率，在高负载下通过动态调整服务器运行参数，保证服务器在极限状态下的性能。在网络层传输上，还通过将数据整帧封装传送来优化网络性能，提高网络效率。

SMART还通过统一的log记录访问接口支持多类型可定制的log格式，包括UNIX下的syslog系统日志格式、apache的标准web日志格式、存放在关系数据库中自定义日志格式等，通过对多种日志格式的支持，便于采用多种log分析工具直接进行分析，能及时、有效地提供web访问的分析结果。

在SMART体系结构中，在提高单台服务器运行效率的同时，还通过将多台服务器组成机群系统smart cluster，以cluster的方式来大幅度提高整个系统的负载能力。针对web应用中HTTP协议无连接的特点，smart cluster通过分布式session技术支持群集系统。在smart cluster中多台服务器之间的负载均衡技术可包括简单的DNS循环解析、基于SNMP的负载均衡等。基于SNMP的负载均衡系统需要在每台服务器上加上支持SNMP协议的监控模块，动态检查每台服务器的负载。每当有新的访问请求到达时，最初收到请求的服务器作为代理将请求转发到负载最轻的服务器上，从而在系统内部真正实现负载均衡。

在可靠性要求较高的情况下，为保证在多机环境的smart系统的可靠运行，可通过配套的监控系统，监控整个系统的运行状况。在监控系统的网管工作站上，监视smart cluster上每台服务器的负载情况及运行状况（登录用户数、并发用户数、响应时间等）；监控系统根据某种策略，动态调整服务器运行参数（总线程数、每个线程的最大连结数等），保证smart系统在高负载下可靠地运行；对于系统出现的异常情况，系统及时作出自适应处理，同时通知系统管理员。监控系统的实现可通过读取系统的配置，通过每台服务器上的负载监控模块定时检测整个系统（包括smart cluster、数据库、LDAP、应用服务器等）的运行状况。

为提高系统的可扩展性，还可以在SMART的后端通过扩展接口实现多种关系数据库系统、多种高性能的应用服务器（IBM的WebSphere、BEA的Texudo等）以及目录服务的直接连接。

smart服务器同时支持静态文档、动态文档，兼有web服务器和web应用服务器的功能。对静态文档采用预处理后直接传送的方案，对动态文档采用在静态文档中嵌入C/C++脚本的CSP方案。下图是smart服务的启动过程：

在smart启动时，对静态文档进行预处理，处理后文档放在特定的目录下。当有静态文档访问请求时，smart通过系统调用将预处理后文档直接返回给浏览器，这种方式将明显节省系统开销，如果系统有足够的内存，还可将预处理后文档直接存放在内存中，显著减少磁盘操作时间。

对动态文档，smart采取的是CSP动态页面方案。与静态文档的处理方式相类似，在smart启动时也需要对动态文档做预处理，将CSP页面预处理成为C++源文件，再通过C++编译器将CSP页面编译进入smart服务程序中。这样，不同于一般的web应用框架中设置单独的应用服务器来解释应用脚本，产生动态文档；在smart中，由smart自身来直接产生动态文档，在与smart同一地址空间中运行web应用，运行效率显著提高。

在CSP中，提供了类似于ASP、JSP的对象框架，CSP对象框架如下图所示：

图四 CSP运行环境对象框架示意图

server

thread

session

request

page

response

在CSP中，可以采用以C/C++作为脚本语言编写web应用脚本，并将它们嵌入在HTML中做成动态页面CSP。与JSP、ASP框架相比较，CSP框架为了提高效率，简化设计，并未提供在server上的application级对象支持，也就是说，整个server就只包含一个应用；此外，thread也是JSP、ASP中所没有的，是用户的request对应的server端的运行，可与连接池技术结合，访问server上的各种连接，包括数据库连结、LDAP连结、应用服务器连接等各种类型的连接，将thread直接放到对象框架中，这将显著简化基于关系数据库、LDAP服务器的web应用，提高运行效率。

其它的对象类似于JSP、ASP，Server对应整个CSP的server运行环境；session对应某一用户的整个登录过程； request指用户的一次访问请求；response是对应一个request的server对client的响应；page指server上的一个html页面单位。

在单台smart服务器内部采用多线程的体系结构，其内部结构如下图所示。

smart启动时，首先启动smart的主线程httpd、task管理线程task_handler，再通过task handler初始化产生由多个task线程组成的线程连接池，其中每个task都是能独立处理web访问请求的线程。当smart收到web访问请求时，将其放到请求队列中。而task handler则不断地将web访问请求分配给不同的task进行处理。

task是对web请求进行处理的实体。对于两种不同类型的文档：静态文档、动态文档，task采取了前面讨论的方案进行处理。在task中，结合了连接池技术，将各种连接在task内部直接实现，大大简化对连接的处理，保证应用开发和系统运行过程的效率。

三、   smart服务器实现

smart服务器是SMART体系结构在UNIX平台上的实现，目前是在redhat linux 7.x上用C++实现的基本系统，并未实现SMART框架中的所有功能。

基本系统的功能包括：静态、动态文档的HTTP请求响应处理的基本web server框架；本机session处理；线程连接池管理。同时还实现了CSP引擎，制订了CSP页面编码规范；实现了通用扩展接口，并在此基础上实现了关系数据库mysql的数据库驱动接口。

基本系统只实现HTTP /1.0中的 GET/POST方法；针对单机环境实现，不包括分布式session、动态负载均衡实现；不含SNMP监控模块；基本系统针对IPv4实现；内码采用ASCII，未包括国际化、本地化支持；通用log访问接口的log格式目前可支持syslog，对于标准web日志格式的log接口也已经完成。

在smart的静态文档处理实现过程中，为提高处理效率，采用了UNIX下系统调用sendfile直接将静态文档发送回浏览器，因此，要求操作系统能支持sendfile系统调用的实现。主要版本的UNIX，包括Linux、FreeBSD、Solaris等，都实现了sendfile系统调用，smart服务器能较为方便地移植到这些平台上。

CSP引擎支持server端session处理,在server端记录完整的session信息。在通过网络传输时，仅将session_id传递到client端。session_id传递方式有两种： cookie和url重写。完整的session内容包括：session_id、最近访问时间、所有的session属性。其中session_id的格式为：

server ip (4字节)

client ip (4字节)

随机数 (4字节)

创建时间 (4字节)

其中， ip地址为4字节无符号整数。session_id在通过网络传输过程中，需要通过base64、或16进制编码，所以在存储时也通过编码方式存储。

四、   性能评测

smart的系统性能评测，包括对静态文档、动态文档的评测。以下通过对smart、resin、apache+cgi三种不同的web及应用服务方案在相同条件下进行简单的测试，得出相对的比较结果。测试工具采用acme的http_load，通过http_load可以测试web服务中HTTP请求响应的多项性能指标，我们选取了最有代表性的单位时间请求响应数（次/秒），平均响应时间（毫秒）。对于测量结果通过excel进行统计分析，并画出三维柱状图。为避免网络性能对测试结果的影响，测试client和server都是在单台服务器上完成，每次测试时间间隔为5秒，client端并发线程为5个。

1、测试环境：

测试服务器：IBM Netfinity 5600 1G内存，2*PIII800，100M网卡

操作系统：redhat 7.2。

测试工具：http_load。

2、测试内容：

测试内容包括对静态文档、动态文档的测试。静态文档选取了不同大小的静态文档；动态文档选取了最简单的动态文档hello world的生成以及典型的数据库访问产生动态文档。具体内容包括：

1.     128字节的静态文档

2.     64K字节的静态文档

3.     hello world的动态文档

4.     典型的数据库应用，读取mysql中数据表，根据表中内容产生动态文档

3、服务器类型

为了评测smart的性能，我们选取的参照方案包括：目前Internet上最流行的web服务器apache，对动态文档处理采用传统的web应用开发方案cgi；另一种服务器为被认为是最快的纯java的web应用服务器resin。具体方案如下：

1.     smart 0.2.0

2.     resin 2.0.4 + Sun JSDK 1.3.1

3.     apache 1.3.19 + cgi

4、测试结果

每个服务器类型的方案的每一项测试内容均进行了4次测试，最终统计结果取4次结果的平均值。每次测试结果包括：单位时间的请求响应数（次/秒），平均响应时间（毫秒）。

测试结果以表格形式如下所示。

下面是以柱状图形式表示的测试结果：

通过测试结果的比较，我们发现在相同条件下，对于静态文档服务，smart方案的比apache方案快两倍以上，比resin方案要略快。对于动态文档服务，smart和 resin方案要比cgi快得多，其中smart方案最快。对于数据库型的应用，由于smart方案中内置db支持，其优势更为明显，比resin方案快3倍，比cgi方案快7倍。综合这些性能特性，通过对smart开发框架的分析，可以看出，smart是一种高效、快捷的web应用开发框架，对web应用的开发、运行都提供了较好的支持，是一种有前途的web应用技术。

在评测过程中，我们开发了针对三种服务器类型下动态文档测试程序，分别是smart中的CSP、resin中的JSP、apache中的cgi。在开发过程中，我们发现，通过CGI开发web应用难度较大，动态页面完全需要通过程序产生；而CSP、JSP在对开发过程的支持方面各有千秋，二者都是在HTML中嵌入动态脚本的方案，JSP中嵌入Java脚本；CSP中嵌入C++脚本。与JSP相比，CSP开发框架中就可提供对包括数据库连接的多种连接的支持，非常高效、方便；CSP的主要缺点是在开发过程中不太方便，每当有页面更新，都需要重新启动smart服务器而使这些页面生效。

五、   未来发展

目前，smart服务器是基于SMART框架实现的基本系统，在redhat linux 7.x上实现了SMART框架的基本功能。今后我们将继续完善系统功能，包括：继续采用新技术，提高单台服务器性能；利用分布式session，实现smart cluster，通过负载均衡增强系统的负载能力；实现在高负载下动态调整系统运行参数，保持系统的可靠运行；完善监控系统，提高可靠性；在现有mysql数据库连接的基础上，增加对主要关系数据库、目录服务器、各类应用服务器的支持，进一步提高系统的可扩展性。

在完善系统功能的基础上，将smart的运行平台扩展到其它的UNIX系统上，包括Solaris、FreeBSD。此外，还需对系统进行更严格、规范的测试，按照SPEC web99标准的要求，对smart做测试，得出规范的web性能指标,以促进smart早日进入实用。

六、   结论

本文针对大容量web应用服务，提出了应用框架SMART，并在此框架的基础上完成了参考实现。SMART应用框架可针对web上的静态文档、动态文档，提供统一、高效的实现方式,是一种有前途的web应用服务的开发框架。

参 考 文 献

1   The C10K problem http://www.kegel.com/c10k.html

2   thttpd-tiny/turbo/throttling HTTP server http://www.acme.com/software/thttpd/

3   Apache http://www.apache.org

4   Resin http://www.caucho.com

5   An efficient and portable Web server http://www.cs.rice.edu/~vivek/flash99/

smart – An efficient web application server

Wu Kaichao He Hongbo

Computer Network Information Center, Chinese Academy of Sciences, 100080

Abstract  This paper presents the design of a new web application architecture called Simple Multi-threaded Architecture for Reliable Transfer(SMART), and describes a reference implementation of this architecture, the smart web application server。We also evaluates the performance of smart, and compare it with that of apache+cgi and resin.

Keyword  web framework, csp, smart