HTTP Keep Alive

HTTP Keep Alive

Http Keep-Alive seems to be massively misunderstood. Here’s a short description of how it works, under both 1.0 and 1.1, with some added information about how Java handles it.

Http operates on what is called a request-response paradigm. This means that a _client_ generates a request for information, and passes it to the server, which answers it. In the original implementation of HTTP, each request created a new socket connection to the server, sent the request, then read from that connection to get the response.

This approach had one big advantage – it was simple. Simple to describe, simple to understand, and simple to code. It also had one big disadvantage – it was slow. So, keep-alive connections were invented for HTTP.
HTTP/1.0

Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request:

Connection: Keep-Alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.
HTTP/1.1

Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header:

Connection: close

The Connection: Keep-Alive header no longer has any meaning because of this.

Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it.
Not reliable

HTTP is a stateless protocol – this means that every request is independent of every other. Keep alive doesn抰 change that. Additionally, there is no guarantee that the client or the server will keep the connection open. Even in 1.1, all that is promised is that you will probably get a notice that the connection is being closed. So keepalive is something you should not write your application to rely upon.
KeepAlive and POST

The HTTP 1.1 spec states that following the body of a POST, there are to be no additional characters. It also states that "certain" browsers may not follow this spec, putting a CRLF after the body of the POST. Mmm-hmm. As near as I can tell, most browsers follow a POSTed body with a CRLF. There are two ways of dealing with this: Disallow keepalive in the context of a POST request, or ignore CRLF on a line by itself. Most servers deal with this in the latter way, but there’s no way to know how a server will handle it without testing.
Java abstraction – client side

On the client side, Java abstracts the notion of a keepalive request away from the programmer. The HttpURLConnection class implements keepalive automatically, without intervention being either required or possible on the part of the programmer. It does this through an internal cache of client connections, which is maintained as one of the implementation details of the class. Incidentally, this means that keepalive is an implementation detail of the Javasoft class library, which may or may not be available in other class libraries.
Java abstraction – server side

On the server side, Java again abstracts out the notion of a keepalive request. The HttpServlet, HttpServletRequest, and HtppServletResponse classes implement keepalive automatically. In this case, however, some intervention is possible. As mentioned in the KeepAliveServlet that comes with the JavaWebServer, the actual keepalive behavior that occurs depends on two factors: setting content length, and size of output. If content length is set as part of the response, keepalive will be used if the client supports it. If content length is not set, the servlet implementation will attempt to buffer the response to determine it’s content length. If the buffering is successful, keepalive will be used. In the Javasoft implementation, a 4k buffer is used. This means that if the content length is not set, and the amount of data returned is over 4k, keepalive will not be used. As with HttpURLConnection, this is an implementation detail of the Javasoft class library, which may or may not be available in other class libraries.

SO_KEEPALIVE包由TCP处理,而Keep-Alive由HTTP处理,keep-alive是需要客户端支持,so_KEEPALIVE是利用了tcp的双向全双工连接特性,在web-server端可以不断开连接,来接受客户端更多的请求,应该是能够改善连接时间,不过似乎在连接非常多的情况下会大大加重服务器负担,需要tcp/ip协议盏支持,并且不同客户端之间有不同的设定
在观测时发现以下现象:当keepalive off时的值与keepalive on时的值比较得以下结果:

ps -ef|grep httpd|wc -l的值小。
netstat -an | grep :80 |wc -l的值大。
 

摘自:http://hi.baidu.com/toughguy/blog/item/626410fb51abfa176d22eb38.html

轻量级 Web 服务器

最近几年,市场上出现了很多有趣的 Web 服务器实现,包括 lighthttpd、litespeed 和 mongrel 等。这些 Web 服务器都宣称结合了性能、易管理性、可移植性、安全性和其他相关价值。下面的工程研究将调查轻量级 Web 服务器,以帮助您选择最可能满足下一个项目的技术需求的 Web 服务器。

“轻量级” Web 服务器,例如 lighthttpdlitespeedmongrel,可以为项目带来很多的好处。本文调查这种可能性,并展示这些 Web 服务器的适用性。

第一个重要的方面是清楚地理解所调查的领域(请参阅 参考资料,以了解更详细的信息)。终端用户在 Internet 上的基本动作就是 “进入一个 Web 页面”。从大处讲,这牵涉到两个应用程序之间的协作:

        

  • 一个 Web 浏览器,例如 Firefox 或 Internet Explorer,用于请求一个特定的页面,并且以人类可读的方式显示从另一个应用程序那里收到的内容。
  •     

  • 一个 Web 服务器,通常是在远程机器上,负责对页面请求作出响应,返回 HTML 编码的或类似的数据流。

所有 Web 用户直接与浏览器交互,因此他们的选择和分析相应地有些狂热。而服务器只对站点的技术人员可见。根据 Netcraft 最近的调查,虽然存在很多不同的 Web 服务器,但是其中两种 Web 服务器就占据了 90% 的份额,这两种 Web 服务器是 Apache 和 Internet Information Server (IIS)。它们都是经过高度锤炼的产品,并且声称不仅具有广泛的内在技术特性,而且有很多配套的书籍、增件、顾问、提供商等。那么,它们是否还有值得改造的地方呢?

答案是肯定的。评价一个 Web 服务器的重要指标有:

        

  • 性能:对请求作出响应的速度有多快?
  •     

  • 可伸缩性:当很多用户同时访问它时,服务器还能继续可靠地运行吗?
  •     

  • 安全性:服务器是否只执行它应该执行的操作。它在认证用户和加密传输方面提供了怎样的支持?它的使用是否使附近的应用程序或主机变得更易受攻击?
  •     

  • 可靠性:服务器的失效模式和故障发生率如何?
  •     

  • 标准遵从性:服务器遵从相关的 RFC 吗?
  •     

  • 灵活性:是否可以对服务器进行调优,以支持较重的请求负载、需要计算的动态页面或者代价不菲的认证等等?
  •     

  • 平台需求:该服务器可用于哪些平台?它是否有特定的硬件需求?
  •     

  • 易管理性:服务器是否易于设置和维护?它是否与日志记录、审计、成本计算等组织标准兼容?

Apache 和 IIS 不能同时在那么多的标准方面做到最好。理论上讲,显然那些定向的产品至少能在以上的一至两个方面超越市场领头产品。

关于轻量级 Web 服务器的一件有趣的、值得调查的事情是,它们之间的竞争远远不止是理论上的:仔细研究表明,它们有很多 东西可以提供,并且即使在很多常见的情况下,它们相对于 Apache 和 IIS 也坚持了自己的风格。虽然可以合理地认为市场领头产品已经经过了小心的优化,从而能够有效地在性能(举个例子)方面避免被击败,但是很多小型的竞争对手因为只提供简单的静态 Web 页面服务,速度反而更快。当使用这些 Web 服务器运行测试时,您会感觉好像是在赛道上驾驶一辆 go-kart 小车,不知不觉竟然超过了 Porsche 和 Viper 车。这还不是全部:有时候,轻量级 Web 服务器可作为那些大哥级服务器的有效补充,而不只是与它们竞争。即使您知道自己将使用 Apache,有时候通过将它与一个轻量级伙伴搭档,反而可以最大限度地利用它。最好的解决方案有时候需要两个或更多 Web 服务器的协作。

Web 服务的轻巧性

本调查中重点关注的 “轻巧性” 实际上是一种主观质量,就像 “艺术” 或 “风格”。它通常意味着简单、易于安装、流线化、要求低和健壮 —— 比 Apache 和 IIS 更小、更简单,当然,在试图满足大量市场的过程中,它们已经变得异常复杂。出于这个目的,虽然 Java Web Server、AOLserver 和 Zeus 拥有迷人的可移植性和性能优势,但是它们的复杂性和大小使其不得不被拒之门外。

轻量级 Web 服务器可以适用于市场领头产品和其他 “重量级” 服务器无法胜任的情况。例如,整个服务器可以打包在一个文件中。这意味着开发人员可以方便地携带生产环境所需的所有工具。即使在生产服务器上运行的是 Apache,也仍然可以在宾馆的房间里,借助只需数秒钟就可以安装完毕的轻量级 Web 服务器以尝试新想法。而且,由于轻量级 Web 服务器要求很低,因此可以在那些无法负担 IIS 的主机上顺畅地运行。

单文件打包

    

        

            

            

        

    

            

                

                    

                        

                    

                

            

单文件打包
                        Apache 需要小心地安装散布在多个目录中的很多文件。与之截然不同的是,下面的 Web 服务器却打包在一个可执行文件中。我的一个雇主 Phaseit 的专长是部署和打包,我们能使 Apache 的安装看上去比平常更简单一些。但是即使我们做得最好,Apache 或 IIS 与轻量级 Web 服务器在 “空间占用” 方面也仍然有很大的差异:前者要占用大量的空间。

            

小的、轻量级的 Web 服务器还可以在小功率的主机上良好地运行。在我们的公司(Phaseit —— 见 侧栏)中,我们在远程的、条件欠佳或配置较低的环境中的工业计算机上运行专用的 硬件。在这些情况下,能够通过一个对处理能力或磁盘空间要求很低的应用程序来提供 Web 页面是一个很大的优势。这意味着我们的机器可以避免 Apache 的开发和处理能力所带来的开销,构建基于 Web 的管理控制台。

从某种程度上讲,几乎所有轻量级 Web 服务器都是开放源码的。如果我们需要某一款 Web 服务器所特有的行为,那么下面概述的一些 Web 服务器都非常小巧,易于理解,也易于增强,只有两个例外。这些 Web 服务器为嵌入 Web 服务的项目提供极好的原始材料,不管这些 Web 服务是在特殊的硬件中,还是在为在通用计算机上运行而设计的特定应用程序中。它们还广泛用于具有传统外观的 Web 站点:

        

  • YouTube 依靠 lighttpd 快速交付归档的内容,例如视频;
  •     

  • cdServe 运行 “German Woodworking Machinery and Tools” CD;
  •     

  • LiteSpeed 宣扬它在 twitter、www.funnyoride.com、www.airliners.com、WordPress.com、fanfiction.com、SlashGear、www.forumactif.com 和其他著名 Web 站点上担任的角色;
  •     

  • OpenSUSE、RubyOnRails、MarkaBoo 和其他一些著名站点依赖于 Mongrel;
  •     

  • demon.net、bluelight.com、mtv.com、The Drudge Report、garfield.com 等站点则使用 thttpd;
  •     

  • 等等。

下面的例子说明了开发人员使用轻量级服务器的轻巧性:在我们公司,我们采用专门的硬件提供办公室电话解决方案。它基于定制的、以传统的 Linux® 应用程序的形式运行的软件。只需一个附加文件和一点 init.d 配置,很容易添加一个强大的 “Web 控制台”,该 Web 控制台能提供硬件和软件的管理界面。 终端用户可以从任何浏览器中监视和配置他们的计算机,而不必安排专门的硬件连接或解决使用 “垂直” 硬件时常见的其他复杂性。

面向服务架构(SOA)被认为难以使用。在我们的经验中,SOA 至少有一部分这方面的缺点阻碍了 Web 服务的使用。我们利用轻量级 Web 服务来设置快速的 SOA,以进行演示。

轻量级服务器甚至可以用于生产数据中心,包括前面列出的 high-profile 站点。性能非常高的站点会将操作分开,从而最大限度地利用缓存、代理等技术。例如,一个基于 Apache 的站点可能采用一种这样的架构:通过小型的 Web 服务器从专用的文件系统提供缓慢变化的图片。终端用户看到的结果实际上是 Apache 和一个或多个辅助 Web 服务器通过协作得到的输出,它们各自担任自己擅长的角色。这样的安排可以以非常低的计算成本提供非常 快的结果。

虽然轻量级 Web 服务器有很多共同之处,但是各有各的不同。大多数轻量级 Web 服务器是用 C 编写的,但是实践证明,有些其他实现语言也可以成功地用于实现服务器,对此我已经做了实验,这些语言包括 Erlang、Java、Lisp、Lua、Perl、Python 和 Tcl。如果其中有您喜欢的语言,那么也许可以找到适合您的 Web 服务器。

由于很多特定的原因,您可能会将目光投向某种 “不常见” 的语言:

        

  • 教学:使用轻量级 Web 服务器来制定一个重要、但是并不太大的目标。这是获得使用某种语言的经验的好方法。
  •     

  • 虽然用 C 编写的轻量级 Web 服务器大小为 10-50 KB,更高级的语言有 100 KB 到数 MB 的运行时,但整个 Web 服务器的源文件可能只占几千个字节。这种 Web 服务器占用的空间很小,因此比 Apache 更易于与技术伙伴共享。
  •     

  • 更高级的语言可以使实验更吸引人 —— 例如,添加一个新的 HTTP/1.1 特性可能只需几行源代码。这些轻量级服务器是非常方便的实验材料。
  •     

  • 将 HTTP 服务器添加到已有的、用高级语言编写的应用程序中只需增加几行源代码。

Athana 可以作为这些主题的例子。它是用 Python 编写的 Web 服务器。它支持 HTTP 多部分(上传)、会话、 cookie 等。从 0.2.1 版开始,Athana 一直被编写在一个单独的、精心组织的源文件中。

如前所述,不同的轻量级 Web 服务器有着不同的优点,它们或多或少独立于编程语言。所有轻量级 Web 服务器都比 Apache 更小、更易于配置。与 Apache 相比,有些轻量级 Web 服务器更快,有些则快得多。有些则强调安全性、重负载下的从容性、可扩展性或者内存占有量。在任何情况下,都可以以一种不适用于 Apache 的方式彻底地理解这些服务器。

哪些特定的产品使这些可能性成为现实?即使只留意 “轻量级” 服务器,面对的也是一个很大的难于管理的产品集合。不过可以将它们按子类来划分:超轻型、关注安全型、支持特定语言型等等。

我特别喜欢其中的超轻型 Web 服务器,它们比 Apache 小得多。如此小的应用程序可以直接记住,系统地、严密地加以考虑,以证明 它们的安全性或可伸缩性。小型 Web 服务器包括:

        

  • Cheetah Server,用不到一千行的 C 代码编写而成。
  •     

  • DustMote,一个非常 小的 Web 服务器,用一个大约 3000 字节的 Tcl 源文件实现。
  •     

  • fnord,大小取决于平台和配置,不超过 20K。虽然很小,但是它支持虚拟主机、CGI 和 keep-alive。
  •     

  • ihttpd,使用不到 800 行的 C 代码,包括 CGI,并通过 inetd 提供页面。
  •     

  • im-httpd,非常小的服务器 —— 只有大约 7 KB,链接到 glibc。而且它也非常快。
  •     

  • mattows,支持 CGI,只有 600 行 C 代码。
  •     

  • Scrinchy,虽然很小,不到 30KB,但是支持多种脚本编制语言,包括一种特殊用途的、基于栈的 Sy 脚本语言。
  •     

  • ZWS 演示了一个即使是使用 500 多行带足够注释的 zsh (!) 编写的应用程序 —— 在这里是一个 HTTP 0.9+ 服务器 —— 也可以有多强大。

体积小并不妨碍这些服务器被正式使用。例如,fnord 可以处理数千个同时进行的连接。

 

也许轻量级作为一个类别最令人印象深刻的成就是高性能服务器:

        

  • cghttpd 是一个小型 Web 服务器,它被理解为使用 2.6 系列内核中可用的异步功能的一个试验品。
  •     

  • darkhttpd 是一个快速的、单线程的 HTTP/1.1 服务器。
  •     

  • Gatling 是为高性能设计的。它的特性包括 FTP、IPv6、虚拟主机、CGI 等。
  •     

  • Kernux 是一个 Linux 内核模块,它实现了一个 HTTP 守护进程。
  •     

  • lighttpd 是使用率排名第五的 Web 服务器(排名还在上升)。它为很多同时进行的连接进行了优化:“典型的场景是使用 lighttpd 作为一个下载(off-load)服务器,以提供静态内容……”
  •     

  • LiteSpeed Web Server 是一款轻量级商业 Web 服务器,强调性能和安全性。 LiteSpeed Technologies 公司宣传为静态内容提速了 6 倍,在解释页面方面也有一定的提高。
  •     

  • Miniature JWS,也称 tjws,它是基于 Java 的 Web 服务器,可以处理 servlet、JSP 和数千个并发连接,而大小只有 77 KB。它的作者声称它 “比 Apache 2.x 快 10%”。
  •     

  • Yaws 是用 Erlang 编写的一款高性能 HTTP/1.1 服务器。

 

有些 Web 服务器被实现为类或库,以便嵌入 到较大的应用程序中。 在这些 Web 服务器当中,我发现特别有趣的有:

        

  • EHS —— “嵌入式 HTTP 服务器”,被设计为一个 C++ 类,用于嵌入到较大的 C++ 应用程序;还有
  •     

  • Embedded TCL Web Server,它是一个很普通的 Web 服务器,支持 SSL 和 Basic Authentication,速度非常快 —— 其作者使它至少与 lighthttpd 和 AOLserver 一样快。它是用不到 100 行 Tcl 编写的。

 

Python 是几种适合不寻常环境的 Web 服务器的实现语言,这些 Web 服务器包括:

        

  • cdServer 是一个小型的、用 Python 编写的 HTTP 服务器,它 “被设计用来提供来自 CD-ROM 的(静态)内容” 。它在提供动态内容方面能力有限。我们有几个涉及不受影响的 “live CDs” 的项目,在这些项目中像 cdServer 之类的工具很关键。
  •     

  • edna,一款智能的用 Python 编写的 MP3 服务器,它是用 HTTP 实现的。

 

还有其他一些用 Perl 和其他不出名的语言编写的轻量级 Web 服务器:

        

  • Camlserv,用 ocaml 编写的一个完整的 Web 服务器,目标是 “高度交互式的 Web 页面”。它由几千行 ocaml 编写而成,其中大部分代码都与 MySQL 和 HTML 的特殊处理有关。
  •     

  • dhttpd 用和 Apache 相同的格式记录访问。它支持 CGI,并具有内建的 Perl 解释器、虚拟主机、IPv6、带宽管理和安全性等方面的特性。
  •     

  • DNHTTPD 是用 Perl 编写的,用于 UNIX®。它支持虚拟主机、SSL 连接、CGI 等。
  •     

  • Jellybean 是用 Perl 编写的基于 HTTP 的 Perl Object Server。
  •     

  • lns.http 是一个 Common LISP HTTP/1.1 Web 框架。
  •     

  • Mongrel 是用 Ruby 编写的、用于 HTTP 的一个库和服务器。
  •     

  • Nanoweb 是用 PHP 编写的一款快速、健壮的 Web 服务器。它宣称具有丰富的特性,包括完全遵从 HTTP/1.1、访问控制、身份验证、虚拟主机、SSL 兼容性等。
  •     

  • Naridesh 是用 Perl 编写的 Web 服务器。
  •     

  • OpenAngel 是用 Perl 编写的。它强调的重点是安全性。
  •     

  • Xavante 是用 Lua 编写的 HTTP/1.1 Web 服务器。
  •     

  • XSP 是用 C# 编写的,用于运行 ASP.NET。

 

有时候您可能需要其他一些用 C 编写的、具有不常见的次要优势的轻量级 Web 服务器:

        

  • ABYSS 可以在 UNIX 和 Win32 之间移植,其 “目的是成为完全遵从 HTTP/1.1 的 Web 服务器”。它占用的内存很少。
  •     

  • Anti-Web HTTPD(也称 “Anti-Web”、“awhttpd” 和 “AW”)是一款单进程、无线程、支持 CGI 的服务器,它强调安全性和简单性。
  •     

  • MHTTPD 支持从外部文件或 LDAP 服务器进行的 MHTTPD Basic Authentication。
  •     

  • mini-httpd 可以在一个系统线程中处理多个并发请求,但是在主机上占用的内存或 CPU 很少。
  •     

  • Naken Web 类似于很多其他的轻量级服务器 —— 它支持 Basic Authentication、静态内容等 —— 但是它的作者将它设计为用于 Webcam 操作,并且在 Gumstix、WRT54GL、OpenWrt 和其他新的平台上运行。
  •     

  • Null httpd 是一款多线程的、简单的、可移植的 Web 服务器。
  •     

  • Seminole 是一款商业 Web 服务器,内存需求较小,功能较多。
  •     

  • thttpd throttle,支持 chroot、 Basic Authentication 等。
        
        

Web 服务器远远不止是 Apache 和 IIS 的天下。您可以发现很多其他的 Web 服务器,它们很小,易于理解,但是又足够快,可以被正式使用。这样的 Web 服务器可以很好地加快您的下一个项目。

学习

获得产品和技术

Cameron Laird 长期为 developerWorks 撰稿,并且曾担任专栏作家。他经常撰写关于能加快其雇主的应用程序开发的开放源代码项目的文章,着重关注可靠性和安全性。

 摘自:http://www.ibm.com/developerworks/cn/web/wa-ltwebserv/

莫做电脑的奴隶

一年多来,一直在没日没夜地研究计算机技术,只希望能多学一些东西能挣很多钱;一年过去了,工资还是没有涨,而我却成了计算机的奴隶,没有计算机将无法工作,没有计算机也就没有了乐趣,没有了计算机我会疯掉的。

除了多知道一些计算机的东西,我什么也不会;买东西只能去超市,和人打交道,我注定是要失败的。我只了解计算机,不了解人。我下一步要做的就是,少了解计算机,多了解人,多参加一些公共场合的活动,尽量里计算机远一些。

关于内存泄漏

转自:http://baike.baidu.com/view/1068433.htm

内存泄漏

  也称作“存储渗漏

  用动态存储分配函数动态开辟的空间,在使用完毕后未释放,结果导致一直占据该内存单元。直到程序结束。即所谓内存泄漏。

  内存泄漏概念

  简单的说就是申请了一块内存空间,使用完毕后没有释放掉。它的一般表现方式是程序运行时间越长,占用内存越多,最终用尽全部内存,整个系统崩溃。由程序申请的一块内存,且没有任何一个指针指向它,那么这块内存就泄露了。

  泄漏的分类

  以发生的方式来分类,内存泄漏可以分为4类:

  (1). 常发性内存泄漏。发生内存泄漏的代码会被多次执行到,每次被执行的时候都会导致一块内存泄漏。

  (2). 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境,偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。

  (3). 一次性内存泄漏。发生内存泄漏的代码只会被执行一次,或者由于算法上的缺陷,导致总会有一块仅且一块内存发生泄漏。比如,在类的构造函数中分配内存,在析构函数中却没有释放该内存,所以内存泄漏只会发生一次。

  (4). 隐式内存泄漏。程序在运行过程中不停的分配内存,但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏,因为最终程序释放了所有申请的内存。但是对于一个服务器程序,需要运行几天,几周甚至几个月,不及时释放内存也可能导致最终耗尽系统的所有内存。所以,我们称这类内存泄漏为隐式内存泄漏。

  从用户使用程序的角度来看,内存泄漏本身不会产生什么危害,作为一般的用户,根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积,这会最终消耗尽系统所有的内存。从这个角度来说,一次性内存泄漏并没有什么危害,因为它不会堆积,而隐式内存泄漏危害性则非常大,因为较之于常发性和偶发性内存泄漏它更难被检测到。

  内存泄漏的表现

  

内存泄漏或者是说,资源耗尽后,系统会表现出什么现象哪?

  cpu资源耗尽:估计是机器没有反应了,键盘,鼠标,以及网络等等。这个在windows上经常看见,特别是中了毒。

  进程id耗尽:没法创建新的进程了,串口或者telnet都没法创建了。

  硬盘耗尽: 机器要死了,交换内存没法用,日志也没法用了,死是很正常的。

  内存泄漏或者内存耗尽:新的连接无法创建,free的内存比较少。发生内存泄漏的程序很多,但是要想产生一定的后果,就需要这个进程是无限循环的,是个服务进程。当然,内核也是无限循环的,所以,如果内核发生了内存泄漏,情况就更加不妙。内存泄漏是一种很难定位和跟踪的错误,目前还没看到有什么好用的工具(当然,用户空间有一些工具,有静态分析的,也会动态分析的,但是找内核的内存泄漏,没有好的开源工具)

  内存泄漏和对象的引用计数有很大的关系,再加上c/c++都没有自动的垃圾回收机制,如果没有手动释放内存,问题就会出现。如果要避免这个问题,还是要从代码上入手,良好的编码习惯和规范,是避免错误的不二法门。

  一般我们常说的内存泄漏是指堆内存的泄漏。

  堆内存是指程序从堆中分配的,大小任意的(内存块的大小可以在程序运行期决定),使用完后必须显示释放的内存。

  应用程序一般使用malloc,realloc,new等函数从堆中分配到一块内存,使用完后,程序必须负责相应的调用free或delete释放该内存块,否则,这块内存就不能被再次使用,我们就说这块内存泄漏了。

  (附)部分内存泄漏检测工具

  1.ccmalloc-Linux和Solaris下对C和C++程序的简单的使用内存泄漏和malloc调试库。

  2.Dmalloc-Debug Malloc Library.

  3.Electric Fence-Linux分发版中由Bruce Perens编写的malloc()调试库。

  4.Leaky-Linux下检测内存泄漏的程序。

  5.LeakTracer-Linux、Solaris和HP-UX下跟踪和分析C++程序中的内存泄漏。

  6.MEMWATCH-由Johan Lindh编写,是一个开放源代码C语言内存错误检测工具,主要是通过gcc的precessor来进行。

  7.Valgrind-Debugging and profiling Linux programs, aiming at programs written in C and C++.

  8.KCachegrind-A visualization tool for the profiling data generated by Cachegrind and Calltree.

  9.IBM Rational PurifyPlus-帮助开发人员查明C/C++、托管.NET、Java和VB6代码中的性能和可靠性错误。PurifyPlus 将内存错误和泄漏检测、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的工具包中。

  10.Parasoft Insure++-针对C/C++应用的运行时错误自动检测工具,它能够自动监测C/C++程序,发现其中存在着的内存破坏、内存泄漏、指针错误和I/O等错误。并通过使用一系列独特的技术(SCI技术和变异测试等),彻底的检查和测试我们的代码,精确定位错误的准确位置并给出详细的诊断信息。能作为Microsoft Visual C++的一个插件运行。

  11.Compuware DevPartner for Visual C++ BoundsChecker Suite-为C++开发者设计的运行错误检测和调试工具软件。作为Microsoft Visual Studio和C++ 6.0的一个插件运行。

  12.Electric Software GlowCode-包括内存泄漏检查,code profiler,函数调用跟踪等功能。给C++和.Net开发者提供完整的错误诊断,和运行时性能分析工具包。

  13.Compuware DevPartner Java Edition-包含Java内存检测,代码覆盖率测试,代码性能测试,线程死锁,分布式应用等几大功能模块。

  14.Quest JProbe-分析Java的内存泄漏。

  15.ej-technologies JProfiler-一个全功能的Java剖析工具,专用于分析J2SE和J2EE应用程序。它把CPU、执行绪和内存的剖析组合在一个强大的应用中。

  16.BEA JRockit-用来诊断Java内存泄漏并指出根本原因,专门针对Intel平台并得到优化,能在Intel硬件上获得最高的性能。

PHP数组求差 array_diff 与 array_diff_assoc

程序修改了之后,需要和以前的输出做比较,就是用了数组的求差函数array_diff() ,以前没用过,求出来的东西和我想要的不太一样,因为数组比较大,不太好看出问题,但是删除一部分之后,结果就正常了,终于在花费了3个小时的时间,发现了问题的所在;我渴望array_diff() 能比较key和value,而实际上它只比较了value,而不关心key,如果关心key的话,可以使用函数array_diff_assoc();

另外,php数组求交集的函数:

array_intersect — 计算数组的交集,只关心value,不关心key
array_intersect_assoc — 带索引检查计算数组的交集

知我者谓我心忧,不知我者谓我何求

出自诗经“知我者谓我心忧,不知我者谓我何求”,意思是知我的人呢说我正在心忧,不知我的人呢说我到底是为了什么呀。我不喜欢这个原创,更喜欢“知我者为我心忧,不知我者于我何求!”,当然这只是种理想主义状态,很多时候,我们经常忽视了别人,别人也常常没把自己当一回事。都是孤单的身影后寂聊的心情

原诗:

彼黍离离,彼稷之苗。
行迈靡靡,中心摇摇。
知我者,谓我心忧;
不知我者,谓我何求。
悠悠苍天,此何人哉。

彼黍离离,彼稷之穗。
行迈靡靡,中心如醉。
知我者,谓我心忧;
不知我者,谓我何求。
悠悠苍天,此何人哉。

彼黍离离,彼稷之实。
行迈靡靡,中心如噎。
知我者,谓我心忧;
不知我者,谓我何求。
悠悠苍天,此何人哉。

PHP 加速器 之 APC

下载地址:http://pecl.php.net/package/APC

 

配置详解:

apc.enabled boolean

apc.enabled can be set to 0 to disable APC. This is primarily useful when APC is statically compiled into PHP, since there is no other way to disable it (when compiled as a DSO, the extension line in php.ini can just be commented-out).
通过设置apc.enabled = 0 来禁用apc,这主要是当apc已经被静态编译到了php里了而又不想使用时很有用,因为没有其他的办法来禁用了

apc.shm_segments integer

The number of shared memory segments to allocate for the compiler cache. If APC is running out of shared memory but you have already set apc.shm_size as high as your system allows, you can try raising this value. Setting this to a  value other than 1 has no effect in mmap mode since mmap’ed shm segments don’t have size limits.(Default: 1)
这里设置可以使用多少个共享内存段,当一个共享内存段分配到系统允许的最大值还不够用时,就可以通过该项设置多个共享内存段,以增加缓存的大小;注意:使用mmap模式时,大于1的值是没有任何作用的,因为mmap的内存段是不受限制的;默认值为1

apc.shm_size integer

The size of each shared memory segment in MB. By default, some systems (including most BSD variants) have very low limits on the size of a shared memory segment.
设置每个共享内存段的大小,单位为MB

apc.optimization integer

The optimization level. Zero disables the optimizer, and higher values use more aggressive optimizations. Expect very modest speed improvements. This is experimental.
设置优化级别,0为不优化,值越大,优化级别越高,但是如果代码写的不太好,优化级别太高,难免会出问题。

apc.num_files_hint integer

A "hint" about the number of distinct source files that will be included or requested on your web server. Set to zero or omit if you’re not sure; this setting is mainly useful for sites that have many thousands of source files.
应该是最多允许缓存多少个文件的意思,默认为1024个;(如果我翻译的有问题可以留言)

apc.ttl integer

The number of seconds a cache entry is allowed to idle in a slot in case this cache entry slot is needed by another entry. Leaving this at zero means that your cache could potentially fill up with stale entries while newer entries won’t be cached.
如果缓存空间不够时,将清除缓存时间大于ttl(单位为:s)的一些cache来缓存新的文件,如果没有缓存时间大于ttl的cache或该ttl设置为0时,新的访问将不会被cache

apc.gc_ttl integer

The number of seconds that a cache entry may remain on the garbage-collection list. This value provides a failsafe in the event that a server process dies while executing a cached source file; if that source file is modified, the memory allocated for the old version will not be reclaimed until this TTL reached. Set to zero to disable this feature.
{不知道啥意思}

apc.cache_by_default boolean

On by default, but can be set to off and used in conjunction with positive apc.filters so that files are only cached if matched by a positive filter.
默认缓存任何可以缓存的文件,如果设置为off,将根据apc.filter来缓存允许缓存的文件

apc.filters string

A comma-separated list of POSIX extended regular expressions. If any pattern matches the source filename, the file will not be cached. Note that the filename used for matching is the one passed to include/require, not the absolute path. If the first character of the expression is a + then the expression will be additive in the sense that any files matched by the expression will be cached, and if the first character is a then anything matched will not be cached. The case is the default, so it can be left off.
是逗号分隔的正则表达式的列表,匹配的是文件名,后面的加号表示缓存,减号表示不缓存{现在没时间了,具体用法以后补充}

apc.mmap_file_mask string

If compiled with MMAP support by using –enable-mmap this is the mktemp-style file_mask to pass to the mmap module for determing whether your mmap’ed memory region is going to be file-backed or shared memory backed. For straight file-backed mmap, set it to something like /tmp/apc.XXXXXX (exactly 6 Xs). To use POSIX-style shm_open/mmap put a .shm somewhere in your mask. e.g. /apc.shm.XXXXXX You can also set it to /dev/zero to use your kernel’s /dev/zero interface to anonymous mmap’ed memory. Leaving it undefined will force an anonymous mmap.

apc.slam_defense integer

On very busy servers whenever you start the server or modify files you can create a race of many processes all trying to cache the same file at the same time. This option sets the percentage of processes that will skip trying to cache an uncached file. Or think of it as the probability of a single process to skip caching. For example, setting apc.slam_defense to 75 would mean that there is a 75% chance that the process will not cache an uncached file. So, the higher the setting the greater the defense against cache slams. Setting this to 0 disables this feature.

apc.file_update_protection integer

When you modify a file on a live web server you really should do so in an atomic manner. That is, write to a temporary file and rename (mv) the file into its permanent position when it is ready. Many text editors, cp, tar and other such programs don’t do this. This means that there is a chance that a file is accessed (and cached) while it is still being written to. This apc.file_update_protection setting puts a delay on caching brand new files. The default is 2 seconds which means that if the modification timestamp (mtime) on a file shows that it is less than 2 seconds old when it is accessed, it will not be cached. The unfortunate person who accessed this half-written file will still see weirdness, but at least it won’t persist. If you are certain you always atomically update your files by using something like rsync which does this correctly, you can turn this protection off by setting it to 0. If you have a system that is flooded with io causing some update procedure to take longer than 2 seconds, you may want to increase this a bit.

apc.enable-cli integer

Mostly for testing and debugging. Setting this enables APC for the CLI version of PHP. Normally you wouldn’t want to create, populate and tear down the APC cache on every CLI request, but for various test scenarios it is handy to be able to enable APC for the CLI version of APC easily.

安装:
tar xvf apc_x.y.tar
cd apc_x.y
./configure –enable-apc  –enable-apc-mmap
make
make install

配置:

  extension=apc.so
  apc.enabled=1
  apc.shm_segments=1
  apc.shm_size=128
  apc.ttl=7200
  apc.user_ttl=7200
  apc.num_files_hint=1024
  apc.mmap_file_mask=/tmp/apc.XXXXXX
  apc.enable_cli=1

使用:

1. 源码里都有一个apc.php ,放到网站目录下,可以通过给文件知道apc的使用情况

PHP加速器性能比较

转录某公司进行的PHP加速器性能比较报告:

Product / Test1 / Test2 / Test3
===========================
Reines PHP 5.1.4 / 100% / 100% / 100%
——————————————————
APC 3.0.10 / 112% / 409% / 145%
——————————————————
eAccelerator 0.9.5rc1 / 109% / 447% / 140%
——————————————————
Xcache 1.0.1rc1 / 119% / 95% / 111%
——————————————————
Zend Plattform 2.2.1 / 129% / 386% / 127%
——————————————————

PHP debug 工具 之 APD

首先郑重声明php不是必须以cgi方式运行才可以使用apd

所以手册里面的 Make sure you have installed the CGI version of PHP and it is available in your current path along with the phpize script.

有误导

首先去http://pecl.php.net/package/apd 下载对用的apd包

我下载的apd-1.0.1.tgz,没有找见win下的dll,不过有源码可以直接编译dll

解压缩

然后正常的 编译 安装 可以参考 xdebug部分的安装

配置php.ini

[apd]

;注意是zend_extension 不是extension,是绝对路径,不能是相对路径,手册上有说明,多看看手册在测试
zend_extension=/data/app/php/lib/php/extensions/no-debug-non-zts-20050922/apd.so
apd.dumpdir = /data/website/apd
apd.statement_tracing = 0

apd.dumpdir 是日志地址

这里需要注意的是

zend_extension 千万别 extension 否则

PHP Warning: PHP Startup: Invalid library (maybe not a PHP library) ‘apd.so’ in Unknown on line 0

然后就可以做实验了

<?php

apd_set_pprof_trace();

XXXXX

?>

分析日志的方法 手册里这样写到

pprofp -R /tmp/pprof.22141.0

注意这里的pprofp 在你编译好的 apd的源码目录 其实就是一个php文件

这里你要修改pprofp文件开头的 php路径 才可以正常执行

php 以cgi方式运行的时候 据说 记着 -e参数 (看手册)

分析出来的结果 很帅吧

Trace for /XXXX.php
Total Elapsed Time = 0.54
Total System Time = 0.06
Total User Time    = 0.13

         Real         User        System             secs/    cumm
%Time (excl/cumm) (excl/cumm) (excl/cumm) Calls    call    s/call Memory Usage Name
————————————————————————————–
100.0 0.00 0.54 0.00 0.13 0.00 0.06     1 0.0000   0.5362            0 main
100.0 0.00 0.54 0.00 0.13 0.00 0.06     1 0.0000   0.5362            0 apd_set_pprof_trace
98.7 0.04 0.53 0.01 0.12 0.00 0.06    14 0.0026   0.0378            0 require
83.4 0.00 0.45 0.00 0.10 0.00 0.04     1 0.0004   0.4471            0 DataProxy->run
61.1 0.33 0.33 0.02 0.02 0.00 0.00     5 0.0656   0.0656            0 DataProxy->getModule
10.1 0.00 0.05 0.00 0.03 0.00 0.02     1 0.0000   0.0542            0 MusicModule->onResponse
7.0 0.00 0.04 0.00 0.02 0.00 0.02     3 0.0003   0.0125            0 MusicModule->mr_param
6.8 0.04 0.04 0.02 0.02 0.02 0.02     3 0.0122   0.0122            0 MusicModule->mr_encrypt
5.8 0.00 0.03 0.00 0.02 0.00 0.01     1 0.0000   0.0308            0 NEWSModule->onResponse
5.3 0.00 0.03 0.00 0.01 0.00 0.00     1 0.0000   0.0286            0 Query->processRawQuery
5.0 0.03 0.03 0.02 0.02 0.01 0.01   193 0.0001   0.0001            0 Query->get
3.9 0.02 0.02 0.02 0.02 0.01 0.01    15 0.0014   0.0014            0 fetime
3.8 0.01 0.02 0.01 0.02 0.01 0.01    23 0.0006   0.0009            0 include
3.0 0.02 0.02 0.00 0.00 0.00 0.00     1 0.0161   0.0161            0 xml_iconv
2.6 0.01 0.01 0.00 0.00 0.00 0.00    32 0.0004   0.0004            0 html_substr
2.4 0.00 0.01 0.00 0.02 0.00 0.00    10 0.0000   0.0013            0 ModuleFactory->createModule
2.2 0.00 0.01 0.00 0.01 0.00 0.00     1 0.0000   0.0118            0 BlogModule->onResponse
1.4 0.00 0.01 0.00 0.00 0.00 0.00     1 0.0001   0.0077            0 MusicModule->get_rings
1.4 0.01 0.01 0.00 0.00 0.00 0.00     1 0.0075   0.0075            0 curl_fetch
1.1 0.00 0.01 0.00 0.00 0.00 0.00     5 0.0000   0.0012            0 add_tag_html_substr

最遥远的距离[中英文对照版]

世界上最远的距离 
不是 生与死的距离 
而是 我站在你面前 
你不知道我爱你 

世界上最远的距离 
不是 我站在你面前 
你不知道我爱你 
而是 爱到痴迷 
却不能说我爱你 

世界上最远的距离 
不是 我不能说我爱你 
而是 想你痛彻心脾 
却只能深埋心底 

世界上最远的距离 
不是 我不能说我想你 
而是 彼此相爱 
却不能够在一起 

世界上最远的距离 
不是 彼此相爱 
却不能够在一起 
而是明知道真爱无敌 
却装作毫不在意 

世界上最远的距离 
不是 树与树的距离 
而是 同根生长的树枝 
却无法在风中相依 

世界上最远的距离 
不是 树枝无法相依 
而是 相互了望的星星 
却没有交汇的轨迹 

世界上最远的距离 
不是 星星之间的轨迹 
而是 纵然轨迹交汇 
却在转瞬间无处寻觅 

世界上最远的距离 
不是 瞬间便无处寻觅 
而是 尚未相遇 
便注定无法相聚 

世界上最远的距离 
是鱼与飞鸟的距离 
一个在天,一个却深潜海底 

The most distant way in the world 

The most distant way in the world 
is not the way from birth to the end. 
it is when i sit near you 
that you don’t understand i love u. 

The most distant way in the world 
is not that you’re not sure i love u. 
It is when my love is bewildering the soul 
but i can’t speak it out. 

The most distant way in the world 
is not that i can’t say i love u. 
it is after looking into my heart 
i can’t change my love. 

The most distant way in the world 
is not that i’m loving u. 
it is in our love 
we are keeping between the distance. 

The most distant way in the world 
is not the distance across us. 
it is when we’re breaking through the way 
we deny the existance of love. 

So the most distant way in the world 
is not in two distant trees. 
it is the same rooted branches 
can’t enjoy the co-existance. 

So the most distant way in the world 
is not in the being sepearated branches. 
it is in the blinking stars 
they can’t burn the light. 

So the most distant way in the world 
is not the burning stars. 
it is after the light 
they can’t be seen from afar. 

So the most distant way in the world 
is not the light that is fading away. 
it is the coincidence of us 
is not supposed for the love. 

So the most distant way in the world 
is the love between the fish and bird. 
one is flying at the sky, 
the other is looking upon into the sea.