web服务器

三大WEB服务器对比分析(apache ,lighttpd,nginx)

谁说我不能喝 提交于 2020-01-02 01:07:51
一.软件介绍 (apache lighttpd nginx) 1. lighttpd Lighttpd 是一个具有非常低的内存开销, cpu 占用率低,效能好,以及丰富的模块等特点。 lighttpd 是众多 OpenSource 轻量级的 web server 中较为优秀的一个。支持 FastCGI, CGI, Auth, 输出压缩 (output compress), URL 重写 , Alias 等重要功能。 Lighttpd 使用 fastcgi 方式运行 php, 它会使用很少的 PHP 进程响应很大的并发量。 Fastcgi 的优点在于: · 从稳定性上看 , fastcgi 是以独立的进程池运行来 cgi, 单独一个进程死掉 , 系统可以很轻易的丢弃 , 然后重新分配新的进程来运行逻辑 . · 从安全性上看 , fastcgi 和宿主的 server 完全独立 , fastcgi 怎么 down 也不会把 server 搞垮 , · 从性能上看 , fastcgi 把动态逻辑的处理从 server 中分离出来 , 大负荷的 IO 处理还是留给宿主 server, 这样宿主 server 可以一心一意作 IO, 对于一个普通的动态网页来说 , 逻辑处理可能只有一小部分 , 大量的图片等静态 IO 处理完全不需要逻辑程序的参与 ( 注 1) · 从扩展性上讲 ,

三大WEB服务器对比分析(apache ,lighttpd,nginx)

爱⌒轻易说出口 提交于 2020-01-02 01:07:32
一.软件介绍(apache lighttpd nginx) 1. lighttpd Lighttpd是一个具有非常低的内存开销,cpu占用率低,效能好,以及丰富的模块等特点。lighttpd是众多OpenSource轻量级的web server中较为优秀的一个。支持FastCGI, CGI, Auth, 输出压缩(output compress), URL重写, Alias等重要功能。 Lighttpd使用fastcgi方式运行php,它会使用很少的PHP进程响应很大的并发量。 Fastcgi的优点在于: · 从稳定性上看, fastcgi是以独立的进程池运行来cgi,单独一个进程死掉,系统可以很轻易的丢弃,然后重新分配新的进程来运行逻辑. · 从安全性上看, fastcgi和宿主的server完全独立, fastcgi怎么down也不会把server搞垮, · 从性能上看, fastcgi把动态逻辑的处理从server中分离出来, 大负荷的IO处理还是留给宿主server, 这样宿主server可以一心一意作IO,对于一个普通的动态网页来说, 逻辑处理可能只有一小部分, 大量的图片等静态IO处理完全不需要逻辑程序的参与(注1) · 从扩展性上讲, fastcgi是一个中立的技术标准, 完全可以支持任何语言写的处理程序(php,java,python...) 2.apache

三大WEB服务器对比分析(apache ,lighttpd,nginx)

耗尽温柔 提交于 2020-01-02 01:06:23
三大WEB服务器对比分析(apache ,lighttpd,nginx) 一.软件介绍 (apache lighttpd nginx) 1. lighttpd Lighttpd是一个具有非常低的内存开销,cpu占用率低,效能好,以及丰富的模块等特点。lighttpd是众多OpenSource轻量级的web server中较为优秀的一个。支持FastCGI, CGI, Auth, 输出压缩(output compress), URL重写, Alias等重要功能。 Lighttpd使用fastcgi方式运行php,它会使用很少的PHP进程响应很大的并发量。 Fastcgi的优点在于: · 从稳定性上看, fastcgi是以独立的进程池运行来cgi,单独一个进程死掉,系统可以很轻易的丢弃,然后重新分配新的进程来运行逻辑. · 从安全性上看, fastcgi和宿主的server完全独立, fastcgi怎么down也不会把server搞垮, · 从性能上看, fastcgi把动态逻辑的处理从server中分离出来, 大负荷的IO处理还是留给宿主server, 这样宿主server可以一心一意作IO,对于一个普通的动态网页来说, 逻辑处理可能只有一小部分, 大量的图片等静态IO处理完全不需要逻辑程序的参与(注1) · 从扩展性上讲, fastcgi是一个中立的技术标准,

如何启用编辑并继续?

一笑奈何 提交于 2020-01-02 00:12:05
VS2005优点:自动调整中间的空格, 自动弹出变量, 编辑并继续 开发ASP.NET程序,我在VB6中的坏习惯,边运行边改程序。但到VS2003居然不能用了,效率不知降了多少。后来装了VS2005,系统是说有“编辑并继续”的功能,但我没有启用成功,并且看到网络上很多人的悲观说法都是对ASP.NET无效。 后来发现,只要在“项目”->“某工程属性”->“Web”页签,把“服务器”那一部分选择“使用Visual Studio Development Server”,底下的“启用编辑并继续”打勾即可。这样设,可能无法直接对远端的WEB服务器进行调试,但我的习惯都是本机调好,再上传到服务器上,没有在WEB上直接调过。 至于工具菜单中如何设置都不是问题。 补充:怎么这么多人都说找不到。不过我现在是用VS2008,抓图如下: 来源: https://www.cnblogs.com/yzx99/archive/2008/08/02/1258706.html

nginx介绍

最后都变了- 提交于 2020-01-01 22:41:21
1.2 WEB服务器 nginx 开源的,支持高性能,高并发的 apache nginx他父亲 IIS(windows下面的WEB Server) 1.3 查看WEB服务器信息 使用curl -I 命令查看taobao和JD的WEB服务器 1.4 nginx的优点: 1.4.1 占有内存少,并发能力强 1.4.2 处理静态文件 静态文件与动态文件的区别 静态文件: css js jpg png mp4动态数据: 网站会请求后端的数据库接口,获取最新的数据,这些数据就是动态数据 1.4.3 百度、京东、新浪、网易、腾讯、淘宝都在用nginx 1.4.4 一台机器只有一个80端口,假如我们想要跑多个WEB服务器呢? 2 安装nginx步骤 2.0 首先卸载掉之前安装的nginx yum remove nginx 2.1 安装nginx需要的依赖库 yum install -y gcc patch libffi-devel python-devel zlib-devel bzip2-devel openssl openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel 2.2 下载安装nginx源码包 cd /optwget -c

B/S架构及其运行原理

喜你入骨 提交于 2020-01-01 13:15:11
在公司做B/S 开发与维护三年啦, 对B/S架构的了解也是只知大概,对于这种基础知识还是很有必要理一理哒。趁空去网上查阅了资料,顺便整理一份笔记供以后查询。 大多内容参照http://blog.csdn.net/wang13667539325/article/details/19178349。 一. B/S的概念 B/S(Brower/Server,浏览器/服务器)模式又称B/S结构,是Web兴起后的一种网络结构模式。Web浏览器是客户端最主要的应用软件。 这种模式统一了客户端,将系统功能实现的核心部分集中到服务器上,简化了系统的开发、维护和使用; 客户机上只需要安装一个浏览器,服务器上安装SQL Server, Oracle, MySql等数据库;浏览器通过Web Server同数据库进行数据交互。   二. B/S工作原理 B/S架构采取浏览器请求,服务器响应的工作模式。 用户可以通过浏览器去访问Internet上由Web服务器产生的文本、数据、图片、动画、视频点播和声音等信息; 而每一个 Web 服务器又可以通过各种方式与数据库服务器连接,大量的数据实际存放在数据库服务器中 ; 从 Web 服务器上下载程序到本地来执行,在下载过程中若遇到与数据库有关的指令,由 Web 服务器交给数据库服务器来解释执行,并返回给 Web 服务器, Web 服务器又返回给用户 。在这种结构中

几款Web服务器性能压力测试工具

北城余情 提交于 2020-01-01 09:02:52
一、http_load 程序非常小,解压后也不到100K http_load以并行复用的方式运行,用以 测试 web服务器的吞吐量与负载。 但是它不同于大多数压力测试工具,它可以以一个单一的进程运行,一般不会把客户机搞死。 还可以测试HTTPS类的网站请求。 下载地址: http_load-12mar2006.tar.gz 安装很简单 #tar zxvf http_load-12mar2006.tar.gz #cd http_load-12mar2006 #make && make install 基本用法: http_load -p 并发访问进程数 -s 访问时间 需要访问的URL文件 参数其实可以自由组合,参数之间的选择并没有什么限制。 比如你写成http_load -parallel 5 -seconds 300 urllist.txt也是可以的。 我们把参数给大家简单说明一下。 -parallel 简写-p :含义是并发的用户进程数。 -fetches 简写-f :含义是总计的访问次数 -rate 简写-p :含义是每秒的访问频率 -seconds 简写-s :含义是总计的访问时间 准备URL文件:urllist.txt,文件格式是每行一个URL,URL最好超过50-100个测试效果比较好。 文件格式如下: http://www.qixing318.com/ http:/

如何构建可伸缩的Web应用?

别说谁变了你拦得住时间么 提交于 2020-01-01 02:59:59
为什么要构建可伸缩的Web应用? 想象一下,你的营销活动吸引了很多用户,在某个时候,应用必须同时为成千上万的用户提供服务,这么大的并发量,服务器的负载会很大,如果设计不当,系统将无法处理。 接下来发生的就是,随机错误、缓慢的内容加载、无休止的等待、连接断开、服务不可用等问题。 辛辛苦苦吸引来的用户变成了系统的攻击者,把服务器资源耗尽,应用程序崩溃。 你的大多数用户将丢失,产品评级将降低,市场将充满负面评论。 所以, 可伸缩性 已经成为Web应用程序的DNA。 可伸缩应用架构简介 可伸缩架构的两个主要原则: 关注点分离 水平扩展 关注点分离 每个类型的任务都应该有一个独立的服务器。 有时,应用程序是由一台服务器完成全部工作:处理用户请求,存储用户文件等。 它完成的工作通常应由几台单独的服务器完成。 因此,当服务器过载时,整个应用程序将受到影响:页面无法打开,图像无法加载等。 为避免这种情况,需要确保关注点分离。 例如,API server 处理需要即时回复的 client-server 请求。 假设某个用户更改其个人资料图像,上载图像后,通常会对其进行一定的处理:调整图像大小、分析显式内容、保存在存储中 …… 显然,这个过程复杂而耗时,而且用户不需要等待处理完成。因此,这个任务的优先级较低,因为它不需要一个实时的结果回复。 这是为什么它不应该放在 API server。

大型网站系统架构分析

十年热恋 提交于 2019-12-30 23:31:19
千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用什么系统架构保证性能和稳定性? 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 :负载量不大的情况下select、delete和update是响应很迅速的,最多加几个索引就可以搞定,但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下,更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 :平时我们感觉不到,但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 :大型网站有海量图片数据、视频数据、文件数据等等,他们如何存储并被有效索引?高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题,但是还有个问题就是各地的访问问题,也许我们的服务器在北京,可能在云南或者新疆的访问速度如何解决?如果做分布式,那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构,来有效的解决上述问题。 毋庸置疑,对于规模稍大的网站来说,其背后必然是一个服务器集群来提供网站服务,例如,2004年eBay的服务器有2400台,估计现在更多。当然,数据库也必然要和应用服务分开,有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言,就是应用也分成很多组。 下面

大型网站系统架构分析

谁说我不能喝 提交于 2019-12-30 23:30:56
千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用什么系统架构保证性能和稳定性? 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 :负载量不大的情况下select、delete和update是响应很迅速的,最多加几个索引就可以搞定,但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下,更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 :平时我们感觉不到,但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 :大型网站有海量图片数据、视频数据、文件数据等等,他们如何存储并被有效索引?高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题,但是还有个问题就是各地的访问问题,也许我们的服务器在北京,可能在云南或者海南的访问速度如何解决?如果做分布式,那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构,来有效的解决上述问题。 毋庸置疑,对于规模稍大的网站来说,其背后必然是一个服务器集群来提供网站服务,例如,2004年eBay的服务器有2400台,估计现在更多。当然,数据库也必然要和应用服务分开,有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言,就是应用也分成很多组。 下面