tengine？网页显示tengine什么意思
今天给各位分享tengine的知识，其中也会对网页显示tengine什么意思进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
tengine和apache的区别
tengine是淘宝根据nginx源码，根据自身业务改造而成的，它是完全兼容nginx的，你如果想明白，应该首先了解清楚nginx与apache的区别。
Apache与Nginx的优缺点比较
1.nginx相对于apache的优点：
轻量级，同样起web服务，比apache占用更少的内存及资源
抗并发，nginx处理请求是异步非阻塞的，而apache则是阻塞型的，在高并发下nginx能保持低资源低消耗高性能
高度模块化的设计，编写模块相对简单
社区活跃，各种高性能模块出品迅速啊
2.apache相对于nginx的优点：
rewrite，比nginx的rewrite强大
模块超多，基本想到的都可以找到
少bug，nginx的bug相对较多
超稳定
存在就是理由，一般来说，需要性能的web服务，用nginx。如果不需要性能只求稳定，那就apache吧。后者的各种功能模块实现得比前者，例如ssl的模块就比前者好，可配置项多。这里要注意一点，epoll(freebsd上是 kqueue)网络IO模型是nginx处理性能高的根本理由，但并不是所有的情况下都是epoll大获全胜的，如果本身提供静态服务的就只有寥寥几个文件，apache的select模型或许比epoll更高性能。当然，这只是根据网络IO模型的原理作的一个假设，真正的应用还是需要实测了再说的。
Powered by Tengine 什么意思
Tengine是由淘宝网发起的Web服务器项目。它在Nginx的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。Tengine的性能和稳定性已经在大型的网站如淘宝网，天猫商城等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。
从2011年12月开始，Tengine成为一个开源项目。现在，它由Tengine团队开发和维护。Tengine团队的核心成员来自于淘宝、搜狗等互联网企业。
nginx-tengine health_check报错
很多人都知道nginx可以做反向代理和负载均衡，但是关于nginx的健康检查(health_check）机制了解的不多。其实社区版nginx提供的health_check机制其实很薄弱，主要是通过在upstream中配置max_fails和fail_timeout来实现，这边文章主要是深入分析社区版的health_check机制，当然还有更好的一些建议，比如商业版的nginx plus或者阿里的tengine,他们包含的健康检查机制更加完善和高效，如果你坚持使用nginx社区版，当然还可以自己写或者找第三方模块来编译了。
首先说下我的测试环境，CentOS release 6.4(Final)+ nginx_1.6.0+ 2台tomcat8.0.15作为后端服务器。（声明:以下所有配置仅仅为测试所用，不代表线上环境真实所用，真正的线上环境需要更多配置和优化。）
nginx配置如下:
#user nobody;worker_processes 1;#pid logs/nginx.pid;events{worker_connections 1024;
}http{include mime.types;default_type application/octet-stream;log_format main'$remote_addr-$remote_user [$time_local]"$request"'
'$status$body_bytes_sent"$http_referer"'
'"$http_user_agent""$http_x_forwarded_for"';access_log logs/access.log main;sendfile on;keepalive_timeout 65;upstream backend{ server localhost:9090 max_fails=1 fail_timeout=40s; server localhost:9191 max_fails=1 fail_timeout=40s;
}server{ listen 80; server_name localhost; location/{ proxy_pass http://backend; proxy_connect_timeout 1; proxy_read_timeout 1;
} error_page 500 502 503 504/50x.html; location=/50x.html{ root html;
}
}
}
关于nginx和tomcat的配置的基本配置不再说明，大家可以去看官方文档。
我们可以看到我在upstream指令中配置了两台server,每台server都设置了max_fails和fail_timeout值。
现在开始启动nginx，然后启动后台的2台server,故意把在Tomcat Listener中Sleep 10分钟，也就是tomcat启动要花费10分钟左右，端口已开，但是没有接收请求,然后我们访问http://localhost/response/(response这个接口是我在tomcat中写的一个servlet接口，功能很简单，如果是9090的server接收请求则返回9090，如果是9191端口的server则返回9191.),现在观察nginx的表现。
我们查看nginx中
access.log
192.168.42.254-- [29/Dec/2014:11:24:23+0800]"GET/response/ HTTP/1.1" 504 537 720 380"Mozilla/5.0(Windows NT 6.1; WOW64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 2.004 host:health.iflytek.com192.168.42.254-- [29/Dec/2014:11:24:24+0800]"GET/favicon.ico HTTP/1.1" 502 537 715 311"Mozilla/5.0(Windows NT 6.1; WOW64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.000 host:health.iflytek.com
error.log
2014/12/29 11:24:22 [error] 6318#0:*4785892017 upstream timed out(110: Connection timed out) while reading response header from upstream, client: 192.168.42.254, server: health.iflytek.com, request:"GET/response/ HTTP/1.1", upstream:"http://192.168.42.249:9090/response/", host:"health.iflytek.com"2014/12/29 11:24:23 [error] 6318#0:*4785892017 upstream timed out(110: Connection timed out) while reading response header from upstream, client: 192.168.42.254, server: health.iflytek.com, request:"GET/response/ HTTP/1.1", upstream:"http://192.168.42.249:9191/response/", host:"health.iflytek.com"2014/12/29 11:24:24 [error] 6318#0:*4785892017 no live upstreams while connecting to upstream, client: 192.168.42.254, server: health.iflytek.com, request:"GET/favicon.ico HTTP/1.1", upstream:"http://health/favicon.ico", host:"health.iflytek.com"
（为什么要在listener中设置睡眠10分钟，这是因为我们的业务中需要做缓存预热，所以这10分钟就是模拟服务器启动过程中有10分钟的不可用。）
观察日志发现在两台tomcat启动过程中，发送一次请求，nginx会自动帮我们进行重试所有的后端服务器，最后会报 no live upstreams while connecting to upstream错误。这也算是nginx做health_check的一种方式。这里需要特别强调一点，我们设置了proxy_read_timeout为 1秒。后面再重点讲解这个参数，很重要。
等待40s,现在把9090这台服务器启动完成，但是9191这台服务器仍然是正在启动，观察nginx日志表现。
access.log
192.168.42.254-- [29/Dec/2014:11:54:18+0800]"GET/response/ HTTP/1.1" 200 19 194 423"Mozilla/5.0(Windows NT 6.1; WOW64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.210 host:health.iflytek.com192.168.42.254-- [29/Dec/2014:11:54:18+0800]"GET/favicon.ico HTTP/1.1" 404 453 674 311"Mozilla/5.0(Windows NT 6.1; WOW64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.212 host:health.iflytek.com
error.log
没有打印任何错误
浏览器返回9090,说明nginx正常接收请求。
我们再次请求一次。
access.log
192.168.42.254-- [29/Dec/2014:13:43:13+0800]"GET/response/ HTTP/1.1" 200 19 194 423"Mozilla/5.0(Windows NT 6.1; WOW64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 1.005 host:health.iflytek.com
说明正常返回，同时返回9090
error.log
2014/12/29 13:43:13 [error] 6323#0:*4801368618 upstream timed out(110: Connection timed out) while reading response header from upstream, client: 192.168.42.254, server: health.iflytek.com, request:"GET/response/ HTTP/1.1", upstream:"http://192.168.42.249:9191/response/", host:"health.iflytek.com"
发现nginx error.log增加了一行upstream time out的错误。但是客户端仍然正常返回，upstream默认是轮训的负载，所以这个请求默认会转发到9191这台机器，但是因为9191正在启动，所以这次请求失败，然后有nginx重试转发到9090机器上面。
OK，但是fail_timeout=40s是什么意思呢？我们要不要重现一下这个参数的重要性？Let's go!
现在你只需要静静的做个美男子，等待9191机器启动完毕！多发送几次请求！然后咦,你发现9191机器返回9191响应了噢！fail_timeout=40s其实就是如果上次请求发现9191无法正常返回，那么有40s的时间该server会不可用，但是一旦超过40s请求也会再次转发到该server上的，不管该server到底有没有真正的恢复。所以可见nginx社区版的health_check机制有多么的薄弱啊，也就是一个延时屏蔽而已，如此周而复始！如果你用过nginx plus其实你会发现nginx plus提供的health_check机制更加强大，说几个关键词，你们自己去查! zone slow_start health_check match!这个slow_start其实就很好的解决了缓存预热的问题，比如nginx发现一台机器重启了，那么会等待slow_starts设定的时间才会再次发送请求到该服务器上，这就给缓存预热提供了时间。
网页显示tengine什么意思
Tengine是由淘宝网发起的一个Web服务器项目，是一个基于Nginx的Web服务器增强版，主要用于高并发、分布式的Web服务。Tengine在Nginx的基础上增加了一些功能模块，如动态模块、Lua脚本引擎、流量控制等，同时对Nginx的性能和稳定性进行了优化。Tengine的目标是成为一个高性能、高可靠性、高扩展性、高安全性的Web服务器软件，适用于各种规模的Web应用和服务。
当我们在浏览网页时，如果看到网页底部或者其他地方显示"Tengine"，那么说明该网站使用了Tengine作为Web服务器。这并不影响我们正常浏览网页，只是告诉我们该网站所使用的Web服务器软件是Tengine。
文章到此结束，希望我们对于tengine的问题能够给您带来一些启发和解决方案。如果您需要更多信息或者有其他问题，请随时联系我们。