Apache编译mod_python3.3.1错误解决
[ 2009/06/18 02:52 | by selboo ]
apache2.2.11编译mod_python报错
编译安装mod_python3.3.1
./configure –with-apxs=/usr/local/apache/bin/apxs –with-python=/usr/bin/python2.4
make
make install
如果提示如下错误:
…..
make: *** [do_dso] Error 2
需要修改 mod_python-3.3.1/src/connobject.c
原:
!(b == APR_BRIGADE_SENTINEL(b)
改为:
!(b == APR_BRIGADE_SENTINEL(bb)
编译安装mod_python3.3.1
./configure –with-apxs=/usr/local/apache/bin/apxs –with-python=/usr/bin/python2.4
make
make install
如果提示如下错误:
…..
make: *** [do_dso] Error 2
需要修改 mod_python-3.3.1/src/connobject.c
原:
!(b == APR_BRIGADE_SENTINEL(b)
改为:
!(b == APR_BRIGADE_SENTINEL(bb)
Web 服务器架构史
[ 2009/03/27 22:43 | by selboo ]
架构演变第一步：物理分离webserver和数据库
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝 到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝 到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；
衡量web性能一个性能等式
[ 2009/03/16 23:12 | by selboo ]
给大家分享一个衡量 Web 应用程序性能的一个公式,今天不经意中看到了这个公式,感觉获益良多,并做了一点小小的修改,在这里分享给大家,希望对大家有所帮助.
R=吞吐量/带宽+RTT+Appturns(RTT)/并发请求+Cs+Cc
这个公式来源于2006 年 9 月,NetForecast 的 Peter Sevcik 和 Rebecca Wetzel 发表了一篇名为 "Field Guide to Application Delivery Systems" 的论文利用此公式事实上,如果想在 Web 站点中嵌入调试模式以利用这一性能等式,可以对所有这些元素自行编写代码.这样做有充分的理由：如果能够定期在浏览器中列出性能等式元素,则很容易就可以检测出存在性能问题的位置.以下一些参数的说明变量 定义
R 响应时间.从用户请求页面(通过单击链接等操作)到整个页面全部呈现在用户计算机中所需的总时间.通常以秒为测量单位. 负载 发送到浏览器的字节总数,包括标记和所有资源(例如,CSS、JS 和图像文件等).
带宽 与浏览器之间的传输率.这可能是不对称的,如果给定页面是从多个源生成的,这可能表示多个速度.通常情况下,会加总取一平均值作为单一带宽,单位为字节/秒. AppTurns 给定页面所需的资源文件数.这些资源文件包括 CSS、JS、图像等,还包括浏览器在页面显示过程中检索的任何其他文件.在此等式中,HTML 页面是通过在 AppTurns 表达式之前加上往返时间 (RTT) 单独计算的. RTT 往返所需的时间,与传输的字节无关.对于页面本身,每个请求至少需要耗用一个 RTT.通常以毫秒为测量单位. 并发请求 浏览器同时发出的请求资源文件的请求数.默认情况下,Internet Explorer 执行两个并发请求.此设置可以进行调整,但很少这样做. Cs 服务器上的计算时间.这是运行代码、从数据库检索数据以及合成要发送到浏览器的响应所需的时间.测量单位为毫秒.Cc 客户端上的计算时间.这是浏览器在屏幕上实际显示 HTML、执行 JavaScript、实施 CSS 规则等所需的时间.
RTT(Round-Trip Time): 往返时延,在计算机网络中它也是一个重要的性能指标,它表示从发送端发送数据开始,到发送端收到来自接收端的确使用过LoadRunner的朋友都知道我们能够很容易知道一个业务的吞吐量,AppTurns.对于RTT,并发请求我们能够很容易获得.认(接收端收到数据后便立即发送确认)
对于业务的吞吐量,R响应时间,AppTurns.宽带,RTT,我们可以通过去时些性能测试工具很容易获得.
对于Cs和CC在 ASP.NET 页面中,很容易就可以编写代码来记录页面开始执行的准确时间,然后再将其从执行完成时的当时时间中减掉.客户端也是如此；可在 HTML 页面顶部执行一段 JavaScript 来记录开始时间,然后当页面执行完毕并触发了 OnLoad 事件时将其从当时时间中减掉.事实上,如果想在 Web 站点中嵌入调试模式以利用这一性能等式,可以对所有这些元素自行编写代码.这样做有充分的理由：如果能够定期在浏览器中列出性能等式元素,则很容易就可以检测出存在性能问题的位置.例如,假设您的 ASP.NET 应用程序的用户都位于其他洲,而且使用的是低带宽.由于 ping 时间较高 (> 200ms) 而带宽较低 (< 500kbps),所以这些用户非常容易受应用程序总负载和往返次数的影响.这时您必须站在这些用户的角度来审视您的应用程序,因为他们的体验与您的体验截然不同.
R=吞吐量/带宽+RTT+Appturns(RTT)/并发请求+Cs+Cc
这个公式来源于2006 年 9 月,NetForecast 的 Peter Sevcik 和 Rebecca Wetzel 发表了一篇名为 "Field Guide to Application Delivery Systems" 的论文利用此公式事实上,如果想在 Web 站点中嵌入调试模式以利用这一性能等式,可以对所有这些元素自行编写代码.这样做有充分的理由：如果能够定期在浏览器中列出性能等式元素,则很容易就可以检测出存在性能问题的位置.以下一些参数的说明变量 定义
R 响应时间.从用户请求页面(通过单击链接等操作)到整个页面全部呈现在用户计算机中所需的总时间.通常以秒为测量单位. 负载 发送到浏览器的字节总数,包括标记和所有资源(例如,CSS、JS 和图像文件等).
带宽 与浏览器之间的传输率.这可能是不对称的,如果给定页面是从多个源生成的,这可能表示多个速度.通常情况下,会加总取一平均值作为单一带宽,单位为字节/秒. AppTurns 给定页面所需的资源文件数.这些资源文件包括 CSS、JS、图像等,还包括浏览器在页面显示过程中检索的任何其他文件.在此等式中,HTML 页面是通过在 AppTurns 表达式之前加上往返时间 (RTT) 单独计算的. RTT 往返所需的时间,与传输的字节无关.对于页面本身,每个请求至少需要耗用一个 RTT.通常以毫秒为测量单位. 并发请求 浏览器同时发出的请求资源文件的请求数.默认情况下,Internet Explorer 执行两个并发请求.此设置可以进行调整,但很少这样做. Cs 服务器上的计算时间.这是运行代码、从数据库检索数据以及合成要发送到浏览器的响应所需的时间.测量单位为毫秒.Cc 客户端上的计算时间.这是浏览器在屏幕上实际显示 HTML、执行 JavaScript、实施 CSS 规则等所需的时间.
RTT(Round-Trip Time): 往返时延,在计算机网络中它也是一个重要的性能指标,它表示从发送端发送数据开始,到发送端收到来自接收端的确使用过LoadRunner的朋友都知道我们能够很容易知道一个业务的吞吐量,AppTurns.对于RTT,并发请求我们能够很容易获得.认(接收端收到数据后便立即发送确认)
对于业务的吞吐量,R响应时间,AppTurns.宽带,RTT,我们可以通过去时些性能测试工具很容易获得.
对于Cs和CC在 ASP.NET 页面中,很容易就可以编写代码来记录页面开始执行的准确时间,然后再将其从执行完成时的当时时间中减掉.客户端也是如此；可在 HTML 页面顶部执行一段 JavaScript 来记录开始时间,然后当页面执行完毕并触发了 OnLoad 事件时将其从当时时间中减掉.事实上,如果想在 Web 站点中嵌入调试模式以利用这一性能等式,可以对所有这些元素自行编写代码.这样做有充分的理由：如果能够定期在浏览器中列出性能等式元素,则很容易就可以检测出存在性能问题的位置.例如,假设您的 ASP.NET 应用程序的用户都位于其他洲,而且使用的是低带宽.由于 ping 时间较高 (> 200ms) 而带宽较低 (< 500kbps),所以这些用户非常容易受应用程序总负载和往返次数的影响.这时您必须站在这些用户的角度来审视您的应用程序,因为他们的体验与您的体验截然不同.
