• 服务接口

• 接口实现

• 发布服务

In order to generate functional remote references, Java RMI servers must be able to supply a fully qualified hostname or IP address that is resolvable from all Java RMI clients (an example of a fully qualified hostname is foo.bar.com). If a Java RMI program provides a remote callback operation, then that program serves a Java RMI object and consequently, must be able to determine a resolvable hostname to use as its server hostname in the remote references it passes to Java RMI clients. VMs that make calls to applets that serve remote objects may throwUnknownHostExceptions because the applet has failed to provide a usable server hostname.

If your Java RMI application throws an UnknownHostException, you can look at the resulting stack trace to see if the hostname that the client is using to contact its remote server is incorrect or not fully qualified.【 If necessary, you can set the java.rmi.server.hostname property on the server to the correct IP address or hostname of the server machine and Java RMI will use this property's value to generate remote references to the server.】

转自：http://blog.csdn.net/jinhill/article/details/3961881

综上，URL还是不适合太长，不是不得已，尽量不要通过GET方式提交大量参数，可以考虑用POST方式（大约在2M左右，应该是和服务器及设定有关）。另外这么长的URL在访问和收藏（有文章提到有些浏览器在收藏超长地址时也是会出现问题）时也是相当不友好的。当然，之前数据库字段设置时还是作为255bytes处理，现在可能要考虑扩充一下了。

参考：

1. What is the maximum length of a URL?
2. What is the limit on QueryString / GET / URL parameters?

什么是A/B测试?

A / B测试的核心就是：确定两个元素或版本（A和B）哪个版本更好，你需要同时实验两个版本。最后，选择最好的版本使用。

网络上的A / B测试，即你设计的页面有两个版本（A和B），A为现行的设计（称为控制） ， B是新的设计。比较这两个版本之间你所关心的数据（转化率，业绩，跳出率等） 。最后，您选择效果最好的版本。

测试哪些东西?

你要选择什么去测试取决于你的目标。例如，如果你的目标是增加顾客数量，那么您可能测试下列内容：注册表单数量，字段类型要求，隐私政策等。在这种情况下A / B测试的目标是要弄清楚什么阻止了游客注册。需要填写的表单的数量？用户的隐私？还是该网站做了让游客不信任的事情？所有这些问题都可以通过一个个A/B 测试获得答案。

每一个A / B测试内容都是独一无二的，单通常测试一下这些内容：

• 行动按钮的措辞，大小，颜色和位置，
• 标题或产品说明，
• 表单的数量和字段类型，
• 网站的布局和风格，
• 产品定价和促销活动，
• 着陆和产品页面上的图片，
• 页面上文字的长度（少Vs多）。

一旦你决定要测试什么，下一步当然是要选择一个合适的测试工具。如果你想要一个基础的免费工具，可以使用Google Website Optimizer。如果你想要功能更加强大的工具，可以使用Visual Website Optimizer  。其他的一些选择都是可以的，建立试验在所有工具中都很相似，所以我们只需讨论一种即可。

你可以通过两种方法建立A / B测试：

• 在页面测试加载前替换元素
  如果你测试的是页面上的单个元素，如注册按钮，然后需要在测试工具中设置按钮。当测试时，在A / B工具将在页面给用户前随机替换按钮。
• 重定向到另一页面
  如果你想通过A / B测试整个页面，比如说，一个绿色的主题和一个红色主题，那么你就需要创建和上传新的页面。例如，如果您的主页是 http://www.example.com/index.html，那么你需要创建另外一个页面 http://www.example.com/index1.html。当测试运行时，您的测试工具将一部分访问者重定向到第二个网址。

一旦您使用了上面的两种变换方法，下一步是建立您的转换目标。通常，你会得到一个JavaScript代码，您可以复制并粘贴到一个需要游客到达的目标网页。例如，如果您有一个电子商务网站，你正在测试的“立即购买“按钮的颜色，然后您的转换目标将是购买成功后的“谢谢您“页面。

在转换事件发生的同时，在A / B测试工具，记录了哪种页面显示给了访问者。经过足够数量的游客，您可以确定哪个页面带来了最多的转化！建立和运行的A / B测试，其实很简单。

该做什么和不该做什么

虽然A / B测试是超级简单的概念，但是请记住，以下这些都只是我自己的经验。

注意事项

• 不要分开你的测试情况。始终两个版本同时进行测试。如果您第一星期测试第一版本，第二星期测试第二个版本，你就错了。有可能B版本带来的流量更糟糕，但是带来了更好的业绩，因为两个版本之间的流量始终存在不一样。
• 不要结束得太早。有一个概念叫做“统计信心“ ，无论你的测试结果明显的。如果你只有少数转换或游客，它都无法确定最终的结果。大多数A / B测试工具都有报告统计，但如果你是手动测试，你可以使用 在线计算器。
• 不要让常客惊讶。如果你正在测试网站的一部分。包括新访客和常客，不要使他们觉得震惊。尤其不要因为哪些可能不会最终实施变化。
• 不要让你的直觉推翻了测试结果。在A / B测试的结果往往是令人惊讶的或直观的。在一个绿色为主题的网站，一个明显的红色按钮有可能成为赢家。即使红色按钮不容易吸引注意。您要测试的目标是一个更好的转换率，而不是美学，所以在得到测试借过钱不要拒绝任何尝试。

需要做的

• 知道运行测试多久。结束太早，可能会使你花了时间但是没有得到有意义的结果。结束太晚也不好，因为效果不佳的页面可能影响你的转化和业绩。使用一个计算器，来确定测试多久以后来结束它。
• 将相同的页面呈献给同一个访客。您的工具应该有一个记忆访问者已经看到的页面的功能。这样可以防止向同一用户显示一不同的价格或不同的促销优惠。
• 让您的A / B测试在整个网站保持一致。如果你正在测试的登录按钮在多个地点出现，然后一个访问者应在所有的地方看到同样的变化。在页面1显示一个样子，在页面2显示两外一个样子，会使试验结果被干扰。
• 做很多的A / B测试。让我们面对现实吧：你的第一个A / B测试可能会无效。但是不要绝望。一个A / B测试只能有三个结果：没有结果，不好的结果和好的结果。优化转换率的关键是要做大量的A / B测试，把所有的好的结果拼接起来，最终推动业绩。

经典A/B测试案例研究

这里有一些如何进行A/B测试的案例研究。

Writing Decisions: Headline Tests on the Highrise Sign-Up Page 37Signals测试他们的价格页面的标题。最终发现， “30-Day Free Trial on All Accounts “比原来的“Start a Highrise Account. “多产生30 ％以上的订单。

“You Should Follow Me on Twitter Here” (Dustin Curtis) 这是一个用来测试召唤用户在Twitter上关注自己的试验。. Dustin 发现提示文字是“You should follow me on Twitter here” 的效果是“I’m on Twitter.” 173%

Human Photos Double Conversion Rates 从两个不同的A / B测试将在网站上增加转换率的人的照片：一个令人令人惊讶的结论，A/B测试两张图片，将真人照片放在网站上会获得一倍的转化。研究说明，我们潜意识被照片吸引了。

Google Website Optimizer Case Study: Daily Burn, 20%+ Improvement (Tim Ferriss) 一个将用户选择减少的变化使转化提高了20%，最终的版本在细节和文字上更易吸引目光。

Two Magical Words Increased Conversion Rate by 28% “It’s free” 这个单词增加了注册按钮点击次数的28%, 测试结果表明，在行动召唤上一些很小的变化会带来令人惊讶的结果。

Changing the Sign-Up Button from Green to Red 依靠A / B测试， CareLogger把注册按钮从绿色修改为红色增加了34％转换率！

Single page vs. multi-step checkout 如果你有一个在线商店，很常见的就是支付流程。这个A / B测试发现，多个支付流程比单个支付流程完成的销售更好。

“Mad Libs” style form increases conversion 25-40% 打败传统的智慧，此A / B测试发现一段风格形式输入字段比传统形式的布局更好。

Complete redesign of product page increased sales by 20% 一个软件产品的公司重新设计他们的产品页给它一个现代的外观和增加信任模块。最终结果：他们成功地增加20 ％的总销售额。本案例研究证明了设计对销售的影响。

Marketing Experiments response capture case study – triple digit increase in conversions 通过优化邮件地址获取提高了258 ％。重点是消除所有的干扰，并要求游客只需提供电子邮件地址。使用亚马逊礼品卡让他/她的完成个人资料。

A/B测试工具

有许多侧重点，价位和功能不同的A / B测试工具，这里是一些：

• Google Website Optimizer
  搜索巨头提供的免费A/B测试工具。一个很好的入门级工具，但是没有一些先进的功能。
• A/Bingo and Vanity
  基于Ruby on Rails开发的服务器组件。需要编程和代码集成。
• Visual Website Optimizer
  一个易于使用的A / B测试工具，包含一些先进的功能，如所见即所得的编辑器，单击地图，访问者分割和标签等。
• Unbounce and Performable
  集成着陆页设计的A / B测试工具。
• Vertster, SiteSpect, Webtrends Optimize and Omniture’s Test&Target
  企业级测试工具。

一些深入研究的A/B测试资料

如果你已经读到这里，那么A / B测试大概已经激起你的兴趣。在这里，有一些非常好的A/B测试资源。

寻找你下一个A/B测试的灵感

• Which Test Won?
  一个猜测那种情况会最终胜利的游戏。
• 101 A/B Testing Tips
  大量的A/B测试技巧和方法。
• ABtests.com
  一个可以分享和阅读A/B测试结果的地方。
• A/B Ideafox
  搜索引擎的A / B和多变量的案例研究。

一些介绍性文章

• Effective A/B Testing
  By Ben Tilly.
• Practical Guide to Controlled Experiments on the Web (PDF)
  From Microsoft Research.
• Introduction to A/B Testing
  From the 20bits blog

A/B测试中的数学

• Statistics for A/B Testing
  From the 20bits blog.
• How Not to Do A/B Testing
• What You Should Know About the Mathematics of A/B Testing
  From my own blog.
• Easy Statistics for AdWords A/B Testing, and Hamsters
• Statistical Significance and Other A/B Test Pitfalls

原文地址：http://www.smashingmagazine.com/2010/06/24/the-ultimate-guide-to-a-b-testing/
转载自：http://ucdchina.com/snap/7203

内容如下：

错误一：错误的需求调研阶段，导致很多项目永远无法结束!

在软件行业，在界面设计没有正式展现给客户之前，所有的工作都处于需求调研阶段。其实建筑行业已经给我们做好了先例：客户买房子之前是先要看看样板房和模型的，什么都看不到，这房子你敢买么?除非你不是自己住！而在我们所学的软件工程概念模型中，这是三个阶段：需求调研、需求分析、概要设计。

在客户把他们想要管理的业务模块以及与之相关的业务数据、流程、表单交付你的时候，你千万不要把这个阶段定性为需要调研结束，写出《需要规格说明书》就可以了。大量的实践证明，在概要设计阶段所衍生出来的需求工作量是之前的5~10倍，甚至更多，因为这要看设计人员的业务沟通能力和建模水平。

有实施经验比较丰富的项目管理人员总结说，在中国实施软件项目，必须以咨询方式展开：要推出自己的方案，而不能完全按照客户来提需求作项目。这是一种很好的解决思路，但无法解决所有实施项目的难题。这种解决方案的前提，要么项目实施者有成熟的业务模型，要么有成熟的产品(包含了成熟的业务模型)，否则是不可能做到的。但如果没有3~5年在同一行业，同一领域的实施经验和理论总结，没有哪家IT企业能达到这样的前提要求。

其实得出这样结论的深层原因，是因为国内多数企业管理思想不成熟，更谈不上完善的业务模型，所以客户的思维一定程度是发散的，还未形成系统。甚至还有些客户的领导，脑子中有很多新鲜的点子，他都有可能想在企业信息化的实施过程中加进来，这对把控项目范围和项目实施效果来说，都可能是灾难的开始。

所以，要做好实施项目，实施者必须有很好的业务建模能力，快速的给客户展示合理的软件原型软件Demo。

请记住：软件实施项目，一定要给用户看到样板房软件Demo，才算需求调研结束!

错误二：IT技术人员不需要掌握项目管理

有这种看法的人不在少数。根据观察，之所以形成这种看法，一是对项目的真正概念不清晰，二是对管理的概念神话了，把管理理解成了高深莫测，非一般人能做的事情。首先有必要普及一下项目的概念。

对项目有很多人下过定义，项目管理圣经PMBOK第三版(2004版)的定义是：为创造某个独特的产品或服务，或完成某独特的任务所做的临时性努力。围绕这句话PMBOK做了详细的解释和举例说明，很严谨，想了解的请学习PMBOK。因为都是翻译过来的定义，翻译得过于术语化很容易把人绕进去，在国内不排除已经拿到PMP认证证书的专业人士还搞不清楚项目究竟是什么。笔者在这里只想用汉语最通俗的语言来说明什么是项目和项目管理。

项目，就是在限定的时间要人完成的事。记住三个关键字即可把握：人、时、事。

项目管理就是参与者用什么(知识、技能、工具、方法)来圆满地干好这件事。

明白了这些，你就会明白从日常生活的吃喝拉撒到国家管理，处处都是项目，处处都需要项目管理，也就能明白每个人都需要项目管理，也就能理解学会了项目管理将会多么受益无穷，娴熟运用项目管理思维将无往不胜!

但需要提醒大家一点，现在的PMBOK是把传统制造行业、建筑行业、IT行业等多个行业领域的项目管理知识糅合到了一起，大而全，但针对性不够好，所以很多人觉得PMBOK理论化太强，学完了觉得很多东西没用。现在国际知名的另外一套项目管理认证，IPMP是按照工作岗位能力进行了分级，也没有针对行业进行分解。所以，无论拿到PMP或者IPMP，很多人都会有同样的困惑。据了解，PMI已经准备做这样的改进，这是一个很好的消息。

错误三：忘记项目目标

你看到这个题目什么感觉?很多人会觉得这样的错误怎么会发生?几乎没有人会认为自己犯这个错误！忘记项目目标有两种情形：一是从开始接手项目就没弄清楚项目的目标是什么;二是虽然清楚项目的目标是什么，但却干着跟完成项目目标无关、甚至有害的事。

时刻铭记项目目标是项目管理很重要的一个思维，项目所有的活动都围绕这个展开。可是随着项目的逐步开展，尤其是复杂项目：人多、事多、周期长，很多项目经理会逐渐因为个人喜好而忘记了项目的大目标，比较典型的有：技术出身的项目经理会沉迷于技术细节，大量时间花在学习新技术或者一头闷在解决技术难题上;脾气火爆的项目经理会因为很多不值当的事情大发脾气，把团队搞得乌烟瘴气;小心眼、爱面子的项目经理会因为某个组员无意的顶撞而怀恨在心，从此总给其穿小鞋，搞得团队拉帮结派，毫不团结;还有更糟糕的，比如爱玩游戏的，爱喝小酒的等等。所有这些，无论原因是自身不成熟，还是管理经验、管理能力不足，结果都一样，那就是项目出问题，甚至失败。

项目经理最重要的一项任务就是跟踪与控制，时刻把握项目方向，保证项目计划得以顺利执行，偏差控制在可控风险范围内。但项目总是有太多意外因素，尤其是周期长的项目，人们常用夜长梦多来形容风险会随时间的延长而增加，所以项目经理一定时刻都要保持头脑清醒，对项目无益的事情不做，对项目有风险的事情更不能做。

任何项目在开展过程中都会不断面对机会和诱惑，项目经理一定要能明确项目大目标，才能清晰地识别哪些是使项目成功的机会，哪些是会给项目带来风险的诱惑，才会少走弯路，早日成功。项目管理者联盟，项目管理问题。

人是需要不断被提醒的，这由人性决定。智慧的人能够不断的反省从而自我提醒，愚笨的人会被挫折、外界的警示不断提醒，这就形成了成功与失败的差异。

错误四：计划不能变

怎样才能保证项目成功?计划，计划，再计划，这是项目管理的最佳实践！所以，做项目管理的一般都知道如何编制项目计划，并且很多人能熟练的使用Project工具，知道80小时或者40小时法则、WBS和关键路径的概念。每个项目经理都会记住计划一旦形成，就严格按照计划去执行，而不受某个人、某件事的影响这个原则，也明白这样做不仅能够减少大量资源的浪费，产品的质量也能得到保障。所以，很多项目经理排斥，甚至拒绝改变计划。坚持原则，这貌似没什么错，但真的这样么?

要弄清楚一件事是否有必要做，首先就得弄清楚两个问题：一、这件事为什么要做?二、做了有什么好处?

那我们首先问一下编制计划的目的是什么?我们知道计划是项目管理的最佳实践，计划是保证项目成功的一种手段和方法，做这件事只有一个目的，那就是为了保证项目成功，但前提是，这份计划是周密的、可行的。严格执行一份周密可行的项目计划才能保证项目成功。很多项目经理记住了上面的严格执行原则，但忘记了这个大前提。

第二个问题，计划有什么好处?项目管理的计划方法，把项目活动、持续时间、所需资源有机地结合在一起，并且有严格的先后次序、里程碑和关键路径，可以清晰地提醒项目所有成员在什么时间，做什么事情，保证每个项目任务都得以执行;通过对计划的执行跟踪，项目经理可以清晰地了解项目进展情况和偏差情况，评估并及时有效的控制项目风险，从而保证项目的成功。

明白了这两点，我们再来看IT项目。对多数IT项目，尤其是软件实施项目，启动时都存在范围不够明晰，需求不确定的情况。只有到软件Demo产生，才可能需求清晰，范围确定，这些情况就决定了IT项目计划需要根据项目的实际情况及时进行修正。如何压缩范围确定的时间，早日制定出周密可行的计划，是软件项目的一个重要课题。

制定一份周密可行的计划是项目经理优秀能力的体现，尤其是WBS的制定，对复杂项目有很大难度。在谈2008奥运项目的管理体会时，项目专家曹蕾就提到奥运会项目最难的一点就是WBS的制定(参见PMU网站对2008奥运项目的访谈)。要保证项目的成功，就要保证项目的每个活动都能得以顺利执行。所以，在项目情况发生变化，在原有的计划基础上有需求变更时，就要把新的任务补充到计划中，修正计划，确保WBS的完整，确保计划周密可行，之后的工作才是严格执行。

顺便提一句，有些项目经理会走另外一个极端：因为需求不确定，所以不制定项目计划。这同样是对计划的错误理解。即使计划不够周密，但它可以提醒我们项目的大目标是什么，保证项目团队所采取的行动不偏离大方向。任何一项大的项目，都可以拆分成很多小项目，WBS的渐进明细，也是项目必须完成的任务之一，所有任务的持续时间都是要估算的，即使不够准确，至少可以作为经验累积，为今后的准确估算做了准备。因此，项目的任何阶段都一定要有计划。

错误五：项目一定要盈利

项目一定要盈利，这句话被无数IT项目经理奉为真理，也就注定了要创造很多悲剧！为了达到这个目的，很多IT项目经理甚至都在悉心研究厚黑学，学习用什么办法把小弟搞得热情高涨，比民工累，从而用最低的成本创造最大的利润。

项目管理作为战术层次的管理手段，一定要服务于战略层次的大方向。商场如战场，有胜利就会有失败。为了战略胜利，很多战役要诱敌深入，必须打败仗。败仗不要紧，关键要弄清楚败到什么层次，损失到何种地步，明确本次战役的真实目标，再去打这场战役，就会做到驾轻就熟，从而不至于到最后形成不仅损兵折将，还未能诱敌深入的局面。

开拓市场、占领市场、站稳市场、挖掘市场，这是每个公司发展必不可少的步骤。很多项目，对公司来说都是为了占领市场，甚至虎口夺食。这样的项目，公司从战略层面首先要求的绝对不是盈利，而是如何能把市场占领，继而站稳，项目经理必须明白这个战略意图。

平衡是项目管理最为重要的一个思想，从过去的做好质量、时间、成本项目三要素的平衡，到现在满足相关干系人的需求，所有的最佳实践和理论研究成果，都绝不会提倡走极端，杀机取卵！利润只是项目的一个目标，并且一定要明白有短期利润和长期利润之分，过分单一追求利润的项目注定要失败，过分追求利润的公司也不会长久。

该花的钱不能省，不该花的钱一分也不要花，项目经理把成本控制在合理的预算范围内，就是成本控制的成功。万万不可为了把一个注定要赔钱的项目做得盈利而想尽办法、绞尽脑汁压缩成本，从而让组员加班加点，玩命干活，到最后，项目干完了，人也走/光了，还极有可能因为赶工导致项目质量不合格，客户不满意，那就真的赔了夫人又折兵!

项目组要能保持激情高效，不能懒散拖沓，项目经理一定要把握好这个度，绝不能走极端。平衡是一门艺术，也是展示项目经理能力水平的一个重要标尺！

错误六：记住了科学，忘记了有效

学以致用，就怕乱用。无论是产品、技术还是管理方法，都存在为了更先进、更科学而罔顾现实，盲目乱用的现象，结果先进和科学的技术、工具不仅未提高生产效率，却成了累赘，这样的情况到处都是，在IT项目中也为数不少。

国内大量失败的ERP项目就是这类错误的典型。有人把ERP项目归结为一把手工程，意思是只有领导重视并推动才能成功。领导支持是项目成功很重要的一个条件，但绝不是有领导支持就一定能够成功。有些项目就是领导决策失误盲目上的，从开始就注定项目要失败。一个信息化项目的实施，对很多企业来说就是一场大的改革，对所有员工从思维、技能到工作习惯等多方面都需要进行调整。如果企业的员工素质不能跟上，纵然有各种各样的培训，但不顾员工基础和学习曲线，用户不能真正掌握全新的系统，结果就只能增加用户负担，而产生不了期望的效果。

很多IT项目经理在学习了一些新的技术后，总想立刻在项目中实践，而不去仔细分析这些技术在这个项目中是否需要，是否适合。IT技术日新月异，不断有新的理论被提出来，被翻译引进到国内。有些项目经理在一知半解，对这些技术还不是很熟悉的情况下，就敢向人吹嘘他所掌握技术的科学性、先进性，进而强制要求在项目中实践。这可能是甲方的项目经理，也可能是乙方的项目经理。因为技术选择错误导致项目失败的例子在国内过去有，现在也还有!绝对不可准备不足，大范围引入全新的技术，待到项目时间过去一半了，才发现选择的技术不适用，那时候一切都晚了。掌握任何新东西都有学习曲线，项目的时间限制是项目经理必须时刻牢记的要素，把握不好就会给项目带来极大风险。

涉及到具体的IT项目管理，PMBOK的知识体系可谓博大，还有一些其他新的项目管理工具，不能说不先进，但是哪些知识、工具、方法适合本项目，需要项目经理根据实情，认真分析后进行筛选使用。

科学、先进、好用等等修饰头衔这些都不是要选择的首要理由，需要、适用和有效才是首要考虑的事情。很多IT项目经理因为年轻，初生牛犊不怕虎，胆量大，勇气足，敢于在实践中引入新的工具、方法。敢于尝试不是坏事，但试验的风险一定要控制好。对于项目经理来说，所有的决策都要围绕项目目标进行。项目经理的首要任务是保证项目成功，如果同时能引入新的技术、工具，增加组员的知识技能，提升项目组工作效率，提高产品的质量和可靠性，绝对是锦上添花，但绝对不能为了锦上添花而导致项目失控甚至失败，捡了芝麻，丢了西瓜!
转自：http://sd.csdn.net/a/20110819/303332.html

有一段时间不用虚拟机了，今天又要用到虚拟机。开机虚拟机后，Power on出现上述信息

net start vmci
原因：

Sometimes WS 6.5.0 does not start this automatically

早上同事用PL/SQL连接虚拟机中的Oracle数据库，发现又报了“ORA-12514 TNS 监听程序当前无法识别连接描述符中请求服务”错误，帮其解决后，发现很多人遇到过这样的问题，因此写着这里。

也许你没有遇到过，原因如下：

你oracle安装成功后，一直未停止数据库（即数据库是启动的），客户端配置成功后，应该一直不会有什么问题。

而一旦你和我同事一样，有时把Oracle安装在虚拟机中，而且Oracle安装完毕后，没在进行任何监听的配置，则虚拟机再启动，则就会出现ORA-12514的问题。如下图

TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" name=image_operate_32961295504739984 alt="ORA-12514 TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" src="http://s7.sinaimg.cn/middle/5007d1b1g9a40c1c8ebf6&690" width=378 height=106>

如下是解决思路：

根据出错信息判断出客户端未监听到实例服务名

1、通过重启服务的方式启动数据库，再次连接仍无法连接服务器。

2、既然第一种方法不能解决问题，那就第二种方法。考虑监听listener.ora

   监听配置文件listener.ora中可以不必指定监听的服务名（安装Oracle10g后也是没有指定的）。正常情况下一般只要数据库启动，客户端连接数据库也没有什么问题，但是有时重复启动关闭也会出现ORA-12514错误。

   既然listener.ora中没有指定监听，我们可以在listener.ora文件中指定监听的实例名，这样该问题应该可以连接。

步骤如下：

• 在oracle服务器Oracle安装目录（我的在E:\Oracle10g下，每个人的不一样，根据自己的情况查找）Network/admin目录下找到listener.ora 我的如下图所示

# listener.ora Network Configuration File: E:\Oracle10g\network\admin\listener.ora
# Generated by Oracle configuration tools.

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = E:\Oracle10g)
      (PROGRAM = extproc)
    )
   (SID_DESC =
    (GLOBAL_DBNAME = ORCL)
    (ORACLE_HOME = E:\Oracle10g)
    (SID_NAME = ORCL)
    )
 )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
      (ADDRESS = (PROTOCOL = TCP)(HOST = onest)(PORT = 1521))
    )
  )

标红的为我添加的部分，ORCL为监听的实例名。

• 然后在Oracle服务器的服务中重新启动监听服务TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" name=image_operate_641295504618796 alt="ORA-12514 TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" src="http://s16.sinaimg.cn/middle/5007d1b1g9a4102276c5f&690" real_src="http://s16.sinaimg.cn/middle/5007d1b1g9a4102276c5f&690">，然后在oracle客户端通过再次配置对Orcl实例的监听，如下图所示TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" name=image_operate_40861295504642796 alt="ORA-12514 TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" src="http://s6.sinaimg.cn/middle/5007d1b1g9a410a2805c5&690" width=476 height=86 real_src="http://s6.sinaimg.cn/middle/5007d1b1g9a410a2805c5&690">
• 结果出现如下图的提示。
  TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" name=image_operate_14831295504695718 alt="ORA-12514 TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" src="http://s13.sinaimg.cn/middle/5007d1b1g9a40c26294dc&690" width=598 height=401 real_src="http://s13.sinaimg.cn/middle/5007d1b1g9a40c26294dc&690">
• 这时我们不要着急，只需要oracle服务器重新启动一下，再次连接即成功。这也是我们配置完listener.ora 监听后，经常忘记的。再次尝试，可以看到客户端可以连接上oracle服务器了，而且PL/SQL再次连接也没有问题了。

而有些朋友在配置客户端时，连接数据库成功，而使用PL/SQL时，又出现了如下图所示的问题。这又如何解决呢？为什么oracle客户端已经连接成功了，而PL/SQL确不行呢？

TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" name=image_operate_78131295504727281 alt="ORA-12514 TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" src="http://s3.sinaimg.cn/middle/5007d1b1g9a40c320fad2&690" width=436 height=288 real_src="http://s3.sinaimg.cn/middle/5007d1b1g9a40c320fad2&690">

出现如上的原因是，可能是大家再配置oracle客户端时，虽然链接成功了，步骤上可能有些错误。大家使用Net Cofiguration Assistant客户端时重新配置了Orcl，而不是添加，我们应该如下步骤处理，就不会出问题了。

1、如果Net Cofiguration Assistant中已经有了Orcl。我们可以重新配置

2、如果Net Cofiguration Assistant中没有Orcl，我们应该添加  具体界面如下图所示。

TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" name=image_operate_52121295504778234 alt="ORA-12514 TNS 监听程序当前无法识别连接描述符中请求服务 的解决方法" src="http://s5.sinaimg.cn/middle/5007d1b1g9a412cc6e6d4&690" width=594 height=397 real_src="http://s5.sinaimg.cn/middle/5007d1b1g9a412cc6e6d4&690">

如果大家该步处理也没有问题了，listener.ora 修改成功，并且重新启动了oracle服务器，无论oracle客户端还是PL/SQL都能够成功连接数据库了。

总结一下。当大家遇到“ORA-12514 TNS 监听程序当前无法识别连接描述符中请求服务”错误的解决步骤：

1、通过重启服务的方式启动数据库，再次连接尝试。

2、如果第一种方法不可行，我们采用第二种方法

• 正确添加listener.ora；
• 重新启动了oracle服务器，并检查oracle所有服务是否启动；
• oracle客户端Net Cofiguration Assistant正确添加或重新配置实例名 

(文：包一磊)

AJAX的出现极大的改变了Web应用客户端的操作模式，它使的用户可以在全心工作时不必频繁的忍受那令人厌恶的页面刷新。理论上AJAX技术在很大的程度上可以减少用户操作的等待时间，同时节约网络上的数据流量。而然，实际情况却并不总是这样。用户时常会抱怨用了AJAX的系统响应速度反而降低了。

笔者从事AJAX方面的研发多年，参与开发了目前国内较为成熟的AJAX平台-dorado。根据笔者的经验，导致这种结果的根本原因并不在AJAX。很多时候系统响应速度的降低都是由不够合理的界面设计和不够高效的编程习惯造成的。下面我们就来分析几个AJAX开发过程中需要时刻注意的环节。

n 合理的使用客户端编程和远程过程调用。

客户端的编程主要都是基于JavaScript的。而JavaScript是一种解释型的编程语言，它的运行效率相对于Java等都要稍逊一筹。同时JavaScript又是运行在浏览器这样一个严格受限的环境当中。因此开发人员对于哪些逻辑可以在客户端执行应该有一个清醒的认识。

在实际的应用中究竟应该怎样使用客户端编程，这依赖于开发人员的经验判断。这里很多问题是只可意会的。由于篇幅有限，在这里我们大致归纳出下面这几个注意事项：

u 尽可能避免频繁的使用远程过程调用，例如避免在循环体中使用远程过程调用。

u 如果可能的话尽可能使用AJAX方式的远程过程调用（异步方式的远程过程调用）。

u 避免将重量级的数据操作放置在客户端。例如：大批量的数据复制操作、需要通过大量的数据遍历完成的计算等。

n 改进对DOM对象的操作方式。

客户端的编程中，对DOM对象的操作往往是最容易占用CPU时间的。而对于DOM对象的操作，不同的编程方法之间的性能差异又往往是非常大的。

以下是三段运行结果完全相同的代码，它们的作用是在网页中创建一个10x1000的表格。然而它们的运行速度却有着天壤之别。

这里的“测试代码1”和“测试代码2”之间的差别在于在创建表格单元时使用了不同的API方法。而“测试代码2”和“测试代码3”之间的差别在于处理顺序的略微不同。

“测试代码1”和“测试代码2”之间如此大的性能差别我们无从分析，目前所知的是insertRow和insertCell是DHTML中表格特有的API，createElement和appendChild是W3C DOM的原生API。而前者应该是对后者的封装。不过，我们并不能因此而得出结论认为DOM的原生API总是优于对象特有的API。建议大家在需要频繁调用某一API时，对其性能表现做一些基本的测试。

“测试代码2”和“测试代码3”之间的性能差异主要来自于他们的构建顺序不同。“测试代码2”的做法是首先创建最外层的<TABLE>对象，然后再在循环中依次创建<TR>和<TD>。而“测试代码3”的做法是首先在内存中由内到外的构建好整个表格，最后再将它添加到网页中。这样做的目的是尽可能的减少浏览器重新计算页面布局的次数。每当我们将一个对象添加到网页中时，浏览器都会尝试对页面中的控件的布局进行重新计算。所以，如果我们能够首先在内存中将整个要构造的对象全部创建好，然后再一次性的添加到网页中。那么，浏览器将只会做一次布局的重计算。总结为一句话那就是越晚执行appendChild越好。有时为了提高运行效率，我们甚至可以考虑先使用removeChild将已存在的控件从页面中移除，然后构造完成后再重新将其放置回页面当中。

n 提高字符串累加的速度

在使用AJAX提交信息时，我可能常常需要拼装一些比较大的字符串通过XmlHttp来完成POST提交。尽管提交这样大的信息的做法看起来并不优雅，但有时我们可能不得不面对这样的需求。那么JavaScript中对字符串的累加速度如何呢？我们先来做下面的这个实验。累加一个长度为30000的字符串。

这段代码耗时14.325秒，结果并不理想。现在我们将代码改为如下的形式：

这段代码耗时0.359秒！同样的结果，我们做的只是首先拼装一些较小的字符串然后再组装成更大的字符串。这种做法可以有效的在字符串拼装的后期减小内存复制的数据量。知道了这一原理之后我们还可以把上面的代码进一步拆散以后进行测试。下面的代码仅耗时0.140秒。

不过，上面这种做法也许并不是最好的！如果我们需要提交的信息是XML格式的（其实绝大多数情况下，我们都可以设法将要提交的信息组装成XML格式），我们还能找到更高效更优雅的方法—利用DOM对象为我们组装字符串。下面这段代买组装一个长度为950015的字符串仅须耗时0.890秒。

n 避免DOM对象的内存泄漏。

关于IE中DOM对象的内存泄露是一个常常被开发人员忽略的问题。然而它带来的后果却是非常严重的！它会导致IE的内存占用量持续上升，并且浏览器的整体运行速度明显下降。对于一些泄露比较严重的网页，甚至只要刷新几次，运行速度就会降低一倍。

比较常见的内存泄漏的模型有“循环引用模型”、“闭包函数模型”和“DOM插入顺序模型”,对于前两种泄漏模型，我们都可以通过在网页析构时解除引用的方式来避免。而对于“DOM插入顺序模型”则需要通过改变一些惯有的编程习惯的方式来避免。

有关内存泄漏的模型的更多介绍可以通过Google很快的查到，本文不做过多的阐述。不过，这里我向您推荐一个可用于查找和分析网页内存泄露的小工具—Drip，目前的较新版本是0.5，下载地址是http://outofhanwell.com/ieleak/index.php

n 复杂页面的分段装载和初始化

对系统当中某些确实比较复杂而又不便使用IFrame的界面，我们可以对其实施分段装载。例如对于多页标签的界面，我们可以首先下载和初始化多页标签的默认页，然后利用AJAH（asynchronous JavaScript and HTML）技术来异步的装载其他标签页中的内容。这样就能保证界面可以在第一时间首先展现给用户。把整个复杂界面的装载过程分散到用户的操作过程当中。

n 利用GZIP压缩网络流量。

除了上面提到的这些代码级的改良之外，我们还可以利用GZIP来有效的降低网络流量。目前常见的主流浏览器已经全部支持GZIP算法，我们往往只需要编写少量的代码就可以支持GZIP了。例如在J2EE中我们可以在Filter中通过下面的代码来判断客户端浏览器是否支持GZIP算法，然后根据需要利用java.util.zip.GZIPOutputStream来实现GZIP的输出。

一般而言，GZIP对于HTML、JSP的压缩比可以达到80%左右，而它造成的服务端和客户端的性能损耗几乎是可以忽略的。结合其他因素，支持GZIP的网站有可能为我们节约50%的网络流量。因此GZIP的使用可以为那些网络环境不是特别好的应用带来显著的性能提升。使用Http的监视工具Fiddler可以方便的检测出网页在使用GZIP前后的通讯数据量。Fiddler的下载地址是http://www.fiddlertool.com/fiddler/

关于Web应用的性能优化其实是一个非常大的话题。本文由于篇幅有限，只能涉及其中的几个细节，并且也无法将这些细节的优化方式全面的展现给大家。期望本文能够引起大家对Web应用尤其是客户端性能优化的充分重视。毕竟服务端编程技巧已为大家熟知多年，在服务端挖掘性能的潜力已经不大了。而在客户端的方法改进往往能够得到令人惊奇的性能提升。

PopCap游戏公司亚太区总裁James Gwertzman

对于植物大战僵尸成功秘诀，James Gwertzman总结了以下几点：

第一点：设计的游戏必须要有创新。仅把别人的游戏直接搬过来虽然也会成功，但是永远没有办法做成最好的游戏，最好的游戏永远都是原创的、创新的。

第二点：要不断进行完美。设计的游戏要让每种不同类型的人测试这个游戏，去适应不同人群。

第三点：游戏发布后，要不断更新。成功游戏往往会经常更新，植物大战僵尸每三个月会更新一次。

第四点：同时需要充分利用社会网络，要把社会网络和游戏联在一起，这样可以影响游戏的销售情况。

第五点：游戏支持的设备也很重要，对于小开发商必须支持一系列设备。

第六点：最开始游戏要是免费的。免费游戏很容易被嵌入到一些设备。

附演讲实录：

James  Gwwertzman：大家好，今天给大家谈一谈我们PopCap的经验，我们想问一下大家有多少人玩过，所以这样我就不介绍这个游戏了，我们PopCaP目前为止最成功的游戏也是卖得最快的游戏，我想介绍我们怎么放在移动端上应用，首先给大家举一个例子这里面是我们原来这个游戏获得的一些奖项大家可以非常受欢迎，不仅在PC机上在手机上也是有很多流行比用iPhoen其他设备玩这个游戏，比如说在中国我最喜欢这个视频是从哈尔滨学生传过来，他们做了一个小视频模拟了这个游戏，可以在土豆或者其他上面可以看到，这个可以看到哈尔滨冰雪节的时候，哈尔滨每天雪雕艺术展，我们还有iPhoen版本，大家有多少人在iPhoen或者Ipad上，这个是我最喜欢的版本，最有意思，最好玩和在PC机或者iPhoen，Ipad是最有意思最好玩的。

当我们推出iPhoen版本我们当时第一周销售超过100万美金，然后对于我们PopCaP公司还有包括iPhoen都是历史记录，这个是我们销售在亚洲销售情况，可以看到红色这个是大中华区，绿色是澳大利亚，中间这一部分我们在中国iPhoen版本比其他国家都要多这个是很少见，我们从来没有在中国卖游戏赚钱这是第一次，我们在iPhoen上面比日本，新加坡，还有其他的一些都是远远超过的，增长速度也是不断的在增加，在我们销售平台上增加，所以越来越设备销售出去越来越多，iPhoen4当几周以前上个月北京国内推出iPhoen4，中国成为第二个全球的PPZ国家第一是美国，第二是中国，iPhoen4越来越多会下载我们这个植物大战僵尸。

我想谈一下如何能做一个成功的游戏，当然要开发一个好的游戏，但是不仅如此要开发一个很好游戏其实并不容易，我们PopCaP有几方面做得比较好，首先第一个就是你必须要能够创新，不能说把别人的游戏直接搬过来放过来就成功，当然抄别人东西可能风险比较小，可能做得还不错但是永远没有办法做到最好游戏，最好的游戏永远都是原创，创新的，和别的游戏不一样的，这个不是我们PopCaP游戏，这个仍然也是做得非常好的游戏，现在有很多不同版本，不同方面，第一要承担创新的风险，第二当你有想法要不断完美，我觉得对于开发者有很多问题，就是说还没有把这个游戏完全做得非常好，还做得比较好，或者还不错，还不是完美就推出我们这个游戏花三年时间准备，第二年我们CEO说这个不错，很好游戏赶紧推出我们说不行，我们还不是很完美游戏，到第三年我们才觉得这个游戏是趋于完美了，我们CEO当时说原来第二年的时候说要把这个游戏推出，他说这是他做得最大一个错误，因为第三年可以把这个游戏进一步雕琢，这个是一个屏幕截图，这个是我们第一个版本，我们当时第一个版本05年就是这个样子的，所以可以看到我们第一个版本叫种种子，就是说你把你植物种到土里面，这些都是植物逐渐一点点长大，植物长大开始和坏人作战，右边可以看到是种植工，开发人员他们当时设计就是原来植物和害虫打仗不是和僵尸这个是游戏原形，当时这个游戏一点都不好玩，种种子还要等着这个种子长大这个过程和烦人，你看到你种种子下去逐渐长大作战，种下种子马上要跟它进行坏人作战，从原形我们发现他的问题在哪里这个是06年第二版本植物大战僵尸，我给大家看一下这个游戏。

可以看到谁能认出这个图标，我们上面说在一个暖箱当中，在早期版本上你必须选择某一个卡，把它放到这个卡当中，像这样，你选择你的卡片以后会随即选择哪个卡来玩。

比如说是随即来选这个植物的，然后你要等他卡出现在上面，这个也不是很有意思，为什么？它太随即了，比如说我现在想在这边再种一个种植我不能种了，得等到卡出现才能种，它太随即了。所以大家可以看到这是早期一个版本。所以在这个版本06年版本当时告诉我们就是这种随机性现在卡片，随即你选什么也不是很有意思，不好玩，我们永远不是有一个设计的文件，我们不在纸上写下来游戏是怎么设计出来，你不知道你只有玩的时候才知道这个话游戏好玩不好玩，你只有做完以后玩以下才知道这个游戏意思没意思，早期版本向日葵，僵尸最初分几行种植这是我们原形还有很多东西我们早期是没有考虑是后期添加，这个也是我们从早期版本学到这个是另外一个版本，是我们07年一个版本，07年我们这个游戏其实看起来已经很好玩，背景跟现在差不多，包括格子分布，僵尸形状基本定下来，有很多已经定下来还有最主要一个问题，大家可以看到我不知道大家能不能看到这些植物图表，向日葵是100分，豆荚也是100分，对新玩家玩这个不了解这个经济学，不了解就是说为什么你要先种很多向日葵再种豆荚打僵尸刚开始玩家可能会挣很多钱，有100块钱他想我是选向日葵还是豆荚先玩家会建立这样一个的在家门口都是种的豆荚，最后肯定会失败不了解这个游戏，所以当时我们设计师想如何解决这样的问题，如何教给新玩家为什么先种向日葵，这个对于很多游戏设计师第一答案你教他，如果玩家不懂你要加一个说明，但是我觉得这个设计是不好的，说明就是修整你设计当中存在的漏洞，但是这个并不是最好的解决方法，所以他们所做我们的设计师就是说你只能，你某些区域只能种向日葵不能种豆荚，最后我们提出解决方案把价格调整以下，向日葵是50分，豆荚是100分，新玩家会被你带领种很多的向日葵，通过小阳光挣很多钱才能花钱种豆荚等等，这个就是很好的解决了这样一个问题，所以你看到是一个很小的变化，但是影响整个游戏对新玩家的布局。

对于高级玩家对于其他游戏很熟悉这个你没有什么问题，因为你已经了解了就是先种向日葵再种豆荚，只有随便玩一玩，普通玩家不了解这里面的情况，另外一点我们设计其实目标是针对所有人，大人，小孩，男女等等，你必须找所有人进行测试，我们当时用我们老婆或者女朋友玩这个游戏，所有人都发现这样一个问题，我们自己监测的时候没有任何问题，但是有些人从来没有玩过游戏，觉得这个游戏太难，你设计游戏要让每一个不同类型人测试你这个游戏，这个最新版本是我们花四年时间，是09年版本，我们最初是05年设计出来，大家可以看到是我们最终出来的情况，可以看到价格还有其他很多方面都定下来，你不能够急于求成有很多东西要花很多时间雕琢才能达到精品，我这个笔记本里面有植物大战僵尸十多不同版本，我们一点一点来雕琢完善，第二开发出来很好游戏必须做一个很好手机游戏，像原来我们在电脑上游戏是不一样，如果你在智能手机开发出来游戏还要考虑很多其他因素，对于手机游戏来说首先第一个必须要有一个直观控制，特别是在触屏方式，你设置用户界面是非常关键，如果UI觉得不好玩，没有直接沟通等等，这样没有做好，要有一个直接控制，要调整你这个游戏，或者你把这个游戏来设计，比如说给大家举一个例子，左边是一个在电脑上PC机上的版本，右边是iPhoen版本，可以看到首先第一点就是它的按纽在iPhoen上按纽大很多，iPhoen本身很小，屏幕本身很小，按纽必须比较大用户才能按到，而且很容易能够看到，僵尸脑袋大很多，大了20%，这样用户很容易看到这是那种僵尸，我们还把UI转边上，整个下面一个集成表，我们从右下角挪到中间上面，非常小的改变使它适合IPhone，我们当时有很多设计，在IPhone上面我们使它更加简化而且符合多种平面要求，可以看到右下角不同的iPhoen的UI，所以你对你的游戏不断调整才能做出成功的游戏。

第三点就是必须要不断更新你要不管是3G，2G等等，要跟上，然后成功游戏往往会经常更新，我们植物大战僵尸每三个月更新一次，有些公司频率会更高一些，比如说愤怒鸟这个游戏每两周更新一次，他们也不收钱，你买这个游戏一次每两周都可以更新一次，没有什么问题，这个游戏不断进行更新，人们不断玩不断告诉他们朋友，所以这个愤怒鸟在游戏当中一直是排名前十位，不断更新随着技术不断进展，比如说iPhoen也出现，Android也出现了，技术可能变化速度更快，必须要准备好，不仅仅开发完了这个游戏就是一劳永逸了，是要不断的投入。

还是回到前面这个图，如果你游戏正确你销售会一直增加，我们卖出这个拷贝已经很多了，跟刚开始推出这个游戏已经有很多版本被销售出去，所以大家不要想你这个游戏只卖一个月就完蛋了，如果是一个好的游戏一直会保证一个非常好的销售，所以你要对这个游戏一直进行投资，我们要听取玩家意见，把他融入到我们游戏设计里面去，同时我们需要充分利用社会网络，我们要把社会网络和我们的游戏联在一起，这样可以会影响我们游戏的一个销售，我们看一下一个游戏大家玩过在脸谱上的一个游戏，是一个非常有名的游戏是他的一个改编版本这个就是iPhoen的版本，时间并不是特别长，一般来说都是排第五，第六iPhoen游戏，我们就是把它加上了，我们需要从iPhoen游戏当中登录我们脸谱的一个游戏，可以游戏上玩这个游戏可以得到一个比较高的分数，可以把比较高的分数放到脸谱上，这样一个变化影响是什么，这里是我们销售的一个结果，就是在我们加上脸谱内容以后，在我们加上脸谱的连接性以后，可以看到很多人会在iPhoen上购买游戏，因为他们是从脸谱上了解到这个游戏的，而且我们的销售量也是有了很大的增加，可以看到这个销售量就是在我们加入社交网络之前相比我们销售收入已经增加了两到三倍。

那么我们可以一次性购买iPhoen的游戏，然后可以利用我们的模式规模更多一些更新版本，所以可以看到社会的网络，我认为是相当重要，而且他也会推动我们下一轮网络游戏的一个发展。比如说现在在日本，现在最大的市场是移动社交网络，美国和中国也会很快追上来，我们开发游戏是要把游戏和社交网络结合在一起，因为我们认为这个是一个非常大的成长空间，我们大家应该更多考虑一下社交网络，再现网络或者是社交网络联在一起，另外是我们支持设备也是相当重要，对于小开发商我们必须支持一系列设备，对于PopCaP也是一个非常大的挑战，比如说现在我也没有一个对Android还没有一个很好的融合，比如说之前我们也发现要支持很多设备是非常难的，我们有很多技术但是我们还需要做很多调查测试这是一个非常大的挑战如果我们游戏可以在更多设备商玩我们就会增加一个收入。

后面我会讲一下PLANTS。这个就是其中一个离子2我认为PLANTS这个版本要比我们的PC版本还有移动手机版本要好得多，将来我们会更多开发一些用于PLANTS方面游戏，我们会设计一些图标，比如说我的孩子只有6岁他特别喜欢我这个IPAD，因为他喜欢用我的IPAD玩游戏，我们家里面也有PC和其他设备但是他总是喜欢通过IPAD玩游戏也就证明这方面市场是非常大。

我们看一下在亚洲和中国，我没有必要告诉F2P是一个很好的模式，我们知道免费玩游戏是一个非常好的模式，当然在美国销售游戏是比较好的模式，在中国我想免费玩游戏是非常好的模式，特别是在中国，或者在亚洲我们发现很多游戏是免费玩的一种模式，如果是能够免费玩的话，如果是这种模式游戏DRM很容易被破解，但是在IPAD可以有，别的地方没有，所以这个DRM五问题一定是非常重要的，另外一个就是有大量的OEM嵌入机会，游戏是免费游戏很容易被嵌入到一些设备，可以获得一些许可一些成本，可以获得一些许可费，同时比如说我们看一下软件商城，这里就是一个IPhone上一个嵌入一个应用我们需要够一些它也是非常好，我们点击一下我们就可以进行采购，我想就是每个人都曾经用过这样一些界面我们知道可能有两到三十个软件，这样模式可能会很快流行起来，你是否愿意花更多时间玩那些你认为可以玩的那些游戏吗，对于用户来说可能会首先购买一个游戏，如果这个游戏是免费，我想问题不会特别大，如果游戏刚开始是免费，也许他们会愿意花一些钱买一些工具，所以大家一定要采用这种模式，最开始游戏是免费的，我不知道有多少人知道PopCaP我们在很多平台上是非常成功，我们有PC，还有在手机，还有在脸谱上等等我们都特别好的游戏的应用软件。

我们希望能够把所有这些平台整合一起，我知道这是一个移动开发者大会，当然这个移动游戏是非常好的，如果这个移动游戏能够和其他平台结合在一起，比如说和我们的网络游戏，PC游戏或者是社交网络联在一起将会更好，如果能够整合所有平台的话，我们的游戏会变得特别强大。

我还有一些关于几个游戏的一些例子，我也会给大家展示一些示范。接下来给大家介绍我们PVZD的一些游戏，然后我们会进入问答环节，我们做植物大战僵尸我们最重要这个游戏一定要好玩，关于PVZ这个游戏，不知道大家是否熟悉这个游戏，在美国就是我们有4月1日愚人节我们喜欢在办公室玩游戏，我们喜欢玩这个PVZ，我们也喜欢在4月1日玩植物大战僵尸游戏我们可以看到，比如说我们会骗别人说我们有一个最新版本最好的植物大战僵尸游戏美国人下载，结果不是，每个人都被骗了。我们有一个内部工具，玩家可以在上面加上他们的一些评论，他们可能会有一些不同评论可能说最好的PVZ版本有些人会说我们会用这个，或者我们怎么杀死圣诞老人僵尸如果你玩的话你会发现它特别有意思。这个就是愚人节的版本，很多人都说根本不好，这个游戏根本不能玩，很多人会问到底出了什么问题，当然这个是一个游戏是一个愚人节版本，同时我们还有一个另外一个僵尸游戏，这个游戏也是来欺骗别人的，大家可以看到也是特别有意思的。我不知道我们还有多长时间，但是现在我想我们应该回答一下大家的问题，如果大家有问题我们可以提问一下。

他问的问题在我们说到免费版本，我们是通过广告赚钱还是通过在线游戏，通过工具来赚钱呢？我们答案就是第二种情况，游戏当中广告说实话并不是很成功，比如说每年我们都听到这样的一些说到游戏当中加广告是非常好的模式，实际上我们这个模式我们也是用十年时间但是从来没有成功，我想就是你让用户为这个工具花钱的话，可能会更加成功，因为觉得花这个钱是为他自己花的，所以我的答案就是第二种模式。

他是一个评论PopCaP是一个如果让人们为这个工具花钱，我们会有一个免费模式，应该成为一个社会网络的游戏，比如说我们做的第一个游戏，这个游戏在脸谱是可以玩的，因为脸谱是一个社交网络我们可以和朋友，一起竞争玩这个游戏，可以拿到一个非常好的分数，他是一个一个非常简单在线模式，也就是说你所要想的就是要获得最高的分数，使劲玩获得很多分数很多人在这方面愿意花很多钱玩这个游戏，这个游戏每年也是变得越来越复杂，可以看到这个游戏就是和最开始我们这个游戏推出和6个月之前我们发现每个用户在上面花钱跟我们游戏推出开始的时候比这个钱是之前的4到5倍，我们有很多方法改善我们的游戏，更新我们的游戏，很多人讲到AP测试就是说我们应该做不同的测试然后选择最好的方法，通过他可以对我们游戏进行提高但是我们可以提高10%到20%，如果我们加入一些新特点，我们能够非常快的推动这个游戏的一个推广，如果你分数非常高这个游戏会说祝贺你，因为你发现我们的月亮石，你是否愿意买，这个玩家会觉得是一个珍贵的宝石，所以他们会用他们免费货币买，当然如果你没有网上虚拟货币可以用真钱买我们的宝石。

当然并不会改变我们的多层的一个平台，很多人非常喜欢这样一种模式，比如说有很多人会尝试这样一个游戏，然后会反复玩，如果我们能够尝试不同的东西的话，可能会帮助你生成更多的收入非常感谢。

提问：我有两个问题，你讲到PopCaP我们会进入社交网络游戏不仅仅是手机游戏，我中国有一个网络开发商他们已经创建了一个在线的PVZ游戏版本他，他可以在任何浏览器上使用，我的第一个问题就是他很容易被复制，很容易被复制到中国来。所以可能会影响PopCaP在中国的收入，那么您的看法是什么呢？

James  Gwwertzman：就是对于这种山寨游戏我们是非常关注，比如说中国很多山寨游戏我们都知道，有的时候我们会提起上诉，当然就是用法律手段是一种方法，我们都知道PopCaP这个游戏有的时候需要花很多时间才能开发出来好的，很多山寨游戏并不是特别好，总的来说用户都不喜欢那些山寨游戏因为我们总是要听看这个PPS论坛上用户意见这并不是真的我们不喜欢这个游戏，是山寨版本给了我们一个希望，用户新的真的版本，真的东西，真的品牌，我们能够提供一个真正的PVZ游戏如果很有意思我们会占据优势，当然要花很多时间，最开始游戏要花四年时间，要建立一个在线游戏当然要花很长时间，我们最终会推出这样一个在线游戏，我们竞争对手并不应该是这种山寨游戏因为他们的质量太差了，我们真正竞争对手的并不是山寨开发商，我们最大的竞争对手是我们自己，很多人喜欢以前版本我们要把他吸引到再现游戏版本上来说的话，对我来说这是一个很大的挑战，当然如果我们花很长时间开发出非常好在线游戏丰富它的内容我们排名还要考前，人们一直想要尝试愿意玩他们这个游戏，我们希望我们能够开发出特别好的游戏，而且一直进行更新。

我想就是中国可能和国际市场有一些不同，在中国我们有几个非常大的社区，比如说人人，QQ我们知道最初版本是脸谱是一个原创版本，但是PVZiPhoen版本，他们也有一些功能可以很脸谱朋友联一起，但是这个人人还有QQ上的朋友，现在人们喜欢通过山寨版本的脸谱和自己的朋友联合，实际上就是我们也有一个版本就是通过iPhoen可以跟人人联在一起，我们还没有在人人上启动一个功能，但是我们特别重视中国的社交网络比我们跟人人，开心，QQ都进行过跟踪，脸谱不是中国本土网络，在中国就是这样一些市场必须是本土化的，所以我们也希望PopCaP一些游戏能够实现本土化。

你最近是在中国市场上，它能不能用在SNS比如说人人网络上我们现在是出版了它的实验版将来大家可能会看到。

提问：第一就是你如何平衡它的时间和进展，你刚才说你前面植物僵尸是花四年时间不断雕琢，那么你四年肯定花了很多时间金钱等等，如果成功了没有问题，但是如果你四年以后还是失败怎么办。

第二个问题你如何比如说像EA你觉得他们是你的竞争对手吗？

James  Gwwertzman：第一个问题如果我们花四年时间做游戏如果失败怎么办，比如说花了很多时间精力，对于我们就是快点失败，如果失败就会快一点，这个游戏不会一直投入，然后发展到失败，这个原形就是我们可能过了两周觉得这个游戏不是很有意思，但是我们没有说完全放弃，我们要看它有没有意思，再改进，如果说你这个想法有意思只需要改进可能花三年，我们花了6个月就知道这是一个很好的游戏，如果这个游戏过六周没有意思过了三年也没有意思我们PopCaP有很多游戏没有上市，我们推出很多游戏可能是很多游戏都是从来没有出过他的摇篮当中，你看到都是成功的游戏我们会很快决定，所以对于成本和质量来说往往是有关系，我们CEO说我们每两年推出一个游戏，一个成功的游戏的话，我们做的时候是非常好，每两年只要能有一个游戏成功就没有问题，但是及时这样都很难但是我们不可能一年推出十个游戏，所有都是很一般的游戏，所以游戏好还是不好，得好不好，是不是所有的平台的多挣钱，PC挣这么多钱，iPhoen每一个平台设备都能挣钱所以一个非常伟大的  游戏，根据这个游戏开发出一个不同的系列。

提问：我想问一下你对于在线多玩家游戏是什么看法。

James  Gwwertzman：这个问题中国现在就是做PC游戏越来越少，我觉得全球范围之内也是这样，PopCaP也是单一玩家游戏会越来越少，将来我们可以看到社交游戏在线游戏，网上游戏等等，网上游戏有很多优势，所以我觉得每个游戏PopCaP有一个网络特性，社交特性，我们现在设计游戏是针对每个人的，所以我们植物大战僵尸也是这样，我们希望将来能够添加我们社交特色社交网络，对于中国更是这样，我们上海有80人团队做中国游戏开发，比如说一个月之前在韩国我们宣布了一个新产品叫PopCaPW是第一个自由在线多玩家PopCaP游戏，有一个超级祖玛四个人多万家2玩祖玛游戏这个是祖玛游戏最有意思一个版本，我们在韩国现在推出了，将来我们有可能把它带到中国市场，我们现在正在开发这种多玩家在线游戏，但是不仅仅是PC，我们说移动设备，比如说现在我们可以看到Android等等，我们觉得多设备，界面也是非常有潜力，非常感谢大家。

作者： KeeKim Heng, Google Web Developer

在我们开发互联网富应用（RIA）时，我们经常写一些javascript脚本来修改或者增加页面元素，这些工作最终是DOM——或者说文档对象模型——来完成的，而我们的实现方式会影响到应用的响应速度。

DOM操作会导致浏览器重解析(reflow)，这是浏览器的一个决定页面元素如何展现的计算过程。直接修改DOM，修改元素的CSS样式，修改浏览器的窗口大小，都会触发重解析。读取元素的布局属性比如offsetHeithe或者offsetWidth也会触发重解析。重解析需要花费计算时间，因此重解析触发的越少，应用就会越快。

DOM操作通常要不就是修改已经存在的页面上的元素，要不就是创建新的页面元素。下面的4种优化方案覆盖了修改和创建DOM节点两种方式，帮助你减少触发浏览器重解析的次数。

方案一：通过CSS类名切换来修改DOM

这个方案让我们可以一次性修改一个元素和它的子元素的多个样式属性而只触发一次重解析。

需求：

（emu注：原文作者写到这里的时候脑子显然短路了一下，把后面的Out-of-the-flow DOM Manipulation模式要解决的问题给摆到这里来了，不过从示范代码中很容易明白作者真正想描述的问题，因此emu就不照翻原文了）

我们现在需要写一个函数来修改一个超链接的几个样式规则。要实现很简单，把这几个规则对应的属性逐一改了就好了。但是带来的问题是，每修改一个样式属性，都会导致一次页面的重解析。

view plaincopy to clipboardprint?
function selectAnchor(element) {  
  element.style.fontWeight = 'bold';  
  element.style.textDecoration = 'none';  
  element.style.color = '#000';  
} 
function selectAnchor(element) {
  element.style.fontWeight = 'bold';
  element.style.textDecoration = 'none';
  element.style.color = '#000';
}

解决方案

要解决这个问题，我们可以先创建一个样式名，并且把要修改的样式规则都放到这个类名上，然后我们给超链接添加上这个新类名，就可以实现添加几个样式规则而只触发一次重解析了。这个模式还有个好处是也实现了表现和逻辑相分离。

view plaincopy to clipboardprint?
.selectedAnchor {  
  font-weight: bold;  
  text-decoration: none;  
  color: #000;  
}  
 
function selectAnchor(element) {  
  element.className = 'selectedAnchor';  
} 
.selectedAnchor {
  font-weight: bold;
  text-decoration: none;
  color: #000;
}

function selectAnchor(element) {
  element.className = 'selectedAnchor';
}

 方案二：在非渲染区修改DOM

（emu注：作者在这里再次脑子短路，把DocumentFragment DOM Generation模式的介绍提前到这里来了，emu只好再次发挥一下）
上一个方案解决的是修改一个超链接的问题，当一次需要对很多个超链接进行相同修改的时候，这个方案就可以大显身手了。

需求

需求是这样的，我们要写一个函数来修改一个指定元素的子元素中所有的超链接的样式名（className）属性。要实现很简单，我们可以通过遍历每个超链接并且修改它们的样式名来完成任务。但是带来的问题就是，每修改一个超链接都会导致一次重解析。

view plaincopy to clipboardprint?
function updateAllAnchors(element, anchorClass) {  
  var anchors = element.getElementsByTagName('a');  
  for (var i = 0, length = anchors.length; i < length; i ++) {  
    anchors[i].className = anchorClass;  
  }  
} 
function updateAllAnchors(element, anchorClass) {
  var anchors = element.getElementsByTagName('a');
  for (var i = 0, length = anchors.length; i < length; i ++) {
    anchors[i].className = anchorClass;
  }
}
 

解决方案

要解决这个问题，我们可以把被修改的指定元素从DOM里面移除，再修改所有的超链接，然后在把这个元素插入回到它原来的位置上。为了完成这个复杂的操作，我们可以先写一个可重用的函数，它不但移除了这个DOM节点，还返回了一个把元素插回到原来的位置的函数。

view plaincopy to clipboardprint?
/** 
 * Remove an element and provide a function that inserts it into its original position 
 * @param element {Element} The element to be temporarily removed 
 * @return {Function} A function that inserts the element into its original position 
 **/ 
function removeToInsertLater(element) {  
  var parentNode = element.parentNode;  
  var nextSibling = element.nextSibling;  
  parentNode.removeChild(element);  
  return function() {  
    if (nextSibling) {  
      parentNode.insertBefore(element, nextSibling);  
    } else {  
      parentNode.appendChild(element);  
    }  
  };  
} 
/**
 * Remove an element and provide a function that inserts it into its original position
 * @param element {Element} The element to be temporarily removed
 * @return {Function} A function that inserts the element into its original position
 **/
function removeToInsertLater(element) {
  var parentNode = element.parentNode;
  var nextSibling = element.nextSibling;
  parentNode.removeChild(element);
  return function() {
    if (nextSibling) {
      parentNode.insertBefore(element, nextSibling);
    } else {
      parentNode.appendChild(element);
    }
  };
}

有了上面这个函数，现在我们就可以在一个不需要解析渲染的元素上面修改那些超链接了。这样只在移除和插入元素的时候各触发一次重解析。

view plaincopy to clipboardprint?
function updateAllAnchors(element, anchorClass) {  
  var insertFunction = removeToInsertLater(element);  
  var anchors = element.getElementsByTagName('a');  
  for (var i = 0, length = anchors.length; i < length; i ++) {  
    anchors[i].className = anchorClass;  
  }  
  insertFunction();  
} 
function updateAllAnchors(element, anchorClass) {
  var insertFunction = removeToInsertLater(element);
  var anchors = element.getElementsByTagName('a');
  for (var i = 0, length = anchors.length; i < length; i ++) {
    anchors[i].className = anchorClass;
  }
  insertFunction();
}
 

方案三：一次性的DOM元素生成

这个方案让我们创建一个元素的过程只触发一次重解析。在创建完元素以后，先进行所有需要的修改，最后才把它插入到DOM里面去就可以了

需求

需求是这样的，实现一个函数，往一个指定的父元素上插入一个超链接元素。这个函数要同时可以设置这个超链接的显示文字和样式类。我们可以这样做：创建元素，插入到DOM里面，然后设置相应的属性。这就要触发3次重解析。

view plaincopy to clipboardprint?
function addAnchor(parentElement, anchorText, anchorClass) {  
  var element = document.createElement('a');  
  parentElement.appendChild(element);  
  element.innerHTML = anchorText;  
  element.className = anchorClass;  
} 
function addAnchor(parentElement, anchorText, anchorClass) {
  var element = document.createElement('a');
  parentElement.appendChild(element);
  element.innerHTML = anchorText;
  element.className = anchorClass;
}
 

解决方案

很简单，我们只要把插入元素这个操作放到最后做，就可以只进行一次重解析了。

view plaincopy to clipboardprint?
function addAnchor(parentElement, anchorText, anchorClass) {  
  var element = document.createElement('a');  
  element.innerHTML = anchorText;  
  element.className = anchorClass;  
  parentElement.appendChild(element);  
} 
function addAnchor(parentElement, anchorText, anchorClass) {
  var element = document.createElement('a');
  element.innerHTML = anchorText;
  element.className = anchorClass;
  parentElement.appendChild(element);
}

不过，要是我们想要插入很多个超链接到一个元素里面的话，那么这个做法还是有问题：每插入一个超链接还是要触发一次重解析。下一个方案可以解决这个问题。

方案四：通过文档片段对象（DocumentFragment）创建一组元素

这个方案允许我们创建并插入很多个元素而只触发一次重解析。要实现这点需要用到所谓的文档片段对象（DocumentFragment）。我们先在DOM之外创建一个文档片段对象（这样它也就不需要解析和渲染），然后我们在文档片段对象中创建很多个元素，最后我们把这个文档片段对象中所有的元素一次性放到DOM里面去，只触发一次重解析。

需求

我们要写一个函数，往一个指定的元素上面增加10个超链接。如果我们简单的直接插入10个超链接到元素上面，就会触发10次重解析。

view plaincopy to clipboardprint?
function addAnchors(element) {  
  var anchor;  
  for (var i = 0; i < 10; i ++) {  
    anchor = document.createElement('a');  
    anchor.innerHTML = 'test';  
    element.appendChild(anchor);  
  }  
} 
function addAnchors(element) {
  var anchor;
  for (var i = 0; i < 10; i ++) {
    anchor = document.createElement('a');
    anchor.innerHTML = 'test';
    element.appendChild(anchor);
  }
}

解决方案

要解决这个问题，我们要先创建一个文档片段对象，然后把每个新创建的超链接都插入到它里面去。当我们把文档片段对象用appendChild命令插入到指定的节点时，这个文档片段对象的所有子节点就一起被插入到指定的元素里面，而且只需要触发一次重解析。

view plaincopy to clipboardprint?
function addAnchors(element) {  
  var anchor, fragment = document.createDocumentFragment();  
  for (var i = 0; i < 10; i ++) {  
    anchor = document.createElement('a');  
    anchor.innerHTML = 'test';  
    fragment.appendChild(anchor);  
  }  
  element.appendChild(fragment);  
} 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/emu/archive/2010/03/01/5334583.aspx

2007 年 8 月 31 日

很多应用譬如监控、即时通信、即时报价系统都需要将后台发生的变化实时传送到客户端而无须客户端不停地刷新、发送请求。本文首先介绍、比较了常用的“服务器推”方案，着重介绍了 Comet － 使用 HTTP 长连接、无须浏览器安装插件的两种“服务器推”方案：基于 AJAX 的长轮询方式；基于 iframe 及 htmlfile 的流方式。最后分析了开发 Comet 应用需要注意的一些问题，以及如何借助开源的 Comet 框架－pushlet 构建自己的“服务器推”应用。
“服务器推”技术的应用

 请访问 Ajax 技术资源中心，这是有关 Ajax 编程模型信息的一站式中心，包括很多文档、教程、论坛、blog、wiki 和新闻。任何 Ajax 的新信息都能在这里找到。 
   订阅 Ajax 相关文章和教程的 RSS 提要
 

 
 
传统模式的 Web 系统以客户端发出请求、服务器端响应的方式工作。这种方式并不能满足很多现实应用的需求，譬如：

监控系统：后台硬件热插拔、LED、温度、电压发生变化；
即时通信系统：其它用户登录、发送信息；
即时报价系统：后台数据库内容发生变化；
这些应用都需要服务器能实时地将更新的信息传送到客户端，而无须客户端发出请求。“服务器推”技术在现实应用中有一些解决方案，本文将这些解决方案分为两类：一类需要在浏览器端安装插件，基于套接口传送信息，或是使用 RMI、CORBA 进行远程调用；而另一类则无须浏览器安装任何插件、基于 HTTP 长连接。

将“服务器推”应用在 Web 程序中，首先考虑的是如何在功能有限的浏览器端接收、处理信息：

客户端如何接收、处理信息，是否需要使用套接口或是使用远程调用。客户端呈现给用户的是 HTML 页面还是 Java applet 或 Flash 窗口。如果使用套接口和远程调用，怎么和 JavaScript 结合修改 HTML 的显示。
客户与服务器端通信的信息格式，采取怎样的出错处理机制。
客户端是否需要支持不同类型的浏览器如 IE、Firefox，是否需要同时支持 Windows 和 Linux 平台。
 
  回页首
 
基于客户端套接口的“服务器推”技术

Flash XMLSocket

如果 Web 应用的用户接受应用只有在安装了 Flash 播放器才能正常运行， 那么使用 Flash 的 XMLSocket 也是一个可行的方案。

这种方案实现的基础是：

Flash 提供了 XMLSocket 类。
JavaScript 和 Flash 的紧密结合：在 JavaScript 可以直接调用 Flash 程序提供的接口。
具体实现方法：在 HTML 页面中内嵌入一个使用了 XMLSocket 类的 Flash 程序。JavaScript 通过调用此 Flash 程序提供的套接口接口与服务器端的套接口进行通信。JavaScript 在收到服务器端以 XML 格式传送的信息后可以很容易地控制 HTML 页面的内容显示。

关于如何去构建充当了 JavaScript 与 Flash XMLSocket 桥梁的 Flash 程序，以及如何在 JavaScript 里调用 Flash 提供的接口，我们可以参考 AFLAX（Asynchronous Flash and XML）项目提供的 Socket Demo 以及 SocketJS（请参见 参考资源）。

Javascript 与 Flash 的紧密结合，极大增强了客户端的处理能力。从 Flash 播放器 V7.0.19 开始，已经取消了 XMLSocket 的端口必须大于 1023 的限制。Linux 平台也支持 Flash XMLSocket 方案。但此方案的缺点在于：

客户端必须安装 Flash 播放器；
因为 XMLSocket 没有 HTTP 隧道功能，XMLSocket 类不能自动穿过防火墙；
因为是使用套接口，需要设置一个通信端口，防火墙、代理服务器也可能对非 HTTP 通道端口进行限制；
不过这种方案在一些网络聊天室，网络互动游戏中已得到广泛使用。

Java Applet 套接口

在客户端使用 Java Applet，通过 java.net.Socket 或 java.net.DatagramSocket 或 java.net.MulticastSocket 建立与服务器端的套接口连接，从而实现“服务器推”。

这种方案最大的不足在于 Java applet 在收到服务器端返回的信息后，无法通过 JavaScript 去更新 HTML 页面的内容。

 
  回页首
 
基于 HTTP 长连接的“服务器推”技术

Comet 简介

浏览器作为 Web 应用的前台，自身的处理功能比较有限。浏览器的发展需要客户端升级软件，同时由于客户端浏览器软件的多样性，在某种意义上，也影响了浏览器新技术的推广。在 Web 应用中，浏览器的主要工作是发送请求、解析服务器返回的信息以不同的风格显示。AJAX 是浏览器技术发展的成果，通过在浏览器端发送异步请求，提高了单用户操作的响应性。但 Web 本质上是一个多用户的系统，对任何用户来说，可以认为服务器是另外一个用户。现有 AJAX 技术的发展并不能解决在一个多用户的 Web 应用中，将更新的信息实时传送给客户端，从而用户可能在“过时”的信息下进行操作。而 AJAX 的应用又使后台数据更新更加频繁成为可能。

图 1. 传统的 Web 应用模型与基于 AJAX 的模型之比较 
“服务器推”是一种很早就存在的技术，以前在实现上主要是通过客户端的套接口，或是服务器端的远程调用。因为浏览器技术的发展比较缓慢，没有为“服务器推”的实现提供很好的支持，在纯浏览器的应用中很难有一个完善的方案去实现“服务器推”并用于商业程序。最近几年，因为 AJAX 技术的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 组件中可以解决 IE 的加载显示问题，一些受欢迎的应用如 meebo，gmail+gtalk 在实现中使用了这些新技术；同时“服务器推”在现实应用中确实存在很多需求。因为这些原因，基于纯浏览器的“服务器推”技术开始受到较多关注，Alex Russell（Dojo Toolkit 的项目 Lead）称这种基于 HTTP 长连接、无须在浏览器端安装插件的“服务器推”技术为“Comet”。目前已经出现了一些成熟的 Comet 应用以及各种开源框架；一些 Web 服务器如 Jetty 也在为支持大量并发的长连接进行了很多改进。关于 Comet 技术最新的发展状况请参考关于 Comet 的 wiki。

下面将介绍两种 Comet 应用的实现模型。

基于 AJAX 的长轮询（long-polling）方式

如 图 1 所示，AJAX 的出现使得 JavaScript 可以调用 XMLHttpRequest 对象发出 HTTP 请求，JavaScript 响应处理函数根据服务器返回的信息对 HTML 页面的显示进行更新。使用 AJAX 实现“服务器推”与传统的 AJAX 应用不同之处在于：

服务器端会阻塞请求直到有数据传递或超时才返回。
客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。
当客户端处理接收的数据、重新建立连接时，服务器端可能有新的数据到达；这些信息会被服务器端保存直到客户端重新建立连接，客户端会一次把当前服务器端所有的信息取回。
图 2. 基于长轮询的服务器推模型 
一些应用及示例如 “Meebo”, “Pushlet Chat” 都采用了这种长轮询的方式。相对于“轮询”（poll），这种长轮询方式也可以称为“拉”（pull）。因为这种方案基于 AJAX，具有以下一些优点：请求异步发出；无须安装插件；IE、Mozilla FireFox 都支持 AJAX。

在这种长轮询方式下，客户端是在 XMLHttpRequest 的 readystate 为 4（即数据传输结束）时调用回调函数，进行信息处理。当 readystate 为 4 时，数据传输结束，连接已经关闭。Mozilla Firefox 提供了对 Streaming AJAX 的支持， 即 readystate 为 3 时（数据仍在传输中），客户端可以读取数据，从而无须关闭连接，就能读取处理服务器端返回的信息。IE 在 readystate 为 3 时，不能读取服务器返回的数据，目前 IE 不支持基于 Streaming AJAX。

基于 Iframe 及 htmlfile 的流（streaming）方式

iframe 是很早就存在的一种 HTML 标记， 通过在 HTML 页面里嵌入一个隐蔵帧，然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。

图 3. 基于流方式的服务器推模型 
上节提到的 AJAX 方案是在 JavaScript 里处理 XMLHttpRequest 从服务器取回的数据，然后 Javascript 可以很方便的去控制 HTML 页面的显示。同样的思路用在 iframe 方案的客户端，iframe 服务器端并不返回直接显示在页面的数据，而是返回对客户端 Javascript 函数的调用，如“<script type="text/javascript">js_func(“data from server ”)</script>”。服务器端将返回的数据作为客户端 JavaScript 函数的参数传递；客户端浏览器的 Javascript 引擎在收到服务器返回的 JavaScript 调用时就会去执行代码。

从 图 3 可以看到，每次数据传送不会关闭连接，连接只会在通信出现错误时，或是连接重建时关闭（一些防火墙常被设置为丢弃过长的连接， 服务器端可以设置一个超时时间， 超时后通知客户端重新建立连接，并关闭原来的连接）。

使用 iframe 请求一个长连接有一个很明显的不足之处：IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成，而且 IE 上方的图标会不停的转动，表示加载正在进行。Google 的天才们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题，并将这种方法用到了 gmail+gtalk 产品中。Alex Russell 在 “What else is burried down in the depth's of Google's amazing JavaScript?”文章中介绍了这种方法。Zeitoun 网站提供的 comet-iframe.tar.gz，封装了一个基于 iframe 和 htmlfile 的 JavaScript comet 对象，支持 IE、Mozilla Firefox 浏览器，可以作为参考。（请参见 参考资源）

 
  回页首
 
使用 Comet 模型开发自己的应用

上面介绍了两种基于 HTTP 长连接的“服务器推”架构，更多描述了客户端处理长连接的技术。对于一个实际的应用而言，系统的稳定性和性能是非常重要的。将 HTTP 长连接用于实际应用，很多细节需要考虑。

不要在同一客户端同时使用超过两个的 HTTP 长连接

我们使用 IE 下载文件时会有这样的体验，从同一个 Web 服务器下载文件，最多只能有两个文件同时被下载。第三个文件的下载会被阻塞，直到前面下载的文件下载完毕。这是因为 HTTP 1.1 规范中规定，客户端不应该与服务器端建立超过两个的 HTTP 连接， 新的连接会被阻塞。而 IE 在实现中严格遵守了这种规定。

HTTP 1.1 对两个长连接的限制，会对使用了长连接的 Web 应用带来如下现象：在客户端如果打开超过两个的 IE 窗口去访问同一个使用了长连接的 Web 服务器，第三个 IE 窗口的 HTTP 请求被前两个窗口的长连接阻塞。

所以在开发长连接的应用时， 必须注意在使用了多个 frame 的页面中，不要为每个 frame 的页面都建立一个 HTTP 长连接，这样会阻塞其它的 HTTP 请求，在设计上考虑让多个 frame 的更新共用一个长连接。

服务器端的性能和可扩展性

一般 Web 服务器会为每个连接创建一个线程，如果在大型的商业应用中使用 Comet，服务器端需要维护大量并发的长连接。在这种应用背景下，服务器端需要考虑负载均衡和集群技术；或是在服务器端为长连接作一些改进。

应用和技术的发展总是带来新的需求，从而推动新技术的发展。HTTP 1.1 与 1.0 规范有一个很大的不同：1.0 规范下服务器在处理完每个 Get/Post 请求后会关闭套接口连接； 而 1.1 规范下服务器会保持这个连接，在处理两个请求的间隔时间里，这个连接处于空闲状态。 Java 1.4 引入了支持异步 IO 的 java.nio 包。当连接处于空闲时，为这个连接分配的线程资源会返还到线程池，可以供新的连接使用；当原来处于空闲的连接的客户发出新的请求，会从线程池里分配一个线程资源处理这个请求。 这种技术在连接处于空闲的机率较高、并发连接数目很多的场景下对于降低服务器的资源负载非常有效。

但是 AJAX 的应用使请求的出现变得频繁，而 Comet 则会长时间占用一个连接，上述的服务器模型在新的应用背景下会变得非常低效，线程池里有限的线程数甚至可能会阻塞新的连接。Jetty 6 Web 服务器针对 AJAX、Comet 应用的特点进行了很多创新的改进，请参考文章“AJAX，Comet and Jetty”（请参见 参考资源）。

控制信息与数据信息使用不同的 HTTP 连接

使用长连接时，存在一个很常见的场景：客户端网页需要关闭，而服务器端还处在读取数据的堵塞状态，客户端需要及时通知服务器端关闭数据连接。服务器在收到关闭请求后首先要从读取数据的阻塞状态唤醒，然后释放为这个客户端分配的资源，再关闭连接。

所以在设计上，我们需要使客户端的控制请求和数据请求使用不同的 HTTP 连接，才能使控制请求不会被阻塞。

在实现上，如果是基于 iframe 流方式的长连接，客户端页面需要使用两个 iframe，一个是控制帧，用于往服务器端发送控制请求，控制请求能很快收到响应，不会被堵塞；一个是显示帧，用于往服务器端发送长连接请求。如果是基于 AJAX 的长轮询方式，客户端可以异步地发出一个 XMLHttpRequest 请求，通知服务器端关闭数据连接。

在客户和服务器之间保持“心跳”信息

在浏览器与服务器之间维持一个长连接会为通信带来一些不确定性：因为数据传输是随机的，客户端不知道何时服务器才有数据传送。服务器端需要确保当客户端不再工作时，释放为这个客户端分配的资源，防止内存泄漏。因此需要一种机制使双方知道大家都在正常运行。在实现上：

服务器端在阻塞读时会设置一个时限，超时后阻塞读调用会返回，同时发给客户端没有新数据到达的心跳信息。此时如果客户端已经关闭，服务器往通道写数据会出现异常，服务器端就会及时释放为这个客户端分配的资源。
如果客户端使用的是基于 AJAX 的长轮询方式；服务器端返回数据、关闭连接后，经过某个时限没有收到客户端的再次请求，会认为客户端不能正常工作，会释放为这个客户端分配、维护的资源。
当服务器处理信息出现异常情况，需要发送错误信息通知客户端，同时释放资源、关闭连接。
Pushlet - 开源 Comet 框架

Pushlet 是一个开源的 Comet 框架，在设计上有很多值得借鉴的地方，对于开发轻量级的 Comet 应用很有参考价值。

观察者模型

Pushlet 使用了观察者模型：客户端发送请求，订阅感兴趣的事件；服务器端为每个客户端分配一个会话 ID 作为标记，事件源会把新产生的事件以多播的方式发送到订阅者的事件队列里。

客户端 JavaScript 库

pushlet 提供了基于 AJAX 的 JavaScript 库文件用于实现长轮询方式的“服务器推”；还提供了基于 iframe 的 JavaScript 库文件用于实现流方式的“服务器推”。

JavaScript 库做了很多封装工作：

定义客户端的通信状态：STATE_ERROR、STATE_ABORT、STATE_NULL、STATE_READY、STATE_JOINED、STATE_LISTENING；
保存服务器分配的会话 ID，在建立连接之后的每次请求中会附上会话 ID 表明身份；
提供了 join()、leave()、subscribe()、 unsubsribe()、listen() 等 API 供页面调用；
提供了处理响应的 JavaScript 函数接口 onData()、onEvent()…
网页可以很方便地使用这两个 JavaScript 库文件封装的 API 与服务器进行通信。

客户端与服务器端通信信息格式

pushlet 定义了一套客户与服务器通信的信息格式，使用 XML 格式。定义了客户端发送请求的类型：join、leave、subscribe、unsubscribe、listen、refresh；以及响应的事件类型：data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。

服务器端事件队列管理

pushlet 在服务器端使用 Java Servlet 实现，其数据结构的设计框架仍可适用于 PHP、C 编写的后台客户端。

Pushlet 支持客户端自己选择使用流、拉（长轮询）、轮询方式。服务器端根据客户选择的方式在读取事件队列（fetchEvents）时进行不同的处理。“轮询”模式下 fetchEvents() 会马上返回。”流“和”拉“模式使用阻塞的方式读事件，如果超时，会发给客户端发送一个没有新信息收到的“heartbeat“事件，如果是“拉”模式，会把“heartbeat”与“refresh”事件一起传给客户端，通知客户端重新发出请求、建立连接。

客户服务器之间的会话管理

服务端在客户端发送 join 请求时，会为客户端分配一个会话 ID， 并传给客户端，然后客户端就通过此会话 ID 标明身份发出 subscribe 和 listen 请求。服务器端会为每个会话维护一个订阅的主题集合、事件队列。

服务器端的事件源会把新产生的事件以多播的方式发送到每个会话（即订阅者）的事件队列里。

 
  回页首
 
小结

本文介绍了如何在现有的技术基础上选择合适的方案开发一个“服务器推”的应用，最优的方案还是取决于应用需求的本身。相对于传统的 Web 应用， 目前开发 Comet 应用还是具有一定的挑战性。

“服务器推”存在广泛的应用需求，为了使 Comet 模型适用于大规模的商业应用，以及方便用户构建 Comet 应用，最近几年，无论是服务器还是浏览器都出现了很多新技术，同时也出现了很多开源的 Comet 框架、协议。需求推动技术的发展，相信 Comet 的应用会变得和 AJAX 一样普及。

参考资料

学习
developerWorks 文章“ 面向 Java 开发人员的 Ajax: 使用 Jetty 和 Direct Web Remoting 编写可扩展的 Comet 应用程序”：受异步服务器端事件驱动的 Ajax 应用程序实现较为困难，本文介绍了一种结合使用 Comet 模式和 Jetty 6 Continuations API 的解决方法。
“Comet: Low Latency Data for the Browser”：Alex Russell 是 Dojo Toolkit 的项目主管和 Dojo Foundation 的主席，他在这篇博客文章中提出了 Comet 这个术语。
“What else is burried down in the depth’s of Google’s amazing JavaScript?”（Alex Russel，2006 年 2 月）：Alex 在这篇文章里介绍了如何使用“htmlfile”ActiveX 控件解决 iframe 请求长连接时 IE 的加载显示问题。
Comet wiki：提供了很多开源 Comet 框架的链接。
Jetty：Jetty 是一种开源的基于标准的 Web 服务器，完全使用 Java 语言实现。
“Ajax, Comet and Jetty”（Greg Wilkins，Webtide，2006 年 1 月）：Wilkins 的这份白皮书讨论了扩展 Ajax 连接的 Jetty 架构方法。
Continuations：了解更多关于 Jetty 的 Continuations 特性的信息。
“pushlet”：开源 comet 框架，使用了观察者模型。浏览器端提供了基于 AJAX 和 iframe 的 JavaScript 库，服务器端使用 Java Servlet。
“How to implement COMET with PHP”：提供的 comet-iframe.tar.gz 使用 iframe/htmlfile 封装了一个 JavaScript comet 对象，支持 IE、Mozilla Firefox 浏览器。
“AFLAX”：Asynchronous Flash and XML，提供了强大的 Flash、Javascript 库和很多范例。
developerWorks Ajax 技术资源中心：能找到更多关于 Ajax 技术的文章和教程。
developerWorks Web 开发技术专区：提供了关于 Web 开发和架构方面的大量文章。
developerWorks Java 技术专区：提供了关于 Java 编程各个方面的数百篇文章。
浏览 技术书店，查阅有关本文所述主题以及其他技术主题的书籍。 

从8i到10g，Oracle不断进化自己的SQL Tuning智能，一些秘籍级的优化口诀已经失效。
   但我喜欢失效，不用记口诀，操个Toad for Oracle Xpert ，按照大方向舒舒服服的调优才是爱做的事情。

1.Excution Plan
     Excution Plan是最基本的调优概念，不管你的调优吹得如何天花乱堕，结果还是要由Excution plan来显示Oracle 最终用什么索引、按什么顺序连接各表，Full Table Scan还是Access by Rowid Index，瓶颈在什么地方。如果没有它的指导，一切调优都是蒙的。

2.Toad for Oracle Xpert
    用它来调优在真的好舒服。Quest 吞并了Lecco后，将它整合到了Toad 的SQL Tunning里面：最清晰的执行计划显示，自动生成N条等价SQL、给出优化建议，不同SQL执行计划的对比，还有实际执行的逻辑读、物理读数据等等一目了然。

3.索引
   大部分的性能问题其实都是索引应用的问题，Where子句、Order By、Group By 都要用到索引。
   一般开发人员认为将索引建全了就可以下班回家了，实则还有颇多的思量和陷阱。

3.1 索引列上不要进行计算
      这是最最普遍的失效陷阱，比如where trunc(order_date)=trunc(sysdate), i+2>4。索引失效的原因也简单，索引是针对原值建的二叉树，你将列值*3/4+2折腾一番后，原来的二叉树当然就用不上了。解决的方法:
　 1.　换成等价语法，比如trunc(order_date) 换成

where order_date>trunc(sysdate)-1 and order_date<trunc(sysdate)+1　 2.    特别为计算建立函数索引

create index Ｉ_XXXX on shop_order(trunc(order_date))    3.    将计算从等号左边移到右边
　这是针对某些无心之失的纠正，把a*2>4　改为a>4/2；把TO_CHAR(zip) = '94002' 改为zip = TO_NUMBER('94002');

3.2 CBO与索引选择性
     建了索引也不一定会被Oracle用的，就像个挑食的孩子。基于成本的优化器(CBO, Cost-Based Optimizer)，会先看看表的大小，还有索引的重复度，再决定用还是不用。表中有100 条记录而其中有80 个不重复的索引键值. 这个索引的选择性就是80/100 = 0.8，留意Toad里显示索引的Selective和Cardinailty。实在不听话时，就要用hints来调教。
     另外，where语句存在多条索引可用时，只会选择其中一条。所以索引也不是越多越好：）

3.3 索引重建
     传说中数据更新频繁导致有20%的碎片时，Oracle就会放弃这个索引。宁可信其有之下，应该时常alter index <INDEXNAME> rebuild一下。

3.4 其他要注意的地方
      不要使用Not，如goods_no != 2，要改为

where goods_no>2 or goods_no<2      不要使用is null , 如WHERE DEPT_CODE IS NOT NULL 要改为

WHERE DEPT_CODE >=0;3.5 select 的列如果全是索引列时
   又如果没有where 条件，或者where条件全部是索引列时，Oracle 将直接从索引里获取数据而不去读真实的数据表，这样子理论上会快很多，比如

select order_no,order_time from shop_order where shop_no=4当order_no,order_time,shop_no 这三列全为索引列时，你将看到一个和平时完全不同的执行计划。

3.6 位图索引
     传说中当数据值较少，比如某些表示分类、状态的列，应该建位图索引而不是普通的二叉树索引，否则效率低下。不过看执行计划，这些位图索引鲜有被Oracle临幸的。
 

4.减少查询往返和查询的表
这也是很简单的大道理，程序与Oracle交互的成本极高，所以一个查询能完成的不要分开两次查，如果一个循环执行１万条查询的，怎么都快不到哪里去了。

4.1 封装PL/SQL存储过程
　 最高级的做法是把循环的操作封装到PL/SQL写的存储过程里，因为存储过程都在服务端执行，所以没有数据往返的消耗。

4.2 封装PL/SQL内部函数
  有机会，将一些查询封装到函数里，而在普通SQL里使用这些函数，同样是很有效的优化。

4.3 Decode/Case
　 但存储过程也麻烦，所以有case/decode把几条条件基本相同的重复查询合并为一条的用法：

SELECT
 COUNT(CASE WHEN price < 13 THEN 1 ELSE null END) low,
 COUNT(CASE WHEN price BETWEEN 13 AND 15 THEN 1 ELSE null END) med,
 COUNT(CASE WHEN price > 15 THEN 1 ELSE null END) high
FROM products;4.4 一种Where/Update语法

SELECT TAB_NAME　FROM TABLES
WHERE (TAB_NAME,DB_VER) = （( SELECT TAB_NAME,DB_VER)
FROM TAB_COLUMNS WHERE VERSION = 604)

UPDATE EMP
SET (EMP_CAT, SAL_RANGE)
= (SELECT MAX(CATEGORY)FROM EMP_CATEGORIES)
5.其他优化
5.1RowID和ROWNUM
     连Hibernate 新版也支持ROWID了，证明它非常有用。比如号称删除重复数据的最快写法：

DELETE FROM EMP E
WHERE E.ROWID > (SELECT MIN(X.ROWID)
FROM EMP X
WHERE X.EMP_NO = E.EMP_NO);6.终极秘技 - Hints
   这是Oracle DBA的玩具，也是终极武器，比如Oracle在CBO,RBO中所做的选择总不合自己心水时，可以用它来强力调教一下Oracle，结果经常让人喜出望外。
   如果开发人员没那么多时间来专门学习它，可以依靠Toad SQL opmitzer 来自动生成这些提示，然后对比一下各种提示的实际效果。不过随着10g智能的进化，hints的惊喜少了。

7. 找出要优化的Top SQL
    磨了这么久的枪，如果找不到敌人是件郁闷的事情。
    幸亏10g这方面做得非常好。进入Web管理界面，就能看到当前或者任意一天的SQL列表，按性能排序。
    有了它，SQL Trace和TKPROF都可以不用了。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/calvinxiu/archive/2005/11/15/529756.aspx

网管技巧：无法远程桌面连接解决方法