<?phpxml version="1.0" encoding="utf-8"?>
<rss version="2.0" 
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
>
<channel>
<title>Yeeach.com掘客 / 话题 / 技术-高性能服务器</title>
<link>http://www.yeeach.com/digg</link>
<description>Pligg Web 2.0 Content Management System  votes</description>
<pubDate>Sat, 13 Mar 2010 17:40:25 PST</pubDate>
<language>en</language>
<item>
<title><![CDATA[一种以ID特征为依据的数据分片（Sharding）策略]]></title>
<link>http://www.yeeach.com/digg/story/14322</link>
<comments>http://www.yeeach.com/digg/story/14322</comments>
<pubDate>Sat, 13 Mar 2010 17:40:25 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/14322</guid>
<description><![CDATA[假如您有一个应用程序，随着业务越来越有起色，系统所牵涉到的数据量也就越来越大，此时您要涉及到对系统进行伸缩（Scale）的问题了。一种典型 的扩展方法叫做&amp;ldquo;向上伸缩（Scale Up）&amp;rdquo;，它的意思是通过使用更好的硬件来提高系统的性能参数。而另一种方法则叫做&amp;ldquo;向外伸缩（Scale  Out）&amp;rdquo;，它是指通过增加额外的硬件（如服务器）来达到相同的效果。从&amp;ldquo;硬件成本&amp;rdquo;还是&amp;ldquo;系统极限&amp;rdquo;的角度来说，&amp;ldquo;向外伸缩&amp;rdquo;一般都会优于&amp;ldquo;向上伸 缩&amp;rdquo;，因此大部分上规模的系统都会在一定程度上考虑&amp;ldquo;向外&amp;rdquo;的方式。由于许多系统的瓶颈都处在数据存储上，因此一种叫做&amp;ldquo;数据 分片（Database Sharding）&amp;rdquo;的数据架构方式应运而生，本文便会讨论这种数据架构方式的一种<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[做大的艺术 – 大型网站的架构设计]]></title>
<link>http://www.yeeach.com/digg/story/14172</link>
<comments>http://www.yeeach.com/digg/story/14172</comments>
<pubDate>Mon, 08 Mar 2010 06:26:52 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/14172</guid>
<description><![CDATA[如果说1980年代是PC的时代，1990年代是互联网的时代，那么当下呢？当下是移动互联网的时代。移动互联网的基本要义，一言以蔽之，就是把手 机与网站相连，每部手机在网站上都有独立的个人空间，成为手机的镜像。 一部小小的手机里面，可能同时装载着数十个软件。而且在同一时刻，可能好几个软件在同时运行。另外，还得时刻准备暂停运行，把手机CPU等资源让给 电话通话等优先级别高的工作。还有，时刻需要准备应付网络连接中断，手机电池耗尽等等情况。总之，手机软件的结构设计，是做小的艺术。 移动网站的架构设计，与手机软件的架构设计有着本质的不同。如果说手机软件的特点在于小，那么网站的特点在于大。仅中国就有几亿手机用户，作为服务 于移动业务的网站，它的质量来自于是否能够同时为大规模并发用户提供服务，是否能够处理海量数据，是否能够在需要扩大网站吞吐量的时候，只需要增加机器， 而不需要对网站架构做大手术。这是做大的艺术。 提到做大规模网站，大家一定会想到云计算，想到Google File System，Chubby，  BigTable，MapReduce等等。<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[The Reddit problem: Learning from mistakes]]></title>
<link>http://www.yeeach.com/digg/story/14025</link>
<comments>http://www.yeeach.com/digg/story/14025</comments>
<pubDate>Wed, 03 Mar 2010 07:02:28 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/14025</guid>
<description><![CDATA[Reddit  has a very interesting post about what not to do when trying to build a  scalable system. While the error is tragic, I think its an excellent  design mistakes to learn from.  Though the post lacked detailed technical report, we might  be able to recreate what happened. They mentioned they are using <br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Database Capabilities in a High-Volume Environment]]></title>
<link>http://www.yeeach.com/digg/story/13963</link>
<comments>http://www.yeeach.com/digg/story/13963</comments>
<pubDate>Sun, 28 Feb 2010 05:27:24 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13963</guid>
<description><![CDATA[Traditionally, the term &amp;quot;database&amp;quot; as used by technical  professionals implied &amp;quot;relational, row-based, transactional.&amp;quot; These  implied extra characteristics do us a disservice when speaking of  databases in a high-volume environment where there must be several types  of databases deployed, some of which aren't relational, some of which  aren't row-based, and most of which aren't transactional. What is a Database? When we initially started our <br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[up and running with cassandra]]></title>
<link>http://www.yeeach.com/digg/story/13962</link>
<comments>http://www.yeeach.com/digg/story/13962</comments>
<pubDate>Sun, 28 Feb 2010 05:27:24 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13962</guid>
<description><![CDATA[Cassandra is  a hybrid non-relational database in the same class as Google's  BigTable. It is more featureful than a key/value store like Dynomite, but  supports fewer query types than a document store like MongoDB.  Cassandra was started by Facebook and later transferred to the  open-source community. It is an ideal runtime database for web-sca<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Cassandra @ Twitter: An Interview with Ryan King]]></title>
<link>http://www.yeeach.com/digg/story/13961</link>
<comments>http://www.yeeach.com/digg/story/13961</comments>
<pubDate>Sun, 28 Feb 2010 05:27:24 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13961</guid>
<description><![CDATA[There  have been confirmed rumors[1]  about Twitter planning to use Cassandra for a long time. But except the  mentioned post, I couldn&amp;rsquo;t find any other references.   Twitter is fun by itself and we all know that NoSQL  projects love Twitter. So, imagine how excited I was when after  posting <br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[HBase vs Cassandra: why we moved]]></title>
<link>http://www.yeeach.com/digg/story/13862</link>
<comments>http://www.yeeach.com/digg/story/13862</comments>
<pubDate>Sat, 27 Feb 2010 08:35:19 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13862</guid>
<description><![CDATA[ 	My team is currently working on a  brand new product &amp;ndash; the forthcoming MMO www.FightMyMonster.com. This  has given us the luxury of building against a NOSQL database, which  means we can put the horrors of MySQL sharding and expensive scalability  behind us. Recently a few people have been asking why we seem to have  changed our preference from HBase to Cassandra. I can confirm the change  is true and that we have in fact almost completed <br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Scalable Datastores]]></title>
<link>http://www.yeeach.com/digg/story/13832</link>
<comments>http://www.yeeach.com/digg/story/13832</comments>
<pubDate>Sat, 27 Feb 2010 08:35:19 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13832</guid>
<description><![CDATA[In recent years, a number of interesting data storage systems have been developed with excellent horizontal scaling properties: BigTable, CouchDB, Dynamo, and many others.&amp;nbsp; Horizontal scaling allows dozens or hundreds of machines to operate as a single database system, performance improving approximatel<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Redis at Superfeedr]]></title>
<link>http://www.yeeach.com/digg/story/13739</link>
<comments>http://www.yeeach.com/digg/story/13739</comments>
<pubDate>Mon, 22 Feb 2010 02:28:43 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13739</guid>
<description><![CDATA[A lot of the problems we had to tackle in the last months were  directly related to the data stores we used, as well as the schema  of the objects we stored. We&amp;rsquo;ve been using MySQL and Memcached from day one, because it&amp;rsquo;s  always good when you have 50 different problems to tackle to use  tools that you know (read <br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Understanding the Real-Time Web for Web Developers]]></title>
<link>http://www.yeeach.com/digg/story/13698</link>
<comments>http://www.yeeach.com/digg/story/13698</comments>
<pubDate>Mon, 22 Feb 2010 02:28:43 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13698</guid>
<description><![CDATA[The term &amp;ldquo;The real-time web&amp;rdquo; has become popular as a way to  describe burgeoning trends and technologies related to consuming web  content as soon as it is created. However like popular buzz phrases such  as &amp;ldquo;services oriented architecture&amp;rdquo; and &amp;ldquo;web 2.0&amp;rdquo; which came before it,  there is often difficulty in understanding where the technical details  end and where the hype begins. Given that this trend is a fundamental  shift in how many users interact with t<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[SourceForge.net chooses Python, TurboGears and MongoDB to Redesign their Web Site]]></title>
<link>http://www.yeeach.com/digg/story/13697</link>
<comments>http://www.yeeach.com/digg/story/13697</comments>
<pubDate>Mon, 22 Feb 2010 02:28:43 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13697</guid>
<description><![CDATA[Rick Capeland, SourceForge.net gave a presentation on, &amp;ldquo;How  Python, TurboGears, and MongoDB are Transforming SourceForge.net&amp;rdquo;, at  PyCon 2010 today in Atlanta, Georgia. Copeland discussed SourceForge&amp;rsquo;s  desire to migrate off PHP code and start re-factoring their customer  facing site, using a with the titled recipe of Python, TurboGears, and  MongoDB. The PHP code was chosen by SourceForge to be the best  technology at the time back in 1998, and SourceForge believes that a<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Running Hadoop on Windows]]></title>
<link>http://www.yeeach.com/digg/story/13677</link>
<comments>http://www.yeeach.com/digg/story/13677</comments>
<pubDate>Mon, 22 Feb 2010 02:28:43 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13677</guid>
<description><![CDATA[What is Hadoop? Hadoop is a an open source Apache project written in Java and  designed to provide users with two things: a distributed file system  (HDFS) and a method for distributed computation. It&amp;rsquo;s based on Google&amp;rsquo;s  published Google File System  and MapReduce  concept which discuss how to build a framework capable of executing  intensive computations across tons of computers. Something that might,  you know, be helpful in b<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Search Engine Time Machine]]></title>
<link>http://www.yeeach.com/digg/story/13646</link>
<comments>http://www.yeeach.com/digg/story/13646</comments>
<pubDate>Sat, 20 Feb 2010 03:43:04 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13646</guid>
<description><![CDATA[Building a highly available product requires some creative  thinking. High availability is measured in two aspects when talking  about distributed products. The first is the ability to survive partial  cluster failure gracefully (and scale to new nodes when added), and the  second is handling complete cluster failure or shutdown (and bringing it  back up again). The following covers how a distributed system can handle these two  problems, especially in cloud environments, and what Ela<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Brewers CAP Theorem on distributed systems]]></title>
<link>http://www.yeeach.com/digg/story/13572</link>
<comments>http://www.yeeach.com/digg/story/13572</comments>
<pubDate>Mon, 15 Feb 2010 09:38:35 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13572</guid>
<description><![CDATA[Large distributed systems run into a problem which smaller  systems don&amp;rsquo;t usually have to worry about. &amp;ldquo;<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[我朝Internet南北不畅通的解决方案（老旧方案）]]></title>
<link>http://www.yeeach.com/digg/story/13273</link>
<comments>http://www.yeeach.com/digg/story/13273</comments>
<pubDate>Thu, 04 Feb 2010 07:58:09 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13273</guid>
<description><![CDATA[这个问题曾经花过不少力气，但也没有很理想解决。  正好建硕也要解决类似问题，我就把过去的土法给权当抛砖引玉写出来。4年前的东西了，想必现在会有更好的办法。  过去的方案：    1. DNS 采用geo load balance.&amp;nbsp; 关键点在于获得南北的ip分布，并建立规则表。 很多公司应该有这个表   2.  所有的web前端都为 reverse proxy，当时采用SQUID，并设立了2级的级联cache    3. 数据库，  application server 均中心化位于一个 data center.    4.  租用至少一个具有BGP路由的双线机房的主机，这台主机上跑着cache server (SQUID)    5.  配制web前端的cache规则，以实现最好的cache效果   application设计的时候考虑有多极cache服务器的存 在，web app采用下面的原则：   1. 静态、不常变动内容永远采用最大的max-age,  更新的<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[关于两个机房的讨论]]></title>
<link>http://www.yeeach.com/digg/story/13272</link>
<comments>http://www.yeeach.com/digg/story/13272</comments>
<pubDate>Thu, 04 Feb 2010 07:58:09 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13272</guid>
<description><![CDATA[如何最大限度的提升中国的网站速度，今天发信给我信任的朋友们，老冒回复如下：我朝Internet南北不畅通的解决方案（老旧 方案）（需要翻墙。可以在Google  Reader里面订阅http://robertmao.com/feeds/latest/访问）。很多要点老冒几乎都提到了，我在此列出我的一些问题 和思考，共有用样需求的各位讨论。  1. MySQL跨越广域网的复制(Replication of MySQL)是否稳定可靠  除了老冒写到的基于页面或者部分页面的缓存方案(Squid as  cache)，还有一种更加冒险，但是实时性更好的方案就是在异地的数据中心建立MySQL的slave节点，进行主数据中心和附属数据中心的 Master-slave replication.  按说MySQL复制本身已经是一个非常健壮和成熟的解决方案，但是跨越广域网的效果如何，尚待验证。我觉得，只要延迟平均在秒级别，偶<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[对 Web 应用程序进行性能调优]]></title>
<link>http://www.yeeach.com/digg/story/13228</link>
<comments>http://www.yeeach.com/digg/story/13228</comments>
<pubDate>Sat, 30 Jan 2010 23:57:16 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13228</guid>
<description><![CDATA[动态的 Web  应用程序能够存储大量信息，让用户能够通过熟悉的界面立即访问这些信息。但是，随着应用程序越来越受欢迎，可能会发现对请求的响应速度没有以前那么快了。 开发人员应该了解 Web 应用程序处理 Web 请求的方式，知道在 Web 应用程序开发中可以做什么，不能做什么，这有助于减少日后的麻烦。 			静态的 Web 请求（比如图 1 所示的请求）很容易理解。客户机连接服务器（通常通过 TCP 端口 80），使用 HTTP  协议发出一个简单的请求。 			 				图 1. 客户机通过 HTTP 请求静态的文件 				 			 			<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[squid的缓存决定因素和刷新策略]]></title>
<link>http://www.yeeach.com/digg/story/13221</link>
<comments>http://www.yeeach.com/digg/story/13221</comments>
<pubDate>Sat, 30 Jan 2010 23:57:16 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13221</guid>
<description><![CDATA[1） 是否缓存  squid本质是缓存url,对于一个url能否缓存，取决与两个因素，一个是配置，一个response头，缺一不可    1.1） 配置  比如有可能存在下面的配置就对url中带cgi-bin或者?的不缓存  acl QUERY urlpath_regex cgi-bin ?  cache deny QUERY    squid3.0默认没有上面的配置，之前的版本是有的    1.2）response头  对于静态页面来说，服务器会自动加上Last-Modified头，这使得squid可以缓存，  但不确定缓存时间，所以需要使用refresh-pattern指令来确定    对于动态内容来说，原始服务器不会添加影响缓存的头，所以squid对动态内容不做缓存，其实  squid是无法识别动态或者静态，完全是通过response头来决定缓存与否，所以要想缓存动态内容  必须通<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Creating high performance dynamic web sites with the Varnish HTTP accelerator]]></title>
<link>http://www.yeeach.com/digg/story/13219</link>
<comments>http://www.yeeach.com/digg/story/13219</comments>
<pubDate>Sat, 30 Jan 2010 23:57:16 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13219</guid>
<description><![CDATA[This article offers an overview of the Varnish HTTP  accelerator: what it is, briefly how it works and how it can benefit  you, the webmaster. The first half  of this article introduces the reader to basic web caching concepts.   This text is not Varnish-specific and is best skipped if you are already  familiar with caching as it is used on the web.  The latter half of  this article delves into the<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Caching Tutorial  for Web Authors and Webmasters]]></title>
<link>http://www.yeeach.com/digg/story/13205</link>
<comments>http://www.yeeach.com/digg/story/13205</comments>
<pubDate>Sat, 30 Jan 2010 04:28:02 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13205</guid>
<description><![CDATA[This is an informational document. Although technical in nature, it attempts to make the concepts involved understandable and applicable in real-world situations. Because of this, some aspects of  the material are simplified or omitted, for the sake of clarity. If you are interested in the minutia of the subject, please explore the References and Further  Information at the end.<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[面向站长和网站管理员的Web缓存加速指南]]></title>
<link>http://www.yeeach.com/digg/story/13206</link>
<comments>http://www.yeeach.com/digg/story/13206</comments>
<pubDate>Sat, 30 Jan 2010 04:28:02 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13206</guid>
<description><![CDATA[                                                                                      原文（英文）地址： http://www.mnot.net/cache_docs/&amp;nbsp;  版权声明：署 名-非商业性使用-禁止演绎 2.0这是一篇知识性的文档，主要目的是为了让Web缓存相关概念更容易被开发者理解并应用 于实际的应用环境中。为了简要起见，某些实现方面的细节被简化或省略了。如果你更关心细节实现则完全不必耐心看完本文，后面参考文档和更多深入阅读部分可 能是你更需要的内容。什么是Web缓存，为什么要使用它？缓存的类型：浏 览器缓存；代理服务器缓存；<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[人人网UGC海量存储系统Nuclear介绍 – 原理展望篇]]></title>
<link>http://www.yeeach.com/digg/story/13203</link>
<comments>http://www.yeeach.com/digg/story/13203</comments>
<pubDate>Fri, 29 Jan 2010 18:37:09 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13203</guid>
<description><![CDATA[书接上文。 原理篇 Nuclear系统构建于java之上，NIO组件使用Netty， 数据序列化使用google的<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Installing HAProxy and Stunnel (load balance http and https)]]></title>
<link>http://www.yeeach.com/digg/story/13066</link>
<comments>http://www.yeeach.com/digg/story/13066</comments>
<pubDate>Sun, 24 Jan 2010 21:56:45 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13066</guid>
<description><![CDATA[ 				HAProxy is wonderful, it&amp;rsquo;s way faster than nginx and if  you want to it can provide high availability too. I&amp;rsquo;m just using it as a  load balancer though&amp;hellip; and the catch is, HAProxy doesn&amp;rsquo;t do SSL, so for  that to work port 443 will be handled by stunnel in front of HAProxy&amp;hellip;  upside, my Apache2 servers never have to care about SSL, stunnel does  that for us. This guide was written for Ubuntu 9.10 Karmic Koala. Minor changes  may need to be made if you<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[SSI, Memcached and Nginx (plus Varnish, ESI and static generation)]]></title>
<link>http://www.yeeach.com/digg/story/13062</link>
<comments>http://www.yeeach.com/digg/story/13062</comments>
<pubDate>Sun, 24 Jan 2010 21:56:45 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13062</guid>
<description><![CDATA[ Contents The SetupInstall MemcahcedNginxPython<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Edge Side Includes explained simple]]></title>
<link>http://www.yeeach.com/digg/story/13061</link>
<comments>http://www.yeeach.com/digg/story/13061</comments>
<pubDate>Sun, 24 Jan 2010 21:56:45 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13061</guid>
<description><![CDATA[ Edge Side Includes, or ESI,  are a technology which has been around for many years. Lately I've been  working a lot with component  based web development where ESI have been used and seeing the  benefits ESI have on the server side, have made me wonder why ESI aren't  more used. I do also find a lot of developers, specially web  developers, go kind of whoooot?!?<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[人人网使用的开源软件列表]]></title>
<link>http://www.yeeach.com/digg/story/13025</link>
<comments>http://www.yeeach.com/digg/story/13025</comments>
<pubDate>Sat, 23 Jan 2010 18:17:10 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13025</guid>
<description><![CDATA[MySQL 关系型数据库存储系统，我们的DBA团队很强大，每人管理上百台MySQL服务器，其他就不多说了，网上资料太多了 Tokyo Cabinet 一个key-value的存储引擎，日本人开发，国内很多公司也开始使用，我们内部很多地方也用它来代替MySQL来做存储，比如我们的搜索结果页的用户 资料，就是用它来做一层MySQL外的冗余存储，目的是加快搜索结果页的显示。在key-value并需要持久存 储的场景下，用它比MySQL更有效，Cabinet本身只是一个存储引擎，没有网络处理能力，你可以用它作为自己的某个系统的下层存储引擎，更好的是搭 配Tokyo Tyrant使用。 Tokyo Tyrant 一个支持Memcached传输协议的网络接口，由Tokyo Cabinet的作者开发，目的是为Tokyo  Cabinet提供网络接入能力，即Tokyo Tyrant处理网络连接，协议解析，然后调用Tokyo Cabinet的API来完成持久化存储。 ICE 一个跨<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[人人网中间层：求解篇]]></title>
<link>http://www.yeeach.com/digg/story/13024</link>
<comments>http://www.yeeach.com/digg/story/13024</comments>
<pubDate>Sat, 23 Jan 2010 18:17:10 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13024</guid>
<description><![CDATA[书接上文，为了提高性能，在人人网的技术结构中，在数据库和页面之间，有中间层。中间层高性能的基础是用内存代替磁盘。 用内存代替磁盘 数据库系统的最大瓶颈在磁盘IO，大量的小数据请求不是磁盘的强项。人人网中间层服务就是利用了内存代替硬盘的方法来提高整体性能。有了这层服务以 后，以前的数据库关联查询被提前计算并缓存，需要访问时直接获取。 通用的Memcached缓存方案也有些不足，数据不能自己变化，也不能部分变化。于是人人网选择了自己实现缓存的方式。 在自己实现缓存的过程中，管理内存相对容易，通信协议是比较复杂的部分，我们在这方面选择了开源的Ice通信框架 （http://www.zeroc.com）来完成繁琐的工作，至今它都工作的很好。 Ice通信框架在人人网完成了两件事，通信和定位。客户端通过IceGrid组件定位到需要的服务地址，将请求发送到中间层服务，中间层服务将结果返回。 客户端只需要知道一个地址就可以找到所有的服务；同时，众多服务也可以在不同的服务器之间随意迁移。在现在的人人网有超过500个Ice写成的中<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[人人网UGC海量存储系统Nuclear介绍 – 功能应用篇]]></title>
<link>http://www.yeeach.com/digg/story/13005</link>
<comments>http://www.yeeach.com/digg/story/13005</comments>
<pubDate>Sat, 23 Jan 2010 07:39:26 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/13005</guid>
<description><![CDATA[书曰：欲先善其事，必先利其器。人人网作为国内第一大SNS网站，欲存海量UGC数据，必有海量存储系统。Nuclear存储系统在高 性能、高可靠、可扩展的海量数据存储需求下横空出世，待小的给列位看官慢慢道来。 缘由篇 看过《人人网使用的开源软件列表》一文的看官一定知道人人网的关系型数据库使用的是MySQL，Key-Value 存储使用的是Tokyo  Cabinet，话说战斗在第一线的UGC  Team的兄弟们发现，MyS<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[RoadMap to SaaS]]></title>
<link>http://www.yeeach.com/digg/story/12938</link>
<comments>http://www.yeeach.com/digg/story/12938</comments>
<pubDate>Tue, 19 Jan 2010 06:19:44 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12938</guid>
<description><![CDATA[I have observed a pattern from multiple enterprises moving from a traditional web app to a SaaS. Trying to capture this pattern and a number of lessons learned. I use a J2EE Web App architecture to illustrate but the same principles apply to other technology platforms.Stage 1: Some working Web AppAt the very beginning, we have an web application that works well. We analyze the function of the web application and group the implementation classes accordingly<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Zero-Downtime Restarts with HAProxy]]></title>
<link>http://www.yeeach.com/digg/story/12904</link>
<comments>http://www.yeeach.com/digg/story/12904</comments>
<pubDate>Sun, 17 Jan 2010 06:27:56 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12904</guid>
<description><![CDATA[Putting up a maintenance page while you are doing an update and restarting your application servers is good practice, but it definitely hurts the user experience. This, in turn, translates to less frequent releases and frustration for both the developer and the users (release often, release early!). To address this, the Rails community has come up with a couple of approaches to mitigate the problem: Se<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Haproxy/ Varnish/ Cherokee/ Nginx/ Lighttpd]]></title>
<link>http://www.yeeach.com/digg/story/12890</link>
<comments>http://www.yeeach.com/digg/story/12890</comments>
<pubDate>Sun, 17 Jan 2010 03:22:46 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12890</guid>
<description><![CDATA[最近在蹦心的开发环境下交叉对比测试了标题中各个牛X东东的组合架构，最后采用的结构是: Haproxy-&amp;gt;Varnish-&amp;gt;Nginx/Cherokee/Lighttpd  前端使用Haproxy作为BigIP的负载均衡节点，最新版对双机热备、L7交换均有较好支持，友好的web状态监控也很不错；至于为什么不选择Varnish、Nginx或者LVS作为负载均衡，不多说了，具体问题可以和我探讨； 在Haproxy下挂载Varnish作为cache和二级负载分发处理层，考虑因素是比squid更好的可配置性和理论性能数据； 后端的web server优先考虑Nginx，其次进行了部分节点部署Cherokee，一方面为了测试性能，也是为了跟踪该软件后续升级后的表现，从目前我的测试环 境来看，并非有Nginx性能好，因为从Haproxy的优先选择结果来看，更多的会选择Nginx后端分发请求，即使有weight优先的情况下。 Lightpd逐渐的退出我们的系统了，更新的停滞和相对性能无优势的现状使得被我逐渐放弃。 <br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Comparing Nginx and HAProxy for web applications]]></title>
<link>http://www.yeeach.com/digg/story/12889</link>
<comments>http://www.yeeach.com/digg/story/12889</comments>
<pubDate>Sun, 17 Jan 2010 03:22:46 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12889</guid>
<description><![CDATA[ The last few days I have been comparing Nginx&amp;nbsp;to HAProxy, with surprising results. First, a bit of background.&amp;nbsp;For a long time we at Bengler&amp;nbsp;have been using Nginx as the main web server for our projects (1,&amp;nbsp;2), as well as to proxy Rails running under Mongrel. Nginx is a superb little open-source web server with a small footprint, sensible configurati<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Load Balancing &amp; QoS with HAProxy]]></title>
<link>http://www.yeeach.com/digg/story/12888</link>
<comments>http://www.yeeach.com/digg/story/12888</comments>
<pubDate>Sun, 17 Jan 2010 03:22:46 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12888</guid>
<description><![CDATA[ A brand new Rails/Merb app you put together over a weekend, a pack of Mongrels, a reverse proxy (like Nginx), and you're up and running. Well, almost, what about that one request that tends to run forever, often forcing the user to double check their internet co<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[网站性能指标分析]]></title>
<link>http://www.yeeach.com/digg/story/12693</link>
<comments>http://www.yeeach.com/digg/story/12693</comments>
<pubDate>Fri, 08 Jan 2010 05:42:31 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12693</guid>
<description><![CDATA[通用指标 ProcessorTime: 服务器CPU占用 Memory Available Mbyte : 可用内存数 Physicsdisk Time : 物理磁盘读写时间情况 Web服务器指标  Requests Per Second: 平均每秒钟响应次数＝总请求时间 / 秒数 Successful Requests：成功的请求  Failed Requests ：失败的请求  Successful Hits ：成功的点击次数 Failed Hits ：失败的点击次数  Hits Per Second ：每秒点击次数 Successful Hits Per Second ：每秒成功的点击次数  Failed Hits Per Second ：每秒失败的点击次数  数据库服务器性能指标  User Connections ：用户连接数 Number of deadlocks：数据库死锁 <br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[11 Strategies to Rock Your Startup’s Scalability in 2010]]></title>
<link>http://www.yeeach.com/digg/story/12672</link>
<comments>http://www.yeeach.com/digg/story/12672</comments>
<pubDate>Thu, 07 Jan 2010 21:14:03 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12672</guid>
<description><![CDATA[If 2010 is the year that you&amp;rsquo;ve decided to kickoff your startup or if you&amp;rsquo;ve already got something off the ground and are expecting double or triple digit growth, this list is for you.&amp;nbsp; We all want the <br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Oracle and IBM databases: Disk-based vs In-memory]]></title>
<link>http://www.yeeach.com/digg/story/12568</link>
<comments>http://www.yeeach.com/digg/story/12568</comments>
<pubDate>Tue, 05 Jan 2010 05:49:29 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12568</guid>
<description><![CDATA[ 	The case for in-memory databases (IMDB) can be made in three simple points (1) performance - data is kept in RAM so no disk I/O limitations (2) HA with built in fail-over (3) support for relational schema and SQL. Current disk based RDBMS can run out of steam when processing large data. Can these problems be solved by migrating from a disk based RDBMS to an IMDB? Any limitations? To find out, I te<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[Node.js基于Google V8提供了基于事件的I/O处理]]></title>
<link>http://www.yeeach.com/digg/story/12567</link>
<comments>http://www.yeeach.com/digg/story/12567</comments>
<pubDate>Tue, 05 Jan 2010 05:49:29 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12567</guid>
<description><![CDATA[Node.js使得可伸缩的独立Javascript服务端程序可以使用基于事件的I/O，如EventMachine或Python的Twisted，Grand Central Dispatch的分发源和队列（queues）以及很多类似的系统。  这篇演讲讨论了Node.<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[从腾讯QQ升级游戏之“快速加入游戏”功能的实现缺陷看C/S之间如何正确分配相关协作]]></title>
<link>http://www.yeeach.com/digg/story/12360</link>
<comments>http://www.yeeach.com/digg/story/12360</comments>
<pubDate>Wed, 30 Dec 2009 06:12:53 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12360</guid>
<description><![CDATA[笔者在闲暇时，偶尔会登录腾讯QQGame玩玩升级游戏。这确实是一款非常优秀的软件作品，腾讯的开发人员在此展现了极高的技术水准。QQ游戏同时在线用户数都在百万到千万之数量级以上，可以想象其在性能方面所面临的挑战有多高。&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; QQ升级游戏有一个&amp;ldquo;快速加入游戏&amp;rdquo;的功能，方便玩家尽快加入目标牌桌。这本身是个非常人性化的功能，但其实现却存在一个缺陷，当玩家当前所在房间内，同时执行&amp;ldquo;快速加入游戏&amp;rdquo;功能的用户数较多时，常常会出现加入失败的情况。笔者碰到的最糟情形是重复5、6次以上，才最后成功加入，其间获得的用户体验自然是不够好。<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[高性能的网络游戏服务器的设计]]></title>
<link>http://www.yeeach.com/digg/story/12361</link>
<comments>http://www.yeeach.com/digg/story/12361</comments>
<pubDate>Wed, 30 Dec 2009 06:12:53 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12361</guid>
<description><![CDATA[说起高性能的网络游戏，有2个典范，1个是暴雪的WOW，另外一个要数腾讯的QQGame了，因为对于MMPRPG的体系接触不深，几乎属于文盲，没有太多的发言权，而自己又是搞休闲游戏开发的所以本文就主要谈谈QQGame了。前些天通过朋友得到了QQGame的一个系统分析的文档，看完后很是震惊，彻底被QQ的设计所折服了，到底是千万人在线系统经验的拥有者，牛！通过资料了解到QQGame目前有以下让我欣赏的特性：&amp;nbsp;&amp;nbsp; 1. 单机最高容纳35,000人同时在线，对没有看错是这么多，由于它适用了Linux下高性能的网络处理模型ePoll技术，并且一系列高超的优化技术轻松破万人，当然为了稳定性考虑单机保持了2万人的容量，此时的带宽消耗为近30M；&amp;nbsp;&amp;nbsp; 2. 采用共享内存方式高速完成进程间高速通讯；&amp;nbsp;&amp;nbsp; 3. 服务器的扩充方式不是平面的方式，而是裂变式的扩充方式，形成负载均衡阵列树状结构；&amp;nbsp;&amp;nbsp; 4. 所有的游戏服务器不是<br/><br/>1 投票人数 ]]></description>
</item>

<item>
<title><![CDATA[从腾讯QQgame高性能服务器集群架构看“分而治之”与“自治”等分布式架构设计原则]]></title>
<link>http://www.yeeach.com/digg/story/12359</link>
<comments>http://www.yeeach.com/digg/story/12359</comments>
<pubDate>Wed, 30 Dec 2009 06:12:53 PST</pubDate>
<dc:creator></dc:creator>
<category>技术-高性能服务器</category>
<guid>http://www.yeeach.com/digg/story/12359</guid>
<description><![CDATA[腾讯QQGame游戏同时在线的玩家数量极其庞大，为了方便组织玩家组队游戏，腾讯设置了大量游戏室（房间），玩家可以选 择进入属意的房间，并在此房间内找到可以加入的游戏组（牌桌、棋盘等）。玩家选择进入某个房间时，必须确保此房间当前人数未满（通常上限为400），否则 进入步骤将会失败。玩家在登入QQGame后，会从服务器端获取某类游戏下所有房间的当前人数数据，玩家可以据此找到未满的房间以便进入。&amp;nbsp;&amp;nbsp;&amp;nbsp; 如上篇所述的原因，如果待进入房间的人数接近上限时，玩家的进入请求可能失败，这是因为服务器在收到此进入请求之前可能有若干其他玩家也请求进入这个房间，造成房间人数达到上限。这一问题是无法通过上篇所述调整协作分配的方法来解决的，这是因为：要进入的房间是由玩家来指定的，无法在服务器端完成此项工作，游戏软件必须将服务<br/><br/>1 投票人数 ]]></description>
</item>

</channel>
</rss>
