您现在的位置：首页
--> Apache
$request_uri：这个变量就是HTTP头部的 path + query_string, 例如 /my/act?a=1。
$uri：这个变量对应到服务器上的一个文件(资源), 所以, 可能不等于 $uri, 因为可能被 rewrite 过. 例如浏览器请求 /my/act?a=1, 对应的资源(URI, $uri) 是 /dir/file.php, 当然, query_string 不属于 uri 的一部分。
由此可见, $request_uri 这个变量的名字是有歧义的, URI 并不包含 query_string, 但这个变量却包含。
最近收到的几封读者邮件，都是询问为什么在 Nginx 中无法开启 OCSP Stapling。具体现象是在 Nginx 中明明配置了 ssl_stapling on，但通过 SSL Labs 等工具查看，OCSP stapling 这一项并没有生效。本文就这个问题详细探讨下，如果你只关心结论，直接跳到最后一节即可。
搞过前端的估计都碰到最头疼的问题就是浏览器兼容性问题了，特别是针对IE浏览器。往往前端为了省事就搞一个页面提示用户升级浏览器或者显示简单的静态页面。那接下来就需要运维来配置nginx rewrite规则了。
导论 在nginx中使用allow和deny做Access Control访问控制时，有时会出现不生效的问题。 所以我们用实验来验证下 nginx配置如下....
在使用nginx进行 反向代理配置时通过正则表达式配置location后发现，通过$_SERVER['SCRIPT_NAME']; 与$_SERVER['PATH_INFO'] 发现直接获取了整个uri地址。。。
location表达式类型 ~ 表示执行一个正则匹配，区分大小写 ~* 表示执行一个正则匹配，不区分大小写 ^ […]
结论及建议：
Php程序通过HttpMemcMC访问memcache和直接访问memcached的效率并没有太多损失；
采用php直接访问memcached，失败的次数相比通过HttpMemcMC有较大增加，应该是HttpMemcMC在keepalive方面更有优势；
网上很多人写过相关的文章，大多的人的原因是因为 header 的头部大小超了，引起响应 400 告诉是 bad request.但其实还有一种可能，就是象端口测试工具，只是检查端口是否是活的。
所谓「HTTP Keep-Alive」，在维基百科里称为「HTTP Persistent Connection」，说白了就是复用HTTP连接，如此一来理论上客户端的用户体验会更流畅，但是与之相对服务端不得不维持大量的连接。开启还是关闭，这是个问题。
mod_pagespeed是一个开源的Apache module，它由谷歌开发，通过优化你的网页来减少响应延迟和带宽占用。上周，谷歌正式推出了mod_pagespeed的1.0稳定版。
简要说明一下，imgsrc上部署的是apache模块，cdn通过其来访问tfs，并且做一些图像处理工作。有内存泄露是在线上发现的，内存不停的在涨。要找到问题所在，首先需要能够在线下重现，知道在什么情况下会泄露。线上系统当然不可能用valgrind来跑啦，还好我们有tcpcopy(赞一下网易的 @wangbin579 同学，真是个好东西)，我们可以将线上流量镜像到跑着valgrind的机器上来，从而重现问题。跑了一晚上之后问题重现了，这时候需要做的是找到具体能触发问题的http请求。在访问日志和错误日志的帮助下，可以重放这些请求，这样就可以随时重现。一个晚上的访问日志有80多万条之多，我注意到其中有43条是在做图像处理时失败的。这些请求的原图往往都是一些不合法的或已损坏的图。先从这43个请求入手，运气不错，问题已经重现了。这告诉我们多注意一下不法分子总是好的。接下来就是使用2分法来找到具体的某一个访问，可以用脚本来干。最终确定是一个png图片。
今天查看我的 MogileFS 的图片集群,发现很多的日志响应 502 的错误.很是奇怪.然后细细的查看 nginx 输出的 error 的日志,发现大量的超时 upstream timed out (110: Connection timed out) while reading response head...
使用.htaccess 开启gzip 缓存文件 网页 提高速度
关于puppet 的高可用性,以及扩展性puppet pro 书中有详细介绍,本文是参考puppet pro资料进行安装与配置. 为什么要使用Apache来实现,因为puppet 内置的web服务器 比较慢,现在主流的有nginx,apache,关于使用nginx来实现puppet 负载均衡可以参阅:puppet nginx,puppet 官文也有相应文档.可供参考。
服务器上的一些统计数据：1)统计80端口连接数netstat -nat|grep -i "80"|wc -l2)统计httpd协议连接数ps -ef|grep httpd|wc -l3)、统计已连接上的，状态为“establishednetstat -na|grep ESTABLISHED|wc -l4)、查出哪个IP地址连接最多,将其封了.netstat -na|grep ESTABLISHED|awk {print $5}|awk -F: {print $1}|sort|uniq -c|sort -r +0nnetstat -na|grep SYN|awk {print $5}|awk -F: {print $1}sort -r +0n
nginx可以轻松实现根据不同的url 或者 get参数来转发到不同的服务器，然而当我们需要根据http包体来进行请求路由时，nginx默认的配置规则就捉襟见肘了，但是没关系，nginx提供了强大的自定义...
如果你用lighttpd1.5(以下lighttpd均指1.5)做静态文件服务器，或者你虽然用lighttpd处理php请求，但是用到$PHYSICAL作为mod_proxy_core的条件， 且某个时候你的单机流量很低(几个/s), 或许你也有类似的问题，但是影响程度或许不会引起你的注意！ 1.Lighttpd的mod_proxy_core不建议用$PHYSICAL作为条件； 2.Lighttpd的stat cache机制没有节省任何开销； 3.Lighttpd子线程和主线程通过管道+epoll的通信机制，存在event丢失问题； 现象用户反馈凌晨的时候访问百度某页面，某些模块的数据出不来；其它依赖于我们的前端接口的产品线反馈访问时间有时候超过1s；我们自己的QA环境偶尔也会出现请求超过1s的问题；因此我们打开lighttpd的日志的%D配置，打印ms级别的处理时间，发现
近3天十大热文
-
[17] [译]Google Chrome中的高性能网 -
[14] 最近总结的一些技巧(vim,python,s
-
[14] 在FreeNAS/BSD搭建基于Nginx+
-
[14] 关于Linux的文件系统cache
-
[13] Linux常用系统信息查看命令
-
[11] Linux(Ubuntu 10.04)上安装
-
[9] Centos yum 安装nginx+PHP
-
[8] 浏览器缓存机制
-
[8] base64_encode 和 urlenc
-
[7] 精于图片处理的10款jQuery插件
赞助商广告
