WEB服务器 - Apache、Nnginx、Lighttpd的比较和择优

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 because nginx is not able to automatically spawn them [9]. nginx does not support normal CGI applications [10], which is actually a security benefit.

Lighttpd vs nginx
http://www.wikivs.com/wiki/Lighttpd_vs_nginx

3.反向代理Reverse Proxy:
0) 代理服务器的概念proxy server:

代理服务器

的概念很容易理解,就是通常作为两台机器中间的机器,需要提供的功能往往有:

缓 存caching,安全, 负载均衡load banlancing。

所谓的负载均衡就是,很多机器使用一个代理的时候,代理服务器需要对各个服务器进行均衡。
我们常见的代理是正向的代理,例如我们机房有20台电脑要上网,现在只有一个电脑可以上网,那么可以使用这台电脑作为代理服务器,所有通过网络的数据传输 都要经过该代理服务器。

而反向代理,是和正向代理相反的
,正向代理针对服务接收方用户来说,反向代理或者叫做服务器端代理是针对服务器端的,意思是有多台服务器,反向代理服务器对用户的请求代理发送给其中的一 台服务器进行处理。

Proxy server
http://en.wikipedia.org/wiki/Proxy_server

1)
实际中对于一个大型网站,我们通常使用很多台sever来构成一个cluster来对用户的各种请求进行响应。
因此通常需要一台或者多台反向代理服务器来对多台Server进行服务。
这个反向代理服务器需要提供的功能一般都包括:
    安全方面;缓存压缩功能;负载均衡 功能;

Reverse proxy
http://en.wikipedia.org/wiki/Reverse_proxy

(需要注意反向代理服务器和防火墙优点类似,但是防火墙一般只有安全方面的考虑,没有缓存和负载均衡方面的功能。)

3) 综上,实际中Web服务器端的架构
通常是多台Web服务器运行并行地提 供服务;同时还需要在Web服务器前段部署一台或者多台反向代理服务器,一方面缓存一些静态数据,或者将Web服务器动态产生的一些内容缓存,另一方面通 过负载均衡功能,可以均匀地将用户的并发请求传递给多台Web服务器进行处理。

这样一方面可以大大降低后面每台Web服务器的负担;另一方 面可以实现多台服务器的负载均衡。

4. 实际中使用nginx或者lighttpd当做反向代理服务器,后台布置多台ApacheHTTPServer:
1)上面说到,nginx和lighttpd的优点在于速度快,轻量级,在处理多用户并发方面要大大优于Apache服务器。
因此我们通常可以把他们作为反向代理服务器放置到多台的Apache Web服务器前段,来一方面缓存数据,另一方面实现多台服务器的负载均衡。
2) 当然了Apache本身通过mod_proxy和mod_cache也可以实现反向代理和缓存功能
,但是在处理高并发方面还是无法与nginx和lighttpd这种轻量的异步模式的服务器来比较。
3)另外,利用nginx和lighttpd的反响代理功 能,我们可以通过设置其configuration文件,当客户端请求的是静态内容(例如一些图片,js,html文件等)的话,直接由nginx或者 lighttpd进行响应;

如果需要访问动态内容(通常需要实时从数据库中读取)的话, 则通过反向代理,nginx等可以将请求发送给后台等待的Apache进行响应,然后Apache将相应的结果返回给nginx,后者再响应用户的时候还 可以进行缓存。
4)有时候还可以使用一些缓存的工具,例如Squid。
另外nginx也提供了对一些缓存功能的支持,例如memcache
等。

5)因此如果从图形来分析的话,通常的架构如下:

nginx作为最前端的web cache系统

这个结构的优点:

1、可以使用nginx前端进行诸多复杂的配置,这些配置从前在squid是没法做或者做起来比较麻烦的,比如针对目录的防盗链。

2、nginx前端可以直接转发部分不需要缓存的请求。

3、因为nginx效率高于squid,所以某些情况下可以利用nginx的缓存来减轻squid压力。

4、可以实现url hash等分配策略。

5、可以在最前端开启gzip压缩,这样后面的squid缓存的纯粹是无压缩文档,可以避免很多无谓的穿透。

6、因为nginx稳定性比较高,所以lvs不需要经常调整,通过nginx调整就可以。

7、squid的文件打开数按默认的1024就绰绰有余,不过处理的请求可一个都不会少。

8、可以启用nginx的日志功能取代squid,这样做实时点击量统计时可以精确定位到url,不必要再用低效率的grep来过滤。

9、因为nginx的负载能力高于squid,所以在用lvs分流时可以不必分得特别均衡,出现单点故障的几率比较低。

nginx和squid配合搭建的web服务器前端系统

前端的lvs和squid,按照安装方法,把epoll打开,配置文件照搬,基本上问题不多。

这个架构和app_squid架构的区别,也是关键点就是:加入了一级中层代理,中层代理的好处实在太多了:

1、gzip压缩

压缩可以通过nginx做,这样,后台应用服务器不管是apache、resin、lighttpd甚至iis或其他古怪服务器,都不用考虑压缩的功能问 题。

2、负载均衡和故障屏蔽

nginx可以作为负载均衡代理使用,并有故障屏蔽功能,这样,根据目录甚至一个正则表达式来制定负载均衡策略变成了小case。

3、方便的运维管理,在各种情况下可以灵活制订方案。

例如,如果有人用轻量级的ddos穿透squid进行攻击,可以在中层代理想办法处理掉;访问量和后台负载突变时,可以随时把一个域名或一个目录的请求扔 入二级cache服务器;可以很容易地控制no-cache和expires等header。等等功能。。。

4、权限清晰

这台机器就是不写程序的维护人员负责,程序员一般不需要管理这台机器,这样假如出现故障,很容易能找到正确的人。

对于应用服务器和数据库服务器,最好是从维护人员的视线中消失,我的目标是,这些服务只要能跑得起来就可以了,其它的事情全部可以在外部处理掉。

General Architecture of LVS Clusters

For transparency, scalability, availability and manageability of the whole system, we usually adopt three-tie architecture in LVS clusters illustrated in the following figure.

The three-tie architecture consists of

  • Load Balancer
    , which is the front-end machine of the whole cluster systems, and balances requests from clients among a set of servers, so that the clients consider that all the services is from a single IP address.
  • Server Cluster
    , which is a set of servers running actual network services, such as Web, Mail, FTP, DNS and Media service.
  • Shared Storage
    , which provides a shared storage space for the servers, so that it is easy for the servers to have the same contents and provide the same services.

Load balancer is the single entry-point of server cluster systems, it can run IPVS
that implements IP load balancing techniques inside the Linux kernel, or KTCPVS
that implements application-level load balancing inside the Linux kernel. When IPVS is used, all the servers are required to provide the same services and contents, the load balancer forward a new client request to a server according to the specified scheduling algorithms and the load of each server. No matter which server is selected, the client should get the same result. When KTCPVS is used, servers can have different contents, the load balancer can forward a request to a different server according to the content of request. Since KTCPVS is implemented inside the Linux kernel, the overhead of relaying data is minimal, so that it can still have high throughput.

The node number of server cluster can be changed according to the load that system receives. When all the servers are overloaded, more new servers can be added to handle increasing workload. For most Internet services such as web, the requests are usually not highly related, and can be run parallely on different servers. Therefore, as the node number of server cluster increases, the performance of the whole can almost be scaled up linearly.

Shared storage can be database systems, network file systems, or distributed file systems. The data that server nodes need to update dynamically should be stored in data based systems, when server nodes read or write data in database systems parallely, database systems can guarantee the consistency of concurrent data access. The static data is usually kept in network file systems such as NFS and CIFS, so that data can be shared by all the server nodes. However, the scalability of single network file system is limited, for example, a single NFS/CIFS can only support data access from 4 to 8 servers. For large-scale cluster systems, distributed/cluster file systems can be used for shared storage, such as GPFS, Coda and GFS, then shared storage can be scaled up according to system requirement too.

Load balancer, server cluster and shared storage are usually connected by high-speed networks, such as 100Mbps Ethernet network and Gigabit Ethernet network, so that the network will not become the bottleneck of system when the system grows up.

来源:

生产环境中的一些web server(主要是三巨头apache, nginx, lighttpd):http://hudeyong926.javaeye.com/blog/813141
nginx作为最前端的web cache系统:http://sudone.com/archie/app-nginx-squid-nginx.html
nginx和squid配合搭建的web服务器前端系统:http://sudone.com/archie/app_nginx_squid.html
General Architecture of LVS Clusters:http://www.linuxvirtualserver.org/architecture.html
 

Magento关闭没用的功能模块

Magento
功能确实强大,但有一些功能模块是我们用不到的,所以可以考虑关闭掉以提高系统速度。

如何关闭Magento没用的功能模块
呢?

在Magento中所有模块的开关都是在app/etc/modules中的文件进行配置的,要把一个模块禁用,步骤如下:

  1. 确定你要关闭的模块,比如我们这边要关闭的是后台的Magento通知信息模块
    :AdminNotification
  2. 到app/etc/modules目录下,找到包含这个模板定义的xml文件
  3. 删掉它的相关定义,或将<active>true</active>值改成false;

这样就OK了! 所以关闭Magento没用的模块
也挺容易的~~

magento促销方案之 - magento运费计算模块

目前已经有多家物流公司提供了实时的运费计算接口,包括UPS,FedEx,USPS,DHL。

magento实时运费计算模块整合功能

  • 商家仅需在后台设置运费接口的参数,例如重量单位,包装方式,取货途径等,以及官方接口地址即可。
  • 实时运费计算根据买家购买时填写的相关信息和购物车内的产品数量,重量等参数自动计算运费。
  • 客户在送货方式中选择该运输方式,商家即可根据客户所填相关信息为其提供服务

优点+


+ 运费计算自动化

缺点 -


- 运费不可控

 

magento免运费功能

免运费是时下流行的运费模式,可以对所有用户在所有条件下开启,或者在购物满一定价格或数量后给予免运费的优惠。

magento平运费计算模块功能


  • 商家在后台完全开启此功能,填写文字说明。即全场免运费。
  • 商家在后台设定免运费条件,例如购物车中商品的总价,数量等,实现有条件的免运费优惠。
  • 客户在送货方式中选择该运输方式,商家即可根据客户所填相关信息为其提供服务

优点+



+ 促销优惠的好手段

注意点 *



* 需要经过培训以便灵活运用有启动条件免运费

magento平运费计算模型

电子商务中一类运用广泛且简单实用的运费计算模型是单纯根据订单中货物数量或对订单进行统一运费定价

magento平运费计算模块功能


  • 商家在后台可设定一个订单中,每件货物的运费。例如每件货物运费10元,买家购买了5件商品,运费即是10元/件×5件=50元。或者,
  • 商家在后台设定每个订单运费的统一价格。例如,没订单运费均为10元,无论买家购买几件商品,买了多少总价的商品,运费均为10元。
  • 客户在送货方式中选择该运输方式,商家即可根据客户所填相关信息为其提供服务

优点+



+ 商家管理运费公式比较简单


+ 运费计算直观,买家估算运费简单

缺点 -



- 难以实现复杂的运费促销功能和精确运费计算

magento多参数运费计算模型

电子商务中运用最广泛的运费计算模型就是根据货运目的地,货物数量,货物重量等参数进行运费计算。

magento参数运费计算模块功能


  • 商家在后台设定运费计算表格,共有三种模型:货物目的地 - 货物重量 - 运费,货物目的地 - 货物总价 - 运费,货物目的地 - 货物件数 - 运费
  • 客户在送货方式中选择该运输方式,商家即可根据客户所填相关信息为其提供服务

优点+



+ 商家可以为买家提供精确的运费


+ 商家可以利用此运费计算模型进行运费促销,例如根据货物件数或货物总价进行任意的运费设定


+ 商家通过完全可控的多参数运费计算模型,可以将与快递公司、物流公司或邮局达成的协议价格进行性运费设定

缺点 -



- 首次录入数据量稍大

magento货到付款COD模块

货到付款是指同时进行货物运送与征收款项的服务,将货品运送至指定的地点,并且向收件人收取相应费用。若收件人对货物的品质不满或对该交易没有印象而拒绝付款,货物将送回寄件人处。 货到付款的送件人是寄件人与收件人以外的第三方快递企业或邮局。

MEC magento货到付款运费计算模块功能

  • 商家在后台设定货到付款方式所需的运费
  • 客户在送货方式中选择“货到付款”,商家即可根据客户所填相关信息为其提供服务

优点+


+ 商家可以避免收件人收取货物但不付款的风险。
+ 商家通过此收款发货方式可以降低买家的购物心理壁垒。对于新商家来说,可以有效提升网站购物转化率。
+ 买家可以避免在邮购或网络购物已付款(预付)却由于运送途中的意外等原因而收取不到货物的窘境。
+ 买家能够拒绝签收自己没有登记购买的货品。避免网络购物诈骗,遭到卷款逃跑的风险。

缺点 -


- 由快递公司或邮局的中介结算业务,通常需要额外支付手续费。
- 必须和快递企业签约合作,并且每周或每月才结一次款项,造成资金周转与成本增加的压力。
- 可能收件人未确认内容物就直接付款,事后发现和订购商品有出入而产生纠纷。当基于相关法律法规,买家一般无法获得赔偿。

注意点 *


* 支付货款时送货员可能没有没有细款可以找钱,尤其是有多件代收货物时。可能为了找钱再次造访收件人,甚至是拒绝交货。最好事先准备好零钱。

thinkPHP学习笔记[持续更新]

快捷方法:
A:快速实例化Action类库
B:执行行为类
C:配置参数存取方法
D:快速实例化Model类库
F:快速简单文本数据存取方法
L:语言参数存取方法
M:快速高性能实例化模型
R:快速远程调用Action类方法
S:快速缓存存取方法
U:URL动态生成和重定向方法
W:快速Widget输出方法

导入:
Vendor\Zend\Filter\Dir.php
Vendor('Zend.Filter.Dir');

lib\Think\Util\Session.class.php
import("Think.Util.Session");

MyApp项目下面的Lib\Action\UserAction.class.php
import("MyApp.Action.UserAction");

lib\当前项目\Action\UserAction.class.php
import("@.Action.UserAction");

ORG/User.Info.class.php
import("ORG.User#Info");

import('AdvModel');
如果有定义AdvModel别名,则import方法会自动加载定义的别名导入。系统默认的别名定义文件位于系统的Common\alias.php,每个模式和项目都可以定义自己的别名定义文件。

自动加载:__autoload()
系统自动加载ThinkPHP基类库和当前项目的model和Action对象,并且支持配置自动加载路径。APP_AUTOLOAD_PATH(common\convention.php)参数是用于设置框架的自动导入的搜索路径的,默认的配置是Think.Util.,因此才会实现自动导入Think.Util工具类库。例如,我们需要增加ORG.Util.路径作为类库搜索路径,可以使用:'APP_AUTOLOAD_PATH'=> 'Think.Util.,ORG.Util.。

建立新项目:
导入thinkPHP的目录里的ThinkPHP.php,然后执行app:run() ThinkPHP即可自动建立新项目的目录结构。

链接数据库:
$this->db = Db::getInstance(empty($this->connection)?'':$this->connection);

获得配置文件的参数值:
C('参数名称') // 获取已经设置的参数值

跨模块调用方法:
$User = A("User") ===== import("@.Action.UserAction");

R('User','importUser');// 远程调用UserAction控制器的importUser操作方法
A("User","App2"); // 实例化App2项目的UserAction控制器对象
R("User","importUser","App2");// 远程调用App2项目的UserAction控制器的importUser操作方法

跨项目调用模块:
$User = D('User', 'Admin'); // 实例化Admin项目下面的User模型
如果启用了模块分组功能,可使用:$User = D('Admin.User');

实例化模型:
 1、基础模型model类:$User = new Model('User'); || $User = M('User');
 2、其他模型类:$User = new CommonModel('User'); || $User = M('User', 'CommonModel');
 3、用户定义的模型类(项目\Lib\Model):$User = new UserModel(); || $User = D('User');
 4、实例化空模型类:$Model = new Model(); || $Model = M();
                    $Model->query('SELECT * FROM think_user where status=1');

系统配置:
惯例配置(common\convention.php) - 项目配置(项目\conf\config.php) - 调试配置(think\common\debug.php)
- 分组配置(项目\分组名\config.php) - 模块配置(项目\分组名\[模块名小写]_config.php) - 动态配置(具action里的配置)
有效性为:右 > 左


 

如何创建magento模块z之Hello World例子

 

如何创建magento模块z之Hello World例子



步骤:
1.创建一个Hello World模块
2.为这个模块配置路由
3.为这个模块创建执行控制器

 

创建Hello World模块



创建模块的结构目录:
app/core/local/Sjolzy/HelloWorld/Block
app/core/local/Sjolzy/HelloWorld/controllers
app/core/local/Sjolzy/HelloWorld/etc
app/core/local/Sjolzy/HelloWorld/Helper
app/core/local/Sjolzy/HelloWorld/Model
app/core/local/Sjolzy/HelloWorld/sql
创建config.xml的内容(app/core/local/Sjolzy/HelloWorld/etc/config.xml):
<config>
 <modules>
  <Sjolzy_HelloWorld>
   <version>0.1.0</version>
  </Sjolzy_HelloWorld>
 </modules>
</config>
然后创建一个系统配置文件激活这个模块
Sjolzy_HelloWorld.xml(app/etc/modules/Sjolzy_HelloWorld.xml)
<config>
 <modules>
  <Sjolzy_HelloWorld>
   <active>true</active>
   <codePool>local</codePool>
  </Sjolzy_HelloWorld>
 </modules>
</config>
检查是否模块已经激活:先清空magento缓存(var/cache),在后台管理:System->Configuration->Advanced 展开Disable Modules Output,看是否Sjolzy_HelloWorld显示出来。
 

配置路由


路由是用来把一个URL请求转换成一个执行控制器的方法。
需要在magento的全局配置中显式的定义你的路由。
在config.xml(app/core/local/Sjolzy/HelloWorld/etc/config.xml)中:
<config>
 ...
 <!-- /*  fontend:指向网站的前台(也可以是admin|install) */ -->
 <frontend>
  <!-- /*  routers:路由对象的定义或路由路径的定义 */ -->
  <routers>
   <!-- /*  helloworld:指向网站的前台 */ -->
   <helloworld>
    <use>standard</use>
     <args>
      <!-- /*  module:模块名字的小写版本 */ -->
      <module>Sjolzy_HelloWorld</module>
      <!-- /*  fontName:路由过程中的一个参数,只跟路由相关(Front Controller则是用来实例化所有路由) */ -->
      <frontName>helloworld</frontName>
     </args>
   </helloworld>
  </routers>
 </frontend>
</config>
 

为路由创建执行控制器


路由会把控制权交给控制器,我们已经定义了路由,现在来定义我们的执行控制器。
app/code/local/Sjolzy/HelloWorld/controllers/IndexAction.php(模块的控制器放在子目录controllers<小写>里,这是magento的规定)
<?php
class Sjolzy_HelloWorld_IndexController extends Mage_Core_Controller_Front_Action{
 public function indexAction(){
  echo 'Hello World!';
 }
}
?>

还是情况缓存,请求URL:http://example.com/helloworld/index/index
注:http://example.com/frontName/执行控制器/执行方法


如果看到空白页面上写着'Hello World!',则你的模块创建成功!