epoll

Apache与Nginx的优缺点比较 1、nginx相对于apache的优点： 轻量级，同样起web 服务，比apache 占用更少的内存及资源 抗并发，nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能 补充： 同步传输：浏览器发起请求，而后请求会立刻被转到后台，于是在浏览器和后台之间就建立了一个通道。在请求发起直到请求完成，这条通道都是一直存在的。 异步传输：浏览器发起请求，请求不会立刻转到后台，而是将请求数据（header）先收到nginx上，然后nginx再把这个请求发到后端，后端处理完之后把数据返回到nginx上，nginx将数据流发到浏览器，这点和lighttpd有点不同，lighttpd是将后端数据完全接收后才发送到浏览器。 1) 假设用户执行一个上传文件操作，因为用户网速又比较慢，因此需要花半个小时才能把文件传到服务器。squid的同步代理在用户开始上传后就和后台建立了连 接，半小时后文件上传结束，由此可见，后台服务器连接保持了半个小时；而nginx异步代理就是先将此文件收到nginx上，因此仅仅是nginx和用户 保持了半小时连接，后台服务器在这半小时内没有为这个请求开启连接，半小时后用户上传结束，nginx才将上传内容发到后台，nginx和后台之间的带宽 是很充裕的

Apache与Nginx的优缺点比较 1、nginx相对于apache的优点 轻量级，同样起web 服务，比apache 占用更少的内存及资源 抗并发，nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能 高度模块化的设计，编写模块相对简单 社区活跃，各种高性能模块出品迅速啊 apache 相对于nginx 的优点： rewrite ，比nginx 的rewrite 强大 模块超多，基本想到的都可以找到 少bug ，nginx 的bug 相对较多 超稳定 存在就是理由，一般来说，需要性能的web 服务，用nginx 。如果不需要性能只求稳定，那就apache 吧。后者的各种功能模块实现得比前者，例如ssl 的模块就比前者好，可配置项多。这里要注意一点，epoll(freebsd 上是 kqueue )网络IO 模型是nginx 处理性能高的根本理由，但并不是所有的情况下都是epoll 大获全胜的，如果本身提供静态服务的就只有寥寥几个文件，apache 的select 模型或许比epoll 更高性能。当然，这只是根据网络IO 模型的原理作的一个假设，真正的应用还是需要实测了再说的。 2、作为 Web 服务器：相比 Apache，Nginx 使用更少的资源，支持更多的并发连接，体现更高的效率，这点使 Nginx

　　一、Nginx特点 　　1、轻量级，采用C进行编写，同样的web服务，会占用更少的内存及资源。 　　2、抗并发，nginx以epollandkqueue作为开发模型，处理请求是异步非阻塞的，负载能力比apache高很多，而apache则是阻塞型的。在高并发下nginx能保持低资源低消耗高性能，而apache在PHP处理慢或者前端压力很大的情况下，很容易出现进程数飙升，从而拒绝服务的现象。 　　3、nginx在开启时，会生成一个master进程，然后，master进程会fork多个worker子进程，最后每个用户的请求由worker的子线程处理。 　　4、可以配置nginx的upstream实现nginx的反向代理。 　　5、nginx作为负载均衡服务器，支持7层负载均衡。 　　6、nginx处理静态文件好，静态处理性能比apache高三倍以上。 　　7、支持高并发连接，每秒最多的并发连接请求理论可以达到50000个。 　　8、nginx配置简洁，正则配置让很多事情变得简单，而且改完配置能使用-t测试配置有没有问题，apache配置复杂，重启的时候发现配置出错了，会很崩溃。 　　9、用线程处理用户请求，而线程是共享内存的，只需要开启少量进程，多个线程就可以共享进程的内存，占用内存小。 　　10、一个进程死掉时，会影响到多个用户的使用，稳定性差。 　　11

一、同步阻塞IO：blocking IO(BIO) 　　 1.过程分析： 　　当进程进行系统调用时，内核就会去准备数据，当数据准备好后就复制到内核缓冲器，返回成功后将数据复制给进程内存，其中这一系列过程就是阻塞的。 2.特点： 　　优点：能及时响应数据 　　缺点：因为整个过程都是阻塞的，所以高并发下性能非常差 二、同步非阻塞IO:nonblocking IO(NIO) 　　 1.过程分析： 　　当进程调用系统时，会立即返回error，当用户知道返回的是error后就知道数据没有准备好，此时进程进行等待，这一个过程是没有阻塞的，因此可以有多个调用请求。当第一个请求来到时，内核会去准备数据，就和BIO的模式一样，当数据准备好后，复制给用户进程内存，这一个过程是阻塞的，但是用户进程会一直去轮询判断数据是否已经准备好了。 2.特点： 　　优点：能够在数据处理好之前去做其他的事情 　　缺点：性能依旧很差，第一需要不断去判断数据释放准备好了；第二在拷贝数据这个过程中，进程依旧书阻塞的；第三因为是轮询去找数据，所以数据会有延迟 三、IO多路复用 　　 1.定义： 　　所谓的IO多路复用指的就是一个或多个线程处理多个TCP连接。 2.网络模型： 　　IO多路复用的网络模型有三种： 　　①select模型： 　　调用select函数时会阻塞住进程，等有数据可读、可写、出异常或者超时就会返回

参考: https://www.cnblogs.com/wanlei/p/10464517.html 关于Redis处理高并发 Redis的高并发和快速原因 1.Redis是基于内存的，内存的读写速度非常快； 2.Redis是单线程的，省去了很多上下文切换线程的时间； 3.Redis使用多路复用技术，可以处理并发的连接。非阻塞IO 内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间。 下面重点介绍单线程设计和IO多路复用核心设计快的原因 为什么Redis是单线程的 1.官方答案 因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。 2.性能指标 关于Redis的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求。 3.详细原因 1）不需要各种锁的性能消耗 Redis的数据结构并不全是简单的Key-Value，还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除 一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。 总之

编者注：Java nio 空轮询bug也就是Java nio在Linux系统下的epoll空轮询问题。 epoll机制是Linux下一种高效的IO复用方式，相较于select和poll机制来说。其高效的原因是将基于事件的fd放到内核中来完成，在内核中基于红黑树+链表数据结构来实现，链表存放有事件发生的fd集合，然后在调用epoll_wait时返回给应用程序，由应用程序来处理这些fd事件。 使用IO复用，Linux下一般默认就是epoll，Java NIO在Linux下默认也是epoll机制，但是JDK中epoll的实现却是有漏洞的，其中最有名的java nio epoll bug就是即使是关注的select轮询事件返回数量为0，NIO照样不断的从select本应该阻塞的 Selector.select()/Selector.select(timeout) 中wake up出来，导致CPU 100%问题。如下图所示： 那么产生这个问题的原因是什么的？其实在 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6670302 上已经说明的很清楚了，比如下面是bug复现的一个场景： A DESCRIPTION OF THE PROBLEM : The NIO selector wakes up infinitely in this

GC策略 & jconsole远程：增加jmx启动配置 /data/app/jdk1.8.0_151/bin/java -Djava.rmi.server.hostname=127.0.0.1 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=7018 -Dcom.sun.management.jmxremote.rmi.port=7019 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -jar ./bussiness-0.0.1-SNAPSHOT.jar -Xms2048m -Xmx2048m -Xmn1024g -Xss2m -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3 -XX:+UseParNewGC -XX:+PrintGCDetails -XX:

最近感觉很多东西在运用到一定的程度之后，会发现原来是自己了解到的不够。一方面限于实际运用到的不多，一方面可能是因为一开始没有进行全面认识。遂这里搜集整理了一番NGINX。 一、nginx启动和关闭 centos平台,源码安装的 /usr/local/nginx/nginx # 启动 /usr/local/nginx/nginx -s reload # 平滑重启 /usr/local/nginx/nginx.conf # 配置文件 mac平台，使用brew安装的 /usr/local/bin/nginx # 启动 /usr/local/bin/nginx -s reload # 平滑重启 /usr/local/etc/nginx/nginx.cnf # 配置文件 二、nginx.conf 配置文件详解 其实，对比，apache 的配置文件，它的相对比较清晰和简单，之前觉得很难，现在沉下心来想想，其实很简单。大致的分块下，基本就分为以下几块： main events { .... } http { .... upstream myproject { ..... } server { .... location { .... } } server { .... location { .... } } .... } 以上我们可以看出，nginx配置文件主要分为六个区域： 1、main