分享IT基础设施知识与经验,如未注明[转载]的文章均为原创文章,如需转载请注明来源于: http://www.it-infra.cn,谢谢!
作者: Luke Lai | 同意转载, 转载时请以超链接形式标明文章原始出处,谢谢!
网址: http://www.it-infra.cn/SSL_Troubleshooting/

Troubleshooting SSL

SSLDUMP: http://www.rtfm.com/ssldump
– 提供SSL解密及详细命令

HTTPWATCH: http://www.httpwatch.com
– 在浏览器中安装为插件


SSLDUMP解密前(Application Data):




SSLDUMP解密后(Application Data):
Tags:
转自《亿万用户网站MySpace的成功秘密》 ◎ 文 / David F. Carr 译 / 罗小平
增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统,以期与自身的成长同步——目前,该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分,但那些指望迈入庞大在线市场的人,可以从MySpace的成长过程学到知识。



用户的烦恼

Drew,是个来自达拉斯的17岁小伙子,在他的MySpace个人资料页上,可以看到他的袒胸照,看样子是自己够着手拍的。他的好友栏全是漂亮姑娘和靓车的链接,另外还说自己参加了学校田径队,爱好吉他,开一辆蓝色福特野马。

不过在用户反映问题的论坛里,似乎他的火气很大。“赶紧弄好这该死的收件箱!”他大写了所有单词。使用MySpace的用户个人消息系统可以收发信息,但当他要查看一条消息时,页面却出现提示:“非常抱歉……消息错误”。

Drew的抱怨说明1.4亿用户非常重视在线交流系统,这对MySpace来说是个好消息。但也恰是这点让MySpace成了全世界最繁忙的站点之一。

11月,MySpace的美国国内互联网用户访问流量首次超过Yahoo。comScore Media Metrix公司提供的资料显示,MySpace当月访问量为387亿,而Yahoo是380.5亿。
显然,MySpace的成长太快了——从2003年11月正式上线到现在不过三年。这使它很早就要面对只有极少数公司才会遇到的高可扩展性问题的严峻挑战。事实上,MySpace的Web服务器和数据库经常性超负荷,其用户频繁遭遇“意外错误”和“站点离线维护”等告示。包括Drew在内的 MySpace用户经常无法收发消息、更新个人资料或处理其他日常事务,他们不得不在论坛抱怨不停。

尤其是最近,MySpace可能经常性超负荷。因为Keynote Systems公司性能监测服务机构负责人Shawn White说,“难以想象,在有些时候,我们发现20%的错误日志都来自MySpace,有时候甚至达到30%以至40%……而Yahoo、 Salesforce.com和其他提供商用服务的站点,从来不会出现这样的数字。”他告诉我们,其他大型站点的日错误率一般就1%多点。

顺便提及,MySpace在2006年7月24号晚上开始了长达12小时的瘫痪,期间只有一个可访问页面——该页面解释说位于洛杉矶的主数据中心发生故障。为了让大家耐心等待服务恢复,该页面提供了用Flash开发的派克人(Pac-Man)游戏。Web站点跟踪服务研究公司总经理Bill Tancer说,尤其有趣的是,MySpace瘫痪期间,访问量不降反升,“这说明了人们对MySpace的痴迷——所有人都拥在它的门口等着放行”。现 Nielsen Norman Group 咨询公司负责人、原Sun Microsystems公司工程师,因在Web站点方面的评论而闻名的Jakob Nielsen说,MySpace的系统构建方法显然与Yahoo、eBay以及Google都不相同。和很多观察家一样,他相信MySpace对其成长速度始料未及。“虽然我不认为他们必须在计算机科学领域全面创新,但他们面对的的确是一个巨大的科学难题。”他说。

MySpace开发人员已经多次重构站点软件、数据库和存储系统,以满足爆炸性的成长需要,但此工作永不会停息。“就像粉刷金门大桥,工作完成之时,就是重新来过之日。”(译者注:意指工人从桥头开始粉刷,当到达桥尾时,桥头涂料已经剥落,必须重新开始)MySpace技术副总裁Jim Benedetto说。既然如此,MySpace的技术还有何可学之处?因为MySpace事实上已经解决了很多系统扩展性问题,才能走到今天。

Benedetto说他的项目组有很多教训必须总结,他们仍在学习,路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统,以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。

Tags:
by Luke Lai | 不指定 2009/02/19 23:24 | 网站系统架构 | 评论(0) | 引用(0) | 阅读(65)

本文转自:
现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片,如果前期没有很好的规划,那么随着图片文件的增多,无论是管理还是性能上都带来很多问题。就自己的一点理解,抛砖引玉,以期能引出更具价值的信息。

事关图片的存储

把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备,那么简单的很;如果有能力自己开发单独存储图片的文件系统,那么也不用接着往下看了。

如果上述条件不具备,只想在普通的硬盘上存储,首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的,实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ,怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑,选择合适大小的 inode size ,在空间和速度上做取舍,同时防患于未然,注意单个文件系统下文件个数别达到极限。

独立,独立的服务器

无论从管理上,还是从性能上看,只要有可能,尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后,在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd

如果不想在几台机器间同步所有图片,只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题,以及 NFS 特定的传输速度。

独立,独立的域名

如果大部分 Web 页面必须要载入很多图片,那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。

前几天有个朋友在线上问我,”一些大网站,图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?” ,粗糙一点的答案:除了管理方便,便于CDN 同步处理,上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知,有请 Yahoo!的同学发言) 【还有一个我没考虑到的是 Cookie 的因素,参加楼下高春辉的留言】

写在前面,本文转载张宴同学的,这篇文章写得相当不错,图文并茂,非常仔细,我只截取了前言方案的介绍,具体配置需要与时俱进,具体还请跟进张宴的原文,谢谢,另外我个人觉得Nginx还有一个很大用途是可以分流Crawler的流量,这对于数据库压力比较大的动态网页尤其实用,通过一定的逻辑(如同一源IP地每秒请求大于XXX的流量导到另外一普通WEB服务器+普通数据库,正常用户及大搜索引擎VIP待遇,垃圾Crawler导向普通性能的服务免得拖跨主服务)

[文章作者:张宴 本文版本:v4.12 最后修改:2009.01.17 转载请注明原文链接:http://blog.s135.com/post/366.htm]

  前言:本文是我撰写的关于搭建“Nginx + PHP(FastCGI)”Web服务器的第4篇文章。本系列文章作为国内最早详细介绍 Nginx + PHP 安装、配置、使用的资料之一,为推动 Nginx 在国内的发展产生了积极的作用。这是一篇关于Nginx 0.7.x系列版本的文章,安装、配置方式与第3篇文章相差不大,但配置参数有不同。Nginx 0.7.x系列版本虽然为开发版,但在很多大型网站的生产环境中已经使用。

  

  Nginx ("engine x") 是一个高性能的 HTTP 和反向代理服务器,也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,它已经在该站点运行超过两年半了。Igor 将源代码以类BSD许可证的形式发布。

  Nginx 超越 Apache 的高性能和稳定性,使得国内使用 Nginx 作为 Web 服务器的网站也越来越多,其中包括新浪博客新浪播客网易新闻等门户网站频道,六间房56.com等视频分享网站,Discuz!官方论坛水木社区等知名论坛,豆瓣YUPOO相册海内SNS迅雷在线等新兴Web 2.0网站。

Tags:

作者: Luke Lai | 同意转载, 转载时请以超链接形式标明文章原始出处,谢谢!
网址: http://www.it-infra.cn/Ultradns_vs_IP_Anycast/

今天又收到Ultradns发过来的每月Intenet infrastructure的邮件,其中有条挺有意思的,是关于IP Anycast,中文翻译应该叫IP任播吧。曾经跟Ultradns相关的技术经理沟通过Ultradns的架构,感觉那哥们跟偏重于商务,技术都是美国那边控制着,包括在中国建点也是美国那边直派技术人员过来,其实Ultradns的技术还是挺牛。

听说销售最好的业务员没有比较最差的业务员多打几个电话,这里可以看得出来,销售最牛的业务员一定有自己实现的方法,一定跟其它的业务员有区别。随着对Ultradns的了解,觉得Ultradns还是真有自己的一套。它的基础架构跟一般我们从书中上学到的DNS架构完全不一样。其中就是核心架构IP Anycast + BGP。

关于IP Anycast简单解释Neustart公司这么说的:

引用
IP Anycast is one of the key tenets of the UltraDNS Managed DNS Service. Simply put, it is the ability to advertise the same public IP addresses out of multiple machines. This capability is usually combined with the Border Gateway Protocol (BGP).
大概的意思是IP Anycast可以把好多台机器整成一个公网IP地址,然后通过BGP宣告给运营商。
引用
When combined with IP Anycast, it may be used to route packets to the closest, most available instance of a service, such as DNS. In the event of a node outage, BGP route announcements are automatically updated (the address for that node is withdrawn as a viable destination) and traffic is redirected to the next closest topological node.
通过宣告路由给运营商实现客户端就近访问,以及节点失败后,服务自动转移等功能。

引用
DNS is ideally suited to the use of an IP Anycast infrastructure because the vast majority of DNS queries are sent using the User Datagram Protocol (UDP) as its transport mechanism. UDP is a best effort protocol and as such cannot guarantee delivery. By using IP Anycast to bring the answer for a DNS query closer to the end user, it becomes far more likely that the query will reach its destination and be responded to quickly.
相信大家都看得懂这小段英文,这几句看起来非常轻松,个人觉得它一直是通过千锤百练出来,我说的不是语法文法,而是Ultradns在基础架构设计上走过路,以及对DNS深刻的认识,我相信这其中肯定有不少汗水或者泪水。意思很简单,IP Anycast最佳的应用环境就是DNS,一般DNS查询走的都是UDP协议,IP Anycast 结合 BGP的为DNS全球冗余及加速提供天然的条件。

UltraDNS在五大洲已经搭建14个公共节点,虽然在国外鼎鼎大名,但在中国没有什么名气。我想也是跟UltraDNS的基础架构有一定的关系,这种架构第一要求拥有自己的公网IP地址段。第二要跟该国家的主要运营商有BGP广播。目前国内运营部不像国外那么好商谈,坐地起价,漫天要价,而且BGP震荡且不提供任何SLA保证。呵呵,Ultradns也正是因为这种架构“枷锁”在中国难以到处开花,上次听说Ultradns已经在香港开了一个Node,提供一些国外网站在华业务的支持。

呵呵,乱七八糟说了一通UltraDNS,其实IP Anycast还可以应用在企业内部作为DNS高速及冗余可靠方案,回头有时间再写点。


简单的UltraDNS结构图,没有搜到详细些,但也有想象空间,呵呵,版权所有@NeuStart

参考资料:
UltraDNS: http://www.ultradns.com/technology/overview.html

IP Anycast: http://en.wikipedia.org/wiki/Anycast

Tags:
分页: 1/6 第一页 1 2 3 4 5 6 下页 最后页 [ 显示模式: 摘要 | 列表 ]