在内部，一个vert.x实例会管理着一个小的线程集合，每个线程针对服务器上的一个可用内核。基本上每个线程都实现了一个事件循环。当部署一个vert.x应用实例（又叫做verticle）时，服务器会选择一个事件循环分配给该实例。接下来针对该实例的任务都会通过该线程进行分配。由于在某一时刻可能会有成千上万个verticle在运行，因此在同一时刻会将单个事件循环指定给多个verticle。
Verticle可与运行在相同或不同vert.x实例中的其他verticle进行通信，这是通过消息事件总线实现的，它类似于Erlang的actor模型。消息传递旨在让系统能够在多个可用核心上进行扩展而无需以多线程的方式来执行verticle代码。
事件总线是分布式的，并不只会跨越服务器，还会渗透进客户端的JavaScript以处理“实时”的Web应用。
除了并发与消息传递外，vert.x还具有如下特性：
TCP/SSL服务器与客户端
HTTP/HTTPS服务器与客户端
WebSockets/SockJS支持
InfoQ有幸采访到了VMWare的高级工程师Tim Fox以了解vert.x：
InfoQ：能否从架构上介绍一下vert.x及其构建方式？
Tim：vert.x的核心是用Java编写的，接下来我们为每一种支持的JVM语言编写了一个薄薄的API层，这样每种语言都有一个适合于该语言的API了。我们并没有向这些语言直接公开Java API。这意味着Ruby用户会通过Ruby的方式编写代码，JS用户会通过JS的方式编写代码。
InfoQ：能否描述一下在vert.x上典型的开发流程么，特别是与开发者使用Node.js的体验进行一下对比？
我觉得这与node.js是非常类似的。实际的工作流程取决于你是在本地还是云中运行应用。但这并非vert.x所特有的。
InfoQ：就调试、监控与运维来看，在JVM与Node.js上运行实时应用有何差别？
我想说监控与运维实际上与部署vert.x的环境之间的关系更为密切而非vert.x本身。比如说，如果将vert.x部署到云中，那么云提供商可能就会为你提供监控。顺便说一下，社区成员目前已经在OpenShift与Heroku上运行了Vert.x。我们希望不久之后CloudFoundry支持就会到来。
InfoQ：vert.x与Node.js有什么基准比较么？
我们尚未发布任何的官方基准。但我自己已经完成了一些，在我所做的测试中，vert.x的性能与可伸缩性都远远超越了node.js。我希望在不久之后能够发布一些基准。
InfoQ：vert.x与Netty相比如何呢？
Netty是个很棒的底层IO库。Vert.x实际上使用了Netty。但vert.x是个用于编写异步应用的完整。Vert.x还提供了一个组件模型、文件IO及各种Netty所没有的东西。我要说的是，在JVM世界中，Vert.x是更类似于Akka（也使用了Netty）之类的完整框架。
您好，对于你的遇到的问题，我很高兴能为你提供帮助，我之前也遇到过哟，以下是我的个人看法，希望能帮助到你，若有错误，还望见谅！。展开全部Nginx+PHP-fpm组合，以内存占用小，负载能力强壮的特点，成为小内存VPS建站的首选组合。我们一起来探讨一下nginx+php-fpm高负载的优化方法。
先来看看nginx配置参数的优化。nginx是前端接受浏览器端请求的web server, 配置可调的参数如下：
下面是示例nginx配置
user www-data
worker_processes 8
#worker_processes 调至8， 大于8没什么用，小于8，nginx性能发挥不出来
worker_cpu_affinity 01 10 01 10 01 10 01 10
#worker_cpu_affinity 参数可以使nginx充分发挥多核Cpu的性能优势 ，上面的配置是针对双核CPU的配置。01表示第一个核，10表示第二个核，如果是四核cpu，一至四个核分别表示为 0001 0010 0100 1000
error_log /var/log/nginx/error_log crit
pid /var/run/nginx.pid
worker_rlimit_nofile 10240
#worker_rlimit_nofile 是nginx能打开文件的最大句柄数，我们需要把这个数字设大一点。
#linux系统的文件查看数限制查看是用 ulimit -n ，修改这个限制是用 ulimit -HSn 65535
events
{
use epoll
#必须要用高效的event驱动，以获得最大性能
worker_connections 10240
#max_clients = worker_processes * worker_connections/4 （最大连接数的计算公式）
}
http
{
include /etc/nginx/deny.iplist
include /etc/nginx/mime.types
default_type application/octet-stream
server_name_in_redirect off
server_names_hash_bucket_size 128
server_tokens off
client_header_buffer_size 32k
#client头buffer可以调为32K
large_client_header_buffers 4 32k
client_max_body_size 8m
sendfileon
tcp_nopush on
keepalive_timeout 65
tcp_nodelayoff
client_body_timeout 10
client_header_timeout 10
send_timeout 60
output_buffers 1 32k
postpone_output 1460
open_file_cache max=1000 inactive=20s
open_file_cache_valid30s
open_file_cache_min_uses 2
open_file_cache_errors on
fastcgi_connect_timeout 300
fastcgi_send_timeout 300
fastcgi_read_timeout 300
fastcgi_buffer_size 32k
fastcgi_buffers 4 32k
fastcgi_busy_buffers_size 32k
fastcgi_temp_file_write_size 32k
gzip on
gzip_buffers 4 16k
gzip_http_version 1.0
gzip_comp_level 2
gzip_types text/plain application/x-javascript text/css application/xml
gzip_proxied expired no-cache no-store private auth
proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=staticfilecache:80m inactive=1d max_size=2500m
proxy_temp_path /var/lib/nginx/proxy
proxy_connect_timeout 300
proxy_read_timeout 120
proxy_send_timeout 120
proxy_buffer_size 16k
proxy_buffers 4 16k
upstream wordpressnginx
{
server 127.0.0.1:6000 weight=1 fail_timeout=120s
}
include /etc/nginx/sites-enabled/*
}
上面的配置里面，有多处设及到buffer和timeout的地方。我们可以根据需要，慢慢调大这些参数，buffer自然是大点好，但不要太大。16K是标准配置，可以增加到32，往上加更大也不是不行，但 要考虑到你系统内存大不大，够不够用。timeout是超时，如果服务器很繁忙，不妨增加超时等待时间，以避免频繁出现502错误。
gzip是必须开启的，reverse proxy在允许的情况下，也尽量开启，一 是可以提升响应效率，二是降低服务器压力，gzip开启后更可以节省服务器带宽。
nginx主要的配置如上所述。
现在看一下php-fpm的配置。
[global]
pid = run/php5-fpm.pid
process_control_timeout = 5
[www]
listen = /dev/shm/php-cgi.sock
listen.allowed_clients = 127.0.0.1
user = www-data
group = www-data
pm = static
pm.max_children = 7
#这个决定了 php-fpm的总进程。我们要想同时响应更多的并发数，这个数值要尽可能大，比如500，1000
pm.max_requests = 10000
#并发数越大，这个最大请求数应该越大，并发数小，这个数值也应该越小。它表示，php-fpm进程响应了10000个并发请求之后，就自动重启一下进程。
request_terminate_timeout = 30
#表示等待30秒后，结束那些没有自动结束的php脚本，以释放占用的资源。
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
小内存的vps虽然经过使用php-fpm+nginx，提升了系统的效率，可以同时响应较多的并发请求，但是当并发数上来了，比如从100上升到10000，小内存肯定响应不过来，cpu也会 因为太忙，而导致系统负载变得很高很高，这个时候，我们就要考虑升级硬件配置了。
内存越大越好，CPU核心频率越高越好，CPU核越多越好。硬盘最好是SSD+RAID10。这样性能不仅高，数据安全也有保障。
上面所提到的各个配置参数，设及到数值的，不妨自己 多试着调小，调大参数，然后重启下nginx或者php-fpm进程，看看效果怎么样。
下面介绍一个比较好的压力测试工具，siege.
debian和ubuntu用户可以通过apt-get install siege来安装siege.
siege是一个跟ab.exe相似的http压力测试软件。
我们可以用siege来测试我们的网站和服务器性能。
siege -r 100 -c 10
-r 是 repeat , -r 100是重复100次测试
-c 10是表示模拟10个用户同时并发连接
最后面是要测试的URL地址。
测试过程中可以随时按CTRL+C中止进程，siege会生成一个报告给我们。
我们可以同时根据siege的测试结果和监视服务器的负载情况，对系统压力状况进行一个深入了解和分析。接下来可以帮助我们判断该如何进行下一步操作，是继续优化配置，还是升级硬件。非常感谢您的耐心观看，如有帮助请采纳，祝生活愉快！谢谢！
