DNS劫持监控
{DNS}DNS劫持监控:检查根服务和授权域服务器。
比如:dig 51.com +trace
{DNS}DNS劫持监控:检查根服务和授权域服务器。
比如:dig 51.com +trace
DNS管理系统终于上线了,嘿嘿:)
丫的就知道自己爽了,也不晒出来给兄弟们看看
从去年就喊着要开发DNS管理,到今天才算完整了第1个版本,目前是Beta1.0,功能:
未来的功能:
睡觉:)
不了解组成Web站点元素,就没办法进行架构的设计,犹如厨师不知道有哪些材料,那他如何做的出可口的菜肴?
从外到里:
返回上一章:《S2:性能参数》
诊断问题时,第一步将问题分为五种类别:
l DNS查找时间
l 连接建立时间
l 服务器停止时间
l 传输时间
l 连接关闭时间
这些步骤的顺序总是这样的。
以下指导原则可以解决可能出现的五种瓶颈:
l 如果DNS是瓶颈所在,那么可能是测试脚本指定的local dns链路不好,或者是我们的域名的DNS链路不好。
l 如果连接时间是瓶颈,则一定是网络存在问题。可能是连接建立时,由于网路设备超载而丢失了一个数据包。路由器、交换机、线缆、网卡也都可能出现问题,都应该进行检查。
l 如果服务器静止时间是瓶颈,则服务器可能会出现某种程度的超载,更换为更好的硬件或使用更加优化的服务器应用程序或数据库即可解决这个问题。
l 如果传输时间是瓶颈,则问题在于客户端连接速度太慢,或者是要传输的内容过大所致。
l 如果连接关闭是瓶颈,则仍然是网络问题。
另一种了解站点情况的不错的方法是在创建和断开连接时观察连接。可以在Web服务器、中间件或者数据库的某个回路中运行netstat。
对服务器的响应大小的分布有一些了解是十分重要的。根据响应大小的分布信息,你可以决定使用多少台服务器、每台服务器针对不同的响应大小这种方式对你是否有意义。
通过日志的分析,就可以很快找到访问频率最高的用户的IP地址。
可以用哦个lsof -i:port来识别进程,
或者fuser 80/tcp
fuser还可以用于找出谁在使用Linux上的特定文件。fuser filename,则可以报告除所有使用该文件的pid。
只需找到进程ID,然后在/proc下查找该数字即可。在/proc下,将会找到名为fd的目录,在该目录中,每个文件描述符都是到一个真实文件的符号连接。如:我的Web服务器的pid是7428,则有:
# ls -l /proc/7428/fd
total 10
lrwx—— 1 root root 64 Sep 30 21:55 0 -> /dev/null
lrwx—— 1 root root 64 Sep 30 21:55 1 -> /dev/null
lrwx—— 1 root root 64 Sep 30 21:55 2 -> /dfs/web/nginx-0.5.35/logs/error.log
lrwx—— 1 root root 64 Sep 30 21:55 3 -> /dfs/web/nginx-0.5.35/logs/error.log
lrwx—— 1 root root 64 Sep 30 21:55 4 -> /dfs/web/nginx-0.5.35/logs/acc.log
lrwx—— 1 root root 64 Sep 30 21:55 5 -> socket:[7195389]
lrwx—— 1 root root 64 Sep 30 21:55 6 -> socket:[7195392]
lrwx—— 1 root root 64 Sep 30 21:55 7 -> socket:[7195393]
lrwx—— 1 root root 64 Sep 30 21:55 8 -> socket:[7195395]
lrwx—— 1 root root 64 Sep 30 21:55 9 -> socket:[7195396]
要知道这个问题的答案,可以简单的将数据库中的一个关键数据表锁住并查看在Web站点上会发生什么情况。
这样做往往会出现以下几种原因:
l 一种原因是为了查看在点击该Web站点的用户达到一定的数量后,数据库中有多少用户请求在列队等待;
l 另外,你使用这种方法来模拟一个过于繁忙的数据库,查看有何影响;
l 还可以用来检验某个特定的页面是否是依赖数据库而存在。
l 获取一份清晰详尽地标明了所有服务器和连接情况的拓扑结构图。
l 首先应当考虑改变最高层(即体系结构),找到那些可以省去的步骤和机器。最低层的优化应当留到以后再做,因为从低层的优化获得的收益较小,而且在低层优化时的任何变动都有可能造成体系结构的大幅度改变。
l 最有可能产生性能问题的是“自产”的应用程序、高级别的体系结构、数据库、网络和硬盘。
l 尽量在系统上没有其他用户或进程时运行负载测试,一般可能是在晚上,这样可以发现当前配置可能的最佳性能。这有助于清楚地了解差的应用程序和系统上的过渡负载之间的差别。如果在只存在一个没有网路负载的单独用户时性能很差,那么问题可能处在应用程序上。如果性能是间歇性地变差,则应当查找应用程序处理的低效率错误。
l 监控进程的大小,以查找内存泄露。
l 使用日志文件查找错误。
l 检查物理线缆的连接,查找是否因线路纠结或接口处的问题影响性能,比如过于接近荧光灯或无线发送装置。
记住,性能问题的产生即意味着引起某处的用户的不满,成功解决性能问题则意味着使这些用户满意,其满意程度甚至会超过替他们解决所有技术问题所带来的快乐。
l 去了解一下哪些工具可用于将活动映射为PID。
l 不要过分相信日志文件的正确性。
l 记住日志文件记录的是响应完成时的时间,而不是响应开始时的时间。
4.6 我的进程正在使用哪些文件?
用
lsof -p PID
应该比较方便:)
英文地址:http://developer.yahoo.com/performance/rules.html
中文地址:http://www.dudo.org/article.asp?id=218
我们在前面的几节中分别讲了提高网站性能中内容、服务器、JavaScript和CSS等方面的内容。除此之外,图片和Coockie也是我们网站中几乎不可缺少组成部分,此外随着移动设备的流行,对于移动应用的优化也十分重要。这主要包括:
Coockie:
图片:
移动应用:
英文地址:http://developer.yahoo.com/performance/rules.html
中文地址:http://www.dudo.org/article.asp?id=216
在第一部分和第二部分中我们分别介绍了改善网站性能中页面内容和服务器的几条守则,除此之外,JavaScript和CSS也是我们页面中经常用到的内容,对它们的优化也提高网站性能的重要方面:
CSS:
JavaScript
英文地址:http://developer.yahoo.com/performance/rules.html
中文地址:http://www.dudo.org/article.asp?id=215
在本系列的第一节中,讲了提高网站性能中网站“内容”有关的10条原则。除了在网站在内容上的改进外,在网站服务器端上也有需要注意和改进的地方,它们包括:
英文地址:http://developer.yahoo.com/performance/rules.html
中文地址:http://www.dudo.org/article.asp?id=214
Yahoo!的Exceptional Performance团队为改善Web性能带来最佳实践。他们为此进行了一系列的实验、开发了各种工具、写了大量的文章和博客并在各种会议上参与探讨。最佳实践的核心就是旨在提高网站性能。
Excetional Performance团队总结出了一系列可以提高网站速度的方法。可以分为7大类34条。包括内容、服务器、cookie、CSS、JavaScript、图片、移动应用等七部分。
其中内容部分一共十条建议:
一、内容部分
dnstracer
http://www.mavetju.org/unix/dnstracer.php
dnstracer determines where a given Domain Name Server (DNS) gets its information from, and follows the chain of DNS servers back to the servers which know the data.
可以通过nstracer查到域名那个上级nameserver,很不错的工具:)
要实现bind view的同步以前需要在slave的机器上加上多个IP才可以,其实更简单的方法可以结合TSIG来实现。
具体实现方法可以见: 《DNS TSIG实现CDN+GSLB》
其实很简单,关键是要仔细,特别提醒:注意权限。
suchasplus 16:35 on 2010 年 09 月 08 日 链接地址
稳定性方面…IBM>HP>DELL