1. Apache服务器和nginx的优缺点：
我们之前大量使用Apache来作为HTTPServer。
Apache具有很优秀的性能，而且通过模块可以提供各种丰富的功能。
1)首先Apache对客户端的响应是支持并发的 ，运行httpd这个daemon进程之后，它会同时产生多个孩子进程/线程，每个孩子进程/线程分别对客户端的请求进行响应；
2)另外，Apache可以提供静态和动态的服务 ，例如对于PHP的解析不是通过性能较差的CGI实现的而是通过支持PHP的模块来实现的(通常为mod_php5，或者叫做apxs2)。
3)缺点:
因此通常称为Apache的这种Server为process-based server ，也就是基于多进程的HTTPServer，因为它需要对每个用户请求创建一个孩子进程/线程进行响应；
这样的缺点是，如果并发的请求非常多(这在大型门户网站是很常见的)就会需要非常多的线程，从而占用极多的系统资源CPU和内存。因此对于并发处理不是Apache的强项。
4)解决方法：
目前来说出现了另一种WebServer，在并发方面表现更加优越，叫做asynchronous servers异步服务器。最有名的为Nginx和Lighttpd。 所谓的异步服务器是事件驱动程序模式的event-driven，除了用户的并发请求通常只需要一个单一的或者几个线程。因此占用系统资源就非常少。这几种又被称为lightweight web server。
举例，对于10,000的并发连接请求，nginx可能仅仅使用几M的内存；而Apache可能需要使用几百M的内存资源。
2. 实际中单一的使用：
1)关于单一使用Apache来作为HTTPServer的情况我们不用再多做介绍，非常常见的应用；
上面我们介绍到Apache对于PHP等服务器端脚本的支持是通过自己的模块来实现的，而且性能优越。
2)我们同样可以单单使用nginx或者lighttpd来作为HTTPServer来使用。
nginx和lighttpd和Apache类似都通过各种模块可以对服务器的功能进行丰富的扩展，同样都是通过conf配置文件对各种选项进行配置。
对于PHP等，nginx和lighttpd都没有内置的模块来对PHP进行支持，而是通过FastCGI来支持的。
Lighttpd通过模块可以提供CGI, FastCGI和SCGI等服务，Lighttpd is capable of automatically spawning FastCGI backends as well as using externally spawned processes.
nginx则没有自己提供处理PHP的功能，需要通过第三方的模块来提供对PHP进行FastCGI方式的集成。
nginx has module support for FastCGI via a built-in module, SCGI and WSGI via 3rd Party module. The user must be able to spawn the processes separately [...]
1)环境：
a. 我们本地是Windows系统，然后使用VirutalBox安装一个虚拟的Linux系统。
在本地的Windows系统上分别安装nginx(侦听8080端口)和apache(侦听80端口)。在虚拟的Linux系统上安装apache(侦听80端口)。
这样我们相当于拥有了1台nginx在前端作为反向代理服务器；后面有2台apache作为应用程序服务器(可以看作是小型的server cluster。;-) )；
b. nginx用来作为反向代理服务器，放置到两台apache之前，作为用户访问的入口；
nginx仅仅处理静态页面，动态的页面(php请求)统统都交付给后台的两台apache来处理。
也就是说，可以把我们网站的静态页面或者文件放置到nginx的目录下；动态的页面和数据库访问都保留到后台的apache服务器上。
c. 如下介绍两种方法实现server cluster的负载均衡。
我们假设前端nginx(为127.0.0.1:80)仅仅包含一个静态页面index.html；
后台的两个apache服务器(分别为localhost:80和158.37.70.143:80)，一台根目录放置phpMyAdmin文件夹和test.php(里面测试代码为print “server1″;)，另一台根目录仅仅放置一个test.php(里面测试代码为print “server2″;)。
2)针对不同请求 的负载均衡：
a. 在最简单地构建反向代理的时候 (nginx仅仅处理静态不处理动态内容，动态内容交给后台的apache server来处理)，我们具体的设置为：在nginx.conf中修改：
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}
>这样当客户端访问localhost:8080/index.html的时候，前端的nginx会自动进行响应；
>当用户访问localhost:8080/test.php的时候(这个时候nginx目录下根本就没有该文件)，但是通过上面的设置location ~ \.php$(表示正则表达式匹配以.php结尾的文件，详情参看location是如何定义和匹配的http://wiki.nginx.org/NginxHttpCoreModule) ，nginx服务器会自动pass给158.37.70.143的apache服务器了。该服务器下的test.php就会被自动解析，然后将html的结果页面返回给nginx，然后nginx进行显示(如果nginx使用memcached模块或者squid还可以支持缓存)，输出结果为打印server2。
如上是最为简单的使用nginx做为反向代理服务器的例子；
b. 我们现在对如上例子进行扩展，使其支持如上的两台服务器。
我们设置nginx.conf的server模块部分，将对应部分修改为：
location ^~ /phpMyAdmin/ {
proxy_pass 127.0.0.1:80 ;
}
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}
上面第一个部分location ^~ /phpMyAdmin/，表示不使用正则表达式匹配(^~)，而是直接匹配，也就是如果客户端访问的URL是以http://localhost:8080/phpMyAdmin/ [...]
Also filed in
|
Tagged Nginx
|
1. 安装认证(Setup up SSL)
sudo apt-get install ssl-cert
sudo mkdir /etc/apache2/ssl
sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem
2. 安装ssl模块
The mod_ssl module adds an important feature to the Apache2 server – the ability to encrypt ommunications. Thus, when your browser is communicating using SSL encryption, the https:// prefix is used at the beginning of the Uniform Resource Locator (URL) in the [...]
REST的架构设计
REST（Representational State Transfer）是一种轻量级的Web Service架构风格，其实现和操作明显比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。
REST架构遵循了CRUD原则，CRUD原则对于资源只需要四种行为：Create（创建）、Read（读取）、Update（更新）和Delete（删除）就可以完成对其操作和处理。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。
REST架构让人们真正理解我们的网络协议HTTP本来面貌，对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法，因此REST把HTTP对一个URL资源的操作限制在GET、POST、PUT和DELETE这四个之内。这种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性
REST的设计准则
REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则：
1) 网络上的所有事物都被抽象为资源（resource）；
2) 每个资源对应一个唯一的资源标识符（resource identifier）；
[...]
1、Rewrite规则简介：
Rewirte主要的功能就是实现URL的跳转，它的正则表达式是基于Perl语言。可基于服务器级的(httpd.conf)和目录级的(.htaccess)两种方式。如果要想用到rewrite模块，必须先安装或加载rewrite模块。方法有两种一种是编译apache的时候就直接安装rewrite模块，别一种是编译apache时以DSO模式安装apache,然后再利用源码和apxs来安装rewrite模块。
基于服务器级的(httpd.conf)有两种方法，一种是在httpd.conf的全局下直接利用RewriteEngine on来打开rewrite功能;另一种是在局部里利用RewriteEngine on来打开rewrite功能,下面将会举例说明，需要注意的是,必须在每个virtualhost里用RewriteEngine on来打开rewrite功能。否则virtualhost里没有RewriteEngine on它里面的规则也不会生效。
基于目录级的(.htaccess),要注意一点那就是必须打开此目录的FollowSymLinks属性且在.htaccess里要声明RewriteEngine on。
2、举例说明：
下面是在一个虚拟主机里定义的规则。功能是把client请求的主机前缀不是www.colorme.com和203.81.23.202都跳转到主机前缀为http://www.colorme.com.cn，避免当用户在地址栏写入http://colorme.com.cn时不能以会员方式登录网站。
NameVirtualHost 192.168.100.8:80
ServerAdmin webmaster@colorme.com.cn
DocumentRoot “/web/webapp”
ServerName www.colorme.com.cn
ServerName colorme.com.cn
RewriteEngine on #打开rewirte功能
RewriteCond %{HTTP_HOST} !^www.colorme.com.cn [NC]
#声明Client请求的主机中前缀不www.colorme.com.cn,[NC]的意思是忽略大小写
RewriteCond %{HTTP_HOST} !^203.81.23.202 [NC]
#声明Client请求的主机中前缀不是203.81.23.202,[NC]的意思是忽略大小写
RewriteCond %{HTTP_HOST} !^$ #声明Client请求的主机中前缀不为空,[NC]的意思是忽略大小写
RewriteRule ^/(.*) http://www.colorme.com.cn/ [L]
#含义是如果Client请求的主机中的前缀符合上述条件，
#则直接进行跳转到http://www.colorme.com.cn/,[L]意味着立即停止重写操作，并不再应用其他重写规则。
#这里的.*是指匹配所有URL中不包含换行字符，()括号的功能是把所有的字符做一个标记，
#以便于后面的应用.就是引用前面里的(.*)字符。
例二.将输入 folio.test.com 的域名时跳转到profile.test.com
listen 8080
NameVirtualHost 10.122.89.106:8080
ServerAdmin webmaster@colorme.com.cn
DocumentRoot “/usr/local/www/apache22/data1/”
ServerName profile.test.com
RewriteEngine on
RewriteCond %{HTTP_HOST} ^folio.test.com [NC]
RewriteRule ^/(.*) http://profile.test.com/ [L]
3.Apache mod_rewrite规则重写的标志一览
1) R[=code](force redirect) 强制外部重定向
强制在替代字符串加上http://thishost[:thisport]/前缀重定向到外部的URL.如果code不指定，将用缺省的302 HTTP状态码。
2) F(force URL to be forbidden)禁用URL,返回403HTTP状态码。
3) G(force URL to be gone) [...]
Sina App Engine(SAE)，是由新浪公司开发和运营的开放云计算平台的核心组成部分。SAE的目标是实现互联网应用在开发运维上的无缝整合，为App开发者提供稳定、快捷、透明、可控的服务化的平台，同时减少开发者的开发和维护成本。
Sina App Engine是用来做什么的？下面是官方的介绍文本：
SAE的目标是实现互联网应用在开发运维上的无缝整合,为App开发者提供稳定、快捷、透明、可控的服务化的平台，同时减少开发者的开发和维护成本。
目前Sina App Engine需要邀请码注册。
官方的教学视频 http://sae.sina.com.cn/static/flash/video/SaeQuickStart.htm
SAE开发者文档中心 http://wiki.sae.sina.com.cn/doku.php
SAE官方blog: http://blog.sae.sina.com.cn (值得一提的是没有用sina自己的新浪blog，而是开源的wordpress)
一、访问日志的格式
Apache内建了记录服务器活动的功能，这就是它的日志功能。我们将介绍的就是Apache的访问日志、错误日志，以及如何分析日志数据，如何定制Apache日志，如何从日志数据生成统计报表等内容。
如果Apache的安装方式是默认安装，服务器一运行就会有两个日志文件生成。这两个文件是access_log和error_log。采用默认安装方式时，这些文件可以在/var/log/apache下找到, 不同的包管理器会把日志文件放到各种不同的位置，所以你可能需要找找其他的地方，或者通过配置文件查看这些日志文件配置到了什么地方。
正如其名字所示，访问日志access_log记录了所有对Web服务器的访问活动。下面是访问日志中一个典型的记录：
72.14.199.121 – – [19/Aug/2009:14:47:37 -0400] “GET / HTTP/1.0″ 200 654
这行内容由7项构成，上面的例子中有两项空白，但整行内容仍旧分成了7项。
第一项信息是远程主机的地址，即它表明访问网站的究竟是谁。在上面的例子中，访问网站的主机是216.35.116.91。随便说一
句，这个地址属于一台名为NS4.google.com的机器（要找出这个信息，可以使用nslookup工具查找DNS）。可以看出，仅仅从日志记录的第一项出发，我们就可以得到有关访问者的不少信息。
默认情况下，第一项信息只是远程主机的IP地址，但我们可以要求Apache查出所有的主机名字，并在日志文件中用主机名字来替代IP地址。然而，这种做法通常不值得推荐，因为它将极大地影响服务器记录日志的速度，从而也就减低了整个网站的效率。另外，有许多工具能够将日志文件中的IP地址转换成主机名字，因此要求Apache记录主机名字替代IP地址是得不偿失的。
然而，如果确实有必要让Apache找出远程主机的名字，那么我们可以使用如下指令：
HostNameLookups on
如果HostNameLookups设置成double而不是on，日志记录程序将对它找到的主机名字进行反向查找，验证该主机名字确实指向了原来出现的IP地址。默认情况下HostNameLookups设置为off。
上例日志记录中的第二项是空白，用一个“-”占位符替代。实际上绝大多数时候这一项都是如此。这个位置用于记录浏览者的标识，这不只是浏览者的登录名字，而是浏览者的email地址或者其他唯一标识符。这个信息由identd返回，或者直接由浏览器返回。很早的时候，那时Netscape 0.9还占据着统治地位，这个位置往往记录着浏览者的email地址。然而，由于有人用它来收集邮件地址和发送垃圾邮件，所以它未能保留多久，很久之前市场上几乎所有的浏览器就取消了这项功能。因此，到了今天，我们在日志记录的第二项看到email地址的机会已经微乎其微了。
日志记录的第三项也是空白。这个位置用于记录浏览者进行身份验证时提供的名字。当然，如果网站的某些内容要求用户进行身份验证，那么这项信息是不会空白的。但是，对于大多数网站来说，日志文件的大多数记录中这一项仍旧是空白的。
日志记录的第四项是请求的时间。这个信息用方括号包围，而且采用所谓的“公共日志格式”或“标准英文格式”。因此，上例日志记录表示请求的时间是2009年8月19日星期三14:47:37。时间信息最后的“-0400”表示服务器所处时区位于UTC之前的4小时。
日志记录的第五项信息或许是整个日志记录中最有用的信息，它告诉我们服务器收到的是一个什么样的请求。该项信息的典型格式是“METHOD RESOURCE PROTOCOL”，即“方法 资源 协议”。
在上例中，METHOD是GET，其他经常可能出现的METHOD还有POST和HEAD。此外还有不少可能出现的合法METHOD，但主要就是这三种。
RESOURCE是指浏览者向服务器请求的文档，或URL。在这个例子中，浏览者请求的是“/”，即网站的主页或根。大多数情况下，“/”指向DocumentRoot目录的index.html文档，但根据服务器配置的不同它也可能指向其他文件。
PROTOCOL通常是HTTP，后面再加上版本号。版本号或者是1.0，或者是1.1，但出现1.0的时候比较多。我们知道，HTTP协议是Web得以工作的基础，HTTP/1.0是HTTP协议的早期版本，而1.1是最近的版本。当前大多数Web客户程序仍使用1.0版本的HTTP协议。
日志记录的第六项信息是状态代码。它告诉我们请求是否成功，或者遇到了什么样的错误。大多数时候，这项值是200，它表示服务器已经成功地响应浏览器的请求，一切正常。此处不准备给出状态代码的完整清单以及解释它们的含义，请参考相关资料了解这方面的信息。但一般地说，以2开头的状态代码表示成功，以3开头的状态代码表示由于各种不同的原因用户请求被重定向到了其他位置，以4开头的状态代码表示客户端存在某种错误，以5开头的状态代码表示服务器遇到了某个错误。
日志记录的第七项表示发送给客户端的总字节数。它告诉我们传输是否被打断（即，该数值是否和文件的大小相同）。把日志记录中的这些值加起来就可以得知服务器在一天、一周或者一月内发送了多少数据。
二、配置访问日志
访问日志文件的位置实际上是一个配置选项。如果我们检查httpd.conf配置文件，可以看到该文件中有如下这行内容：
CustomLog /usr/local/apache/logs/access_log common
CustomLog指令指定了保存日志文件的具体位置以及日志的格式。至于如何定制日志文件的格式以及内容，我们将在这个
上面这行指令指定的是common日志格式，自从有了Web服务器开始，common格式就是它的标准格式。由此我们也可以理解，虽然几乎不再有任何客户程序向服务器提供用户的标识信息，但访问日志却还保留着第二项内容。
CustomLog指令中的路径是日志文件的路径。注意，由于日志文件是由HTTP用户打开的（用User指令指定），因此必须注意这个路径要有安全保证，防止该文件被随意改写。
APC概要
APC,全称是Alternative PHP Cache.The Alternative PHP Cache (APC) is a free and open opcode cache for PHP. Its goal is to provide a free, open, and robust framework for caching and optimizing PHP intermediate code.
Office Website: http://pecl.php.net /package/apc. 目前的版本是 3.1.3 (2009-08-13)
APC的安装
1. 源码安装
下载源码 http://pecl.php.net/package/APC
解压 安装
$ /usr/local/php/bin/phpize
$ ./configure –enable-apc –enable-apc-mmap –with-php-config=/usr/local/php/bin/php-config
$ make
$ make install
$ cp /usr/local/php/lib/php/extensions/no-debug-zts/apc.so /usr/local/php/lib/php/extensions/apc.so
$ [...]
Also filed in
|
Tagged APC, PHP
|
Apache 为改善HTTP的”‘keep alive”问题，在2.0版本上引入了MPM（Multi -Processing Modules，多道处理模块）
prefork的工作原理及配置
如果不用“–with-mpm”显式指定某种MPM，prefork就是Unix平台上缺省的MPM。它所采用的预派生子进程方式也是 Apache 1.3中采用的模式。prefork本身并没有使用到线程，2.0版使用它是为了与1.3版保持兼容性；另一方面，prefork用单独的子进程来处理不同的请求，进程之间是彼此独立的，这也使其成为最稳定的MPM之一。
若使用prefork，在make编译和make install安装后，使用“httpd -l”来确定当前使用的MPM，应该会看到prefork.c（如果看到worker.c说明使用的是worker MPM，依此类推）。
缺省生成的httpd.conf配置文件，里面包含如下配置段：
<IfModule prefork.c>;
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>;
prefork的工作原理是，控制进程在最初建立“StartServers”个子进程后，为了满足MinSpareServers设置的需要创建一个进程，等待一秒钟，继续创建两个，再等待一秒钟，继续创建四个……如此按指数级增加创建的进程数，最多达到每秒32个，直到满足 MinSpareServers设置的值为止。这就是预派生（prefork）的由来。这种模式可以不必在请求到来时再产生新的进程，从而减小了系统开销以增加性能。
MaxSpareServers设置了最大的空闲进程数，如果空闲进程数大于这个值，Apache会自动kill掉一些多余进程。这个值不要设得过大，但如果设的值比MinSpareServers小，Apache会自动把其调整为MinSpareServers+1。如果站点负载较大，可考虑同时加大MinSpareServers和MaxSpareServers。
MaxRequestsPerChild设置的是每个子进程可处理的请求数。每个子进程在处理了“MaxRequestsPerChild” 个请求后将自动销毁。0意味着无限，即子进程永不销毁。虽然缺省设为0可以使每个子进程处理更多的请求，但如果设成非零值也有两点重要的好处：
◆ 可防止意外的内存泄漏；
◆ 在服务器负载下降的时侯会自动减少子进程数。
MaxClients是这些指令中最为重要的一个，设定的是Apache可以同时处理的请求，是对Apache性能影响最大的参数。其缺省值 150是远远不够的，如果请求总数已达到这个值（可通过ps -ef|grep http|wc -l来确认），那么后面的请求就要排队，直到某个已处理请求完毕。这就是系统资源还剩下很多而HTTP访问却很慢的主要原因。系统管理员可以根据硬件配置和负载情况来动态调整这个值。虽然理论上这个值越大，可以处理的请求就越多，但Apache默认的限制不能大于256。如果把这个值设为大于256，那么 Apache将无法起动。事实上，256对于负载稍重的站点也是不够的。在Apache 1.3中，这是个硬限制。如果要加大这个值，必须在“configure”前手工修改的源代码树下的src/include/httpd.h中查找 256，就会发现“#define HARD_SERVER_LIMIT 256”这行。把256改为要增大的值（如4000），然后重新编译Apache即可。在Apache 2.0中新加入了ServerLimit指令，使得无须重编译Apache就可以加大MaxClients。
worker的工作原理及配置
相对于prefork，worker是2.0 版中全新的支持多线程和多进程混合模型的MPM。由于使用线程来处理，所以可以处理相对海量的请求，而系统资源的开销要小于基于进程的服务器。但是， worker也使用了多进程，每个进程又生成多个线程，以获得基于进程服务器的稳定性。这种MPM的工作方式将是Apache 2.0的发展趋势。
在configure -with-mpm=worker后，进行make编译、make install安装。在缺省生成的httpd.conf中有以下配置段：
<IfModule worker.c>
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>;
worker的工作原理是，由主控制进程生成“StartServers”个子进程，每个子进程中包含固定的ThreadsPerChild 线程数，各个线程独立地处理请求。同样，为了不在请求到来时再生成线程，MinSpareThreads和MaxSpareThreads设置了最少和最多的空闲线程数；而MaxClients设置了所有子进程中的线程总数。如果现有子进程中的线程总数不能满足负载，控制进程将派生新的子进程。
MinSpareThreads和MaxSpareThreads的最大缺省值分别是75和250。这两个参数对Apache的性能影响并不大，可以按照实际情况相应调节。
ThreadsPerChild是worker MPM中与性能相关最密切的指令。ThreadsPerChild的最大缺省值是64，如果负载较大，64也是不够的。这时要显式使用 ThreadLimit指令，它的最大缺省值是20000。上述两个值位于源码树server/mpm/worker/worker.c中的以下两行：
#define DEFAULT_THREAD_LIMIT 64
#define MAX_THREAD_LIMIT 20000
这两行对应着ThreadsPerChild和ThreadLimit的限制数。最好在configure之前就把64改成所希望的值。注意，不要把这两个值设得太高，超过系统的处理能力，从而因Apache不起动使系统很不稳定。
Worker模式下所能同时处理的请求总数是由子进程总数乘以ThreadsPerChild值决定的，应该大于等于MaxClients。如果负载很大，现有的子进程数不能满足时，控制进程会派生新的子进程。默认最大的子进程总数是16，加大时也需要显式声明ServerLimit（最大值是20000）。这两个值位于源码树server/mpm/worker/worker.c中的以下两行：
#define DEFAULT_SERVER_LIMIT 16
#define MAX_SERVER_LIMIT 20000
需要注意的是，如果显式声明了ServerLimit，那么它乘以ThreadsPerChild的值必须大于等于MaxClients，而且MaxClients必须是ThreadsPerChild的整数倍，否则Apache将会自动调节到一个相应值（可能是个非期望值）。