`

webServer LiteSpeed

阅读更多

http://rforum.andreas-s.net/ 

Powered By LiteSpeed Web Server

http://bbs.zmke.com/dv_rss.asp?s=xm&boardid=26&id=2531&page=1&star=1&count=1

Powered By LiteSpeed Web Server

Lite Speed Technologies is not responsible for administration and contents of this web site!

 

[转载.增评]Apache Nginx lighttpd HAProx Litespeed 缓冲原理解析fastcgi性能

http://www.diybl.com/course/3_program/c++/cppjs/2008828/138203.html

由于最近在忙于web server的开发,对于静态部分跟动态部分的交互一直迟迟未定,缓冲区大小也一直很头疼,看了下面的这篇文章觉得不错,我还是这样觉得,简单的就是最好 的,但并不意味着所有处理都用一种方式,正如我在静态输出的socket buffer上面一样,我是根据请求内容的大小来决定缓冲区分配的,即使这样作在系统内部会形成一次内存拷贝(socket回去处理),但是相对于网络的 延迟速度快多了,所以我觉得还是根据不同的内容和大小决定缓冲区大小,既不是lighttpd的照单全收,也不是nginx等的8K绣花,对于接收,首先 分配一个2k-8K的缓冲区去收,西一头部接收完毕了就可以知道剩下的contentlength,比如内容在8K-64K之间的用32K,64K-无穷 大K之间的用64K,这样就可以用进程内的一次内存拷贝换取网络的延迟问题,对于fastcgi的支持也会更好,下面是原文
RoR的部署方案可谓五花八门,有Apache/Fastcgi方式的,有Nginx/Mongrel方式的,还有lighttpd/Fastcgi方 式,也有人使用HAProxy/Mongrel,各种部署方式都是众说纷纭,让人搞不清楚哪种方式更好一些。我的这篇文章就是希望结合我们运营 JavaEye网站一年多以来的经验(通过统计Rails的production.log,JavaEye网站目前每天处理超过70万200 OK状态的Ruby动态请求,应该是国内目前负载量最大的RoR应用了),为大家剖析RoR部署方案的优劣,帮助大家选择适合自己生产环境的RoR部署方 式。

在讨论部署方案之前,先让我们看一下RoR网站部署的简单架构:



浏览器的HTTP访问请求首先达到Web服务器,充当Web服务器的一般是Lighttpd/Apache/Nginx,如果访问请求包含静态资 源,那么Web服务器就会直接从本地硬盘读取静态资源文件,例如图片,JavaScript,CSS等等,返回给客户端浏览器;如果访问请求是动态请求, 那么Web服务器把URL请求转发到后端的FastCGI/Mongrel来处理,等到FastCGI/Mongrel处理完请求,将生成的页面数据返回 给Web服务器,最后Web服务器把页面数据发送到客户端的浏览器。

从RoR的部署方式来看,主要由前端的Web服务器和后端的应用服务器构成:前端的Web服务器可以使用Apache,Lighttpd,Nginx和Litespeed,后端的应用服务器可以使用FastCGI和Mongrel,下面我们分门别类的介绍和剖析:

一、介绍Web服务器
Web服务器的主要作用有两点:一是处理静态资源,二是将动态请求分发到后端应用服务器,然后接收后端应用服务器生成的页面数据,将其返回浏览器,充当了一个信息沟通的桥梁作用,在本文当中我们重点分析后者的作用。

1、Apache 2.2

Apache是全球互联网使用最广泛的Web服务器,但在处理静态资源文件上却不是性能最优秀的Web服务器,不过一般情况下,静态资源的访问并不是RoR网站的瓶颈,因此也不必过于在意这一点。

Apache 2.2既支持HTTP Proxy方式连接后端的Mongrel应用服务器,也可以通过mod_fastcgi/mod_fcgid来连接FastCGI应用服务器:当以 HTTP Proxy方式连接Mongrel的时候,Apache接收Mongrel返回的页面数据的buffer size最大只能开到8KB(默认是4KB或者8KB),因此当页面数据超过8KB的时候,可能需要Apache和Mongrel之间发生多次交互;当以 mod_fastcgi方式连接FastCGI应用服务器的时候,接收返回数据的Buffer size仍然只有8KB而已,如果使用mod_fcgid,那么buffer size为64KB,有了很大的改善。

2、Nginx

Nginx是俄国人出品的轻量级Web服务器,在处理静态资源方面,据说性能还略微超过Lighttpd的10%,而且资源消耗更小。

Nginx内置了良好的HTTP Proxy和FastCGI支持,因此即可以连接Mongrel,也可以连接FastCGI服务器,在这两种情况下,Nginx默认的接收应用服务器返回 数据的Buffer Size也只有区区的8KB,但是你可以自行设置更大Buffer Size。

3、Lighttpd

Lighttpd是全球互联网排名第五的Web服务器,也是近两年来上升最快的Web服务器,特别是很受一些著名Web 2.0大网站的欢迎,例如wikipedia的某些服务器,youtube的视频服务器,在国内,豆瓣网站和JavaEye网站都是Lighttpd的绝 对拥护者。在处理静态资源方面,Lighttpd性能远远超过Apache。

Lighttpd既支持HTTP Proxy连接Mongrel,也支持FastCGI方式,但是Lighttpd的FastCGI支持在所有流行的Web服务器当中可能是最优秀的,所以 用FastCGI的网站都很喜欢Lighttpd。Lighttpd在接收后端应用服务器返回数据的方式上和Apache/Nginx有非常大的区别:

Apache/Nginx是针对每个应用服务器连接分配固定Size的Buffer,而且默认只开8KB,这个Size对于现在网页动辄 50-100KB的情况来说,显得过于保守,如果应用服务器的返回数据无法一次填满Web服务器的Buffer,那么就会导致应用服务器和Web服务器之 间多次数据传输,这对于RoR网站的性能会造成一些相关的影响,我们在后面会详细的分析。

Lighttpd并不针对应用服务器的每个连接分配固定的Buffer,而是尽可能的把应用服务器返回的数据一次性接收下来,因此无论应用服务器返回多大的数据量,Lighttpd都是照单全收,胃口非常惊人。

4、Litespeed

Litespeed是一个商业收费的Web服务器,静态资源处理能力据它自己的评测数据比Lighttpd略高。Litespeed也同时支持 HTTP Proxy连接Mongrel和FastCGI连接应用服务器。此外Litespeed专门为单机运行的RoR开发了一个lsapi协议,号称性能最好的 RoR通讯协议,比HTTP Proxy和FastCGI都要好。但是lsapi的运行方式有很大缺陷:因为lsapi不是web server启动的时候启动固定数目的ruby进程,而是根据请求繁忙程度,动态创建和销毁ruby进程,貌似节省资源,实则留下很大的黑客攻击漏洞。只 要黑客瞬时发起大量动态请求,就会让服务器忙于创建ruby进程而导致CPU资源耗尽,失去响应。

由于Litespeed在运行RoR方面并没有表现出比Lighttpd优越之处,而且还是收费软件,企业版本售价在双核CPU上面每年收费 499美元,并且也不开源,因此我们就不再把关注点放在Litespeed上面。当然Litespeed收费也不是白收的,它提供了非常好用的基于Web 的服务器管理界面,以及非常多的安全性方面的设置参数。

5、HAProxy

HAProxy并不是一个Web服务器,他既不能处理静态资源,也不能充当浏览器和应用服务器之间的缓冲桥梁,他只是充当了一个请求分发的软件网 关作用。ThoughtWorks公司的RubyWorks选择使用HAProxy + Mongrel Cluster的方式来部署RoR应用,不能不说是一个愚蠢的方案。这种方案其实相当于把n个Mongrel应用服务器捆绑起来,直接充当Web服务器, 而Mongrel毕竟是一个Ruby写的服务器,无论是网络IO能力,还是静态资源的处理速度,无法和真正的Web服务器相提并论,让Mongrel直接 处理静态资源和调度网络IO,会造成服务器资源毫无必要的极大开销,因此HAProxy也不在我们的考虑之列。


二、分析应用服务器的处理方式

无论是Mongrel还是FastCGI,都能够良好的运行Rails服务器,但是他们在和Web服务器之间的数据传输方式上存在一些差别,而正是这些差别,对部署方式有重大的影响:

1、Mongrel

Mongrel本身可以直接充当Web服务器,但在这种情况下性能并不会好。因为Mongrel只有HTTP协议的解析部分是用C语言编写的,其 余所有代码都是纯Ruby的。在处理静态资源下载上面,Mongrel的实现方式非常低效率,他只是简单的以16KB为单位,依次读入文件内容,再写出到 网络Socket端口,其性能远远比不上传统的Web服务器调用操作系统的read()和write()库实现的静态文件下载速度,如果和现代Web服务器实现的sendfile方式的“零拷贝” 下载相比,简直就是望尘莫及。

Mongrel使用了Ruby的用户线程机制来实现多线程并发,并且使用了一个fastthread补丁,改善了Ruby用户线程的同步互斥锁问 题。但是Ruby并不是本地线程,我们也不要对Mongrel的网络IO负载能力抱有什么不切实际的幻想。同时Rails本身也不是线程安全的,因此 Mongrel在执行Rails代码的过程中,完全是加锁的状态,那和单进程其实也没有太大差别。

因此,当我们使用Mongrel的时候,一般会在前端放置Web服务器,通过HTTP Proxy方式把请求转发给后端的Mongrel应用服务器。在这种情况下,Mongrel只处理动态请求,在运行Rails框架生成页面数据之后,把数 据返回给Web服务器就可以了。但是在这种部署方案下,有一个很重要的细节被我们忽视了,Mongrel运行Rails生成的页面数据是怎么返回给Web 服务器的呢?通过仔细钻研源代码我们可以搞清楚Mongrel处理Rails请求的细节:

1) Mongrel接收到请求以后,启动一个ruby线程解析请求信息
2) 加锁,调用Rails Dispatcher启动Rails框架
3) Rails处理完毕,创建一个StringIO对象,把Rails生成的页面数据写入到StringIO中
4) 解锁,把StringIO的数据flush到Web服务器

这个StringIO对象其实很重要!它充当了一个输出缓冲区的作用,我们设想一下,当Mongrel作为独立的Web服务器的时候,如果 Rails生成的页面比较大,而客户端浏览器下载页面的速度又比较慢,假设没有这个StringIO对象,会发生什么问题? Rails线程在执行render方法的时候就会被挂住!同步互斥锁没有解锁,Mongrel再也无法处理下一个动态请求了。

当Mongrel仅仅作为应用服务器的时候,这个StringIO仍然很重要,为什么?我们前面提到过了,Apache/Nginx的接收缓冲区 都只开了8KB,如果页面比较大,Mongrel就没有办法一次性把数据全部推给Web服务器,必须等到Web服务器把接收缓冲区的8K数据推到客户浏览 器端以后,清空缓冲区,才能接收下一个8KB的数据。这种情况下,Mongrel必须和Web服务器之间进行多次数据传输,才能完成整个Web响应的过 程,显然没有一次性把页面数据全部推给Web服务器快。如果Web服务器使用Lighttpd的话,情况会不一样。当Mongrel把StringIO的 数据flush出去的时候,Lighttpd是一次性全部接收下来了,不需要多次交互,因此Lighttpd+Mongrel的RoR网站的实际速度要快 于Apache/Nginx+Mongel。

Mongrel使用StringIO对象缓存输出结果,在某些特殊的情况下会带来很大的安全隐忧。我们假设使用服务器端程序控制带权限的文件下 载,某用户下载的是一个100MB的文件,该用户使用了多线程下载工具,他开了10个线程并发下载,那么每个线程Mongrel在响应之后,都会把整个文 件读入到内存的StringIO对象当中,所以总共会创建出来10个StringIO对象保存10份文件内容,所以Mongrel的内存会一下暴涨到 1GB以上。而且最可怕的是,即使当用户下载结束以后,Mongrel的内存都不会迅速回落,而是一直保持如此高的内存占用,这是因为Ruby的GC机制 不好,不能够及时进行垃圾回收。

也许你会觉得不太可能下载100MB那么大的附件,但是以JavaEye网站为例,圈子的共享文件最大允许10MB,只要用户在多台机器上面,每 台机器开100个线程下载圈子共享文件,每个Mongrel的内存占用都会立刻超过1GB,用不了几分钟,服务器的物理内存就会被耗尽,网站失去响应。这 个缺陷非常容易被别有用心的黑客利用,攻击网站。这也是JavaEye网站为什么始终不用mongrel的原因之一。

通过上面的剖析,我们知道Mongrel在使用Lighttpd的时候,可以达到最快的RoR执行速度,但是Lighttpd当前的1.4.18 版本的HTTP Proxy的负载均衡和故障切换功能有一些bug,因此一般很少有人会使用这种方式。大多数人都会采用Mongrel搭配Apache2.2或者 Nginx,但是正如我们上面做分析的那样,Apache/Nginx的Buffer Size实在是一个很讨厌的限制,特别是Apache只能最大开8KB的Buffer,因此我建议使用Nginx搭配Mongrel,并且把Nginx的 Proxy Buffer Size设置的大一些,比如说设置为64KB,以保证大多数页面输出结果可以一次性flush到Web服务器去。

2、FastCGI

很多人对FastCGI谈虎色变,仿佛FastCGI就是内存泄漏,性能故障的罪魁祸首,又或者嫌弃FastCGI太古老了,已经被淘汰掉的技术 了,其实这是一个很大的误解。FastCGI本质上只是一种进程间通讯的协议,虽然是一个比较古老的协议,但是还是比HTTP协议年轻多了,HTTP协议 不是照样现在很流行吗?

在PHP/ASP/JSP流行之前,FastCGI曾经非常普及,只不过那个时代的FastCGI程序是用C语言编写的,写起来太费劲,而PHP /ASP/JSP相比之下,写起来就太简单了,所以FastCGI就渐渐被丢到了历史的故纸堆里面。但是最近两年来,由于Ruby和Python的快速 Web开发框架的强势崛起,FastCGI仿佛又咸鱼翻身了。

当我们以FastCGI方式运行Rails应用服务器的时候,每个FastCGI进程都是单线程运行的,考虑到Rails本身不是线程安全的,所 以和Mongrel运行Rails的实际效果是一样的,都是每个进程只能跑一个Rails实例。但是FastCGI在Rails生成页面数据返回给Web 服务器的方式和Mongrel截然不同:

前面我们说到Mongrel自己开了输出缓冲区,而FastCGI则完全不开任何缓冲区,当Rails执行render方法的时 候,FastCGI实际执行的是FCGI::Stream.write方法调用,直接把数据写给Web服务器了。此时如果Web服务器是 Apache/Nginx,会发生什么?

如果我们使用mod_fastcgi模块,那么Apache的接收缓冲区就是8KB;
如果我们使用mod_fcgid模块,那么Apache的接收缓冲区就是64KB;(mod_fcgid是中国人开发的取代mod_fastcgi的开源项目,在Apache社区很受欢迎,谁敢说中国人只是开源“消费”国?)
如果我们使用Nginx服务器,那么默认的接收缓冲区就是8KB,但是可以改得更大;

如果页面数据比较大,超过8KB,会怎么样? FastCGI进程被挂在render方法上!必须等到Web服务器的缓冲区清空,把页面数据全部接收下来以后,FastCGI进程才能结束本次 Rails调用,处理下一个请求!所以千万别用Apache/Nginx搭配FastCGI应用服务器,否则你的RoR应用会死的很难看。根据我个人的测 试数据表明,同样的测试负载,Apache搭配70个FastCGI进程挂掉,但是Lighttpd搭配30个FastCGI进程轻松跑完!

当FastCGI搭配Lighttpd的时候,我们知道Lighttpd会一次性照单全收FastCGI送过来的页面数据,所以FastCGI进 程并不会被挂住。如果我们对比一下Lighttpd搭配Mongrel和FastCGI会发现,Lighttpd搭配FastCGI性能最好,为什么呢?

Mongrel首先自己会用StringIO缓冲页面数据,然后推送给Lighttpd以后,Lighttpd也在内存当中缓冲了一份页面数据, 造成了毫无必要的double buffer的开销。这自然不如FastCGI不做任何缓冲,直接推给Lighttpd性能来得高,内存消耗少了。

我们的方案分析到这里,大家应该自己心里有结论了,Lighttpd+FastCGI是性能最佳,服务器资源消耗最少的RoR部署方案,事实上目 前RoR网站部署使用最多最流行的也是Lighttpd+FastCGI方式,而JavaEye网站,自然也是这种方式的部署。因此我们可以对各种方案进 行一个性能优劣的排队:


引用
Lighttpd+FastCGI > Lighttpd+Mongrel > Nginx+Mongrel > Apache+Mongrel > Ngignx+FastCGI > Apache+FastCGI

其中Lighttpd+FastCGI是性能最佳方案,而Apache+FastCGI是性能最差方案。


有些细心的同学可能会产生一个新的疑问?你说到底,之所以Lighttpd跑RoR性能最好,还是在于Lighttpd接收数据不限定缓冲区的大 小,而Apache/Nginx限定了缓冲区大小所至。那为什么Nginx要限制呢?Lighttpd如果不限制的话,会不会导致Lighttpd内存爆 掉?

Nginx限制Proxy Buffer Size其实也有道理,因为Nginx并不是为RoR量身打造的Web服务器,Nginx最广泛的用途还是高负载大访问量的代理服务器,在Nginx主要 的应用场合,如果不做这样的限制,那Nginx端的资源消耗就相当高了,有可能会拖累所代理的服务速度。

Lighttpd主要用途之一就是提供高性能的FastCGI支持的Web服务器,所以必须为FastCGI量身打造。Lighttpd端承担的 负载越高,就越能有效的加快FastCGI执行速度。其实我们稍微心算一下,假设Lighttpd后面挂1000个FastCGI进程,每个 FastCGI进程同时送过来50KB的页面数据,Lighttpd就是全部吃下来,也不过只消耗50MB的内存而已,而事实上1000个FastCGI 进程足以支撑每日上千万的大网站了。

只有当我们使用服务器端程序控制大文件下载的时候,有可能造成Lighttpd内存暴涨,例如某个用户使用100个线程并发下载JavaEye圈 子的共享文件,在没有特殊处理的情况下,Lighttpd将全部吃下100个FastCGI进程送过来的10MB数据,就会立刻暴涨1GB的内存。这种情 况怎么办呢?其实我们也有办法让Lighttpd一点内存都不吃, 请看我写的另外一篇文章:RoR网站如何利用lighttpd的X-sendfile功能提升文件下载性能

可能很多人看了我的文章,对结论觉得很诧异,既然Lighttpd+FastCGI这样好,为什么那么多人都推崇Mongrel,否定FastCGI呢?我想,不外乎几个原因:

一、Lighttpd+FastCGI配置起来比较专业,而Mongrel配置简单

尽管我当初第一次搭建Lighttpd+FastCGI环境没费什么周折,但是我观察到非常多的Ruby程序员很难成功搭建一个 Lighttpd+FastCGI的环境出来,很多人连Lighttpd都无法独立的运行起来。这也许是因为很多程序员习惯了Windows开发环境,对 于Unix上面通过源代码编译安装的方式过于陌生造成的。

而我从97年开始使用Unix,至今已有10年历史,因此搭建这样简单的系统,对我来说不造成什 么障碍。

而Mongrel就简单了,gem install mongrel安装完毕,mongrel_rails start启动,哪个人不会?毕竟绝大多数开发人员和部署人员不是高手,他们熟悉哪种方式,自然就会推崇哪种方式。


二、Mongrel可以独立作为Web服务器运行,开发环境和部署环境统一

一般来说,程序员肯定是尽量保持开发环境和部署环境的一致性,避免部署到生产环境出现不测的后果。既然在开发环境熟悉了Mongrel,当然更加愿意在生产环境使用Mongrel,而不愿意碰没有接触过的Lighttpd。


三、Mongrel支持HTTP协议,因此不论监控还是集成其他服务都比较简单,容易玩出更多的花活。

HTTP协议要比FastCGI协议普及的多,因此通过HTTP方式的监控工具,群集管理工具,集成其他服务的工具都是一抓一大把。而支持 FastCGI的第三方工具就少得可怜了。你要玩很多花活出来,用FastCGI的话,就难免得自己开发相应的工具,那当然不如使用Mongrel方便 啦。

 

全能的SQL Server备份帮手——LiteSpeed

http://www.quest.com/documents/landing.aspx?id=8128

 

有两种人经常会需要和数据库打交道——数据库管理员和开发人员——这可不是轻松的事情,然而更不幸
的是我现在同时身兼了这两个职位,如果有办法让我可以更加高效地管理数据库,那绝对会是一件让人感激
的事情。最近才接触到Quest公司出品的LiteSpeed就是一款雪中送炭的产品。需要及时备份数据又不想花费
太多功夫,担心备份占用太多磁盘空间而老板又不给预算购买额外的存储,想要迅速提升数据库开发中的工
作效率?LiteSpeed就是一个不错的选择。

 

end

 

分享到:
评论

相关推荐

    lscache_wp:适用于WordPress的LiteSpeed缓存

    LiteSpeed Web Server是一款高性能的替代Apache或Nginx的Web服务器,提供更快的响应速度和更低的内存占用。 2. **页面静态化**: lscache_wp能够自动将动态WordPress页面转换为静态HTML文件,这大大减少了服务器...

    Debian下手动安装LiteSpeed+PHP+MySQL教程.docx

    3. 安装LiteSpeed Web服务器: 首先访问LiteSpeed官网获取最新版本的下载链接,然后按照以下步骤进行: ``` cd /tmp wget http://litespeedtech.com/packages/4.0/lsws-4.1.13-std-i386-linux.tar.gz tar zxvf lsws*...

    常用的web服务器软件有哪些.doc

    14. LiteSpeed Web Server:商业Web服务器,强调性能和安全性,支持静态内容加速。 15. Miniature JWS (tjws):基于Java,小巧且支持servlet和JSP,性能优于Apache 2.x。 16. Yaws:用Erlang编写,高并发的HTTP/1.1...

    LiteSpeed服务器用htaccess的防盗链代码

    LiteSpeed Web Server 是一款高性能、轻量级的Web服务器软件,它与Apache相似但并不完全兼容,尤其在处理`.htaccess`配置文件时。Apache的`.htaccess`文件用于提供对网站目录的控制,包括重写URL、设置访问权限、...

    TMS WEB Core for RAD Studio 10.3

    快速RAD开发中包含了小而方便的调试webserver ========== FAQ 支持哪些浏览器? Chrome Firefox Safari edge ide支持哪一个? TMS WEB Core可以在Delphi XE7中安装到Delphi东京10.2.x。它可以与专业的,企业和建筑...

    轻量级Web服务器选择

    - **LiteSpeed Web Server**:一款强调性能和安全性的轻量级商业Web服务器。 - **Miniature JWS (tjws)**:基于Java的Web服务器,能够处理servlet、JSP和数千个并发连接,且大小仅为77KB。 - **Yaws**:用Erlang编写...

    可以代替IIS服务器的好工具

    3. ** LiteSpeed Web Server**:这是一个商业级的Web服务器,其性能接近Nginx,但对PHP应用有优化,特别是与WordPress等流行CMS配合时。LiteSpeed也支持自定义端口和主目录,并且与IIS有较好的兼容性,便于迁移。 4...

    Lighting web servers

    2. Apache HTTP Server的轻量级分支:例如Apache HTTPD的LiteSpeed或Apache2的httpd-minimal,保留了核心功能,减少了不必要的模块。 3. Lighttpd:专注于速度和低内存使用,常用于小型网站和动态内容较少的环境。 4...

    programming LSQUIC

    - **历史**:LSQUIC 最初是为了解决 LiteSpeed Web Server 支持 Google QUIC 而开发的。2016 年,目标是为 LiteSpeed Web Server 添加 Google QUIC 支持;2017 年,gQUIC 支持被集成到产品中,并且 LSQUIC 在 GitHub...

    代替网站iis测试网站

    1. **Visual Studio内置Web服务器**:对于.NET开发者,Visual Studio提供了一个内置的Web服务器(称为WebDev.WebServer或IIS Express),可以直接运行ASP.NET应用程序而无需安装完整版的IIS。 2. **XAMPP / WAMP / ...

    代替iis的小工具网上很难找的开发工具

    4. ** LiteSpeed Web Server**:性能优越的轻量级服务器,兼容大部分IIS配置,适合高流量站点。 5. **Nginx**:以其高性能和稳定性著称,常用于反向代理和负载均衡。 6. **Caddy**:现代、自动化且安全的HTTP/2 Web...

    lscache-opencart3.0-V2.2.0.ocmod.zip_WEB开发_PHP__WEB开发_PHP_

    3. ** LiteSpeed Cache (lscache)**:这是一个专门为Litespeed Web Server设计的高性能缓存系统,它可以极大地提高动态网站的加载速度。对于运行在Litespeed上的OpenCart商店,lscache能够缓存页面内容,减少数据库...

    openlitespeed:我们的高性能,轻量级,开源HTTP服务器

    OpenLiteSpeed Web服务器 描述 OpenLiteSpeed是LiteSpeed Technologies开发并拥有版权的高性能,轻量级开源HTTP服务器。 用户可以根据GPLv3许可证的规定自由下载,使用,分发和修改OpenLiteSpeed及其源代码。 这是...

    计算机毕业设计-ASP网上书店管理系统(源代码+LW).zip

    【ASP网上书店管理系统】是一个基于Web的图书销售和管理平台,通常用于计算机科学与技术专业的毕业设计项目。这个系统的设计和实现涵盖了多个IT领域的关键知识点,包括前端开发、后端编程、数据库管理和Web服务器...

    cyberpanel:网络面板-OpenLiteSpeed的托管控制面板

    使用OpenLiteSpeed作为Web服务器的Web主机控制面板。 特征 不同级别的用户。 自动SSL。 FTP服务器。 轻量级DNS服务器(PowerDNS)。 PHPMYAdmin。 电子邮件支持(Rainloop)。 文件管理器。 PHP管理。 ...

    Moodle平台安装教程最详细.doc

    2. Web服务器:Apache是最常用的选择,但Moodle理论上也可在IIS、lighttpd、nginx、cherokee、zeus和LiteSpeed等其他服务器上运行,只是未进行全面测试或官方支持。注意,无论选择哪种Web服务器,都需要确保它配置了...

    ( CentOS 6.0 系统 LAMP(Apache+MySQL+PHP)安装.OK

    【知识点详解】 ...在CentOS 6.0系统上安装LAMP环境,可以按照以下步骤进行: ...在掌握了这些基本技能后,可以进一步探索其他相关技术,比如Perl或Python,以及更高效的Web服务器如Nginx和LiteSpeed。

Global site tag (gtag.js) - Google Analytics