Web 性能是一个持续性的工作，即使是监控最完备的网站也会经常出问题，把性能退化甩给终端用户。真实用户检测是一项必不可少的工具，但还不够，因为对于每一个发布周期可能带入的性能退化，用户是最终的受害者。

YSlow 一直通过分析和建议相应的修补办法来帮助提高专业网站性能，但它是通过在产品的末端手动运行浏览器扩展的形式完成的。现在有了 NodeJS 和 PhantomJS 后 YSlow 如虎添翼，可以无缝插入持续集成流程中，在构建过程中反馈性能退化，保证了网站的最低性能基准，避免不必要地把不愉快的体验带给最终用户。除了通过YSlow 来避免性能退化，在 Twitter 我们通过自动化分支性能比较来努力保持和提高每一次新发布的性能，它能够给出精确的测量，避免产品中甚至是毫秒级的性能退化。

SPDY（读作 SPeeDY）是关于 Web 内容传送的应用层协议，专门针对最小化延迟需求而设计。它使网站更加高效地将内容传送到浏览器，采用了流复用、头部压缩以及服务器推送等手段。SPDY 目前得到了 Chrome 和 Firefox 的支持，而且可以部署的服务器包括 Apache、nginx、node.js 等平台。

在本议题中我首先概述没有 SPDY 的互联网状况。然后讨论 SPDY 如何解决了 HTTP/TCP 面临的问题。最后我会讨论你的网站采用 SPDY 协议的可行方案，以及展示一些具体网站实例。

“连续部署”对于更为传统的发布时间表来讲是一个巨大的背离。"代码一写好就更新到生产网站上”这样的想法听起来就很危险，尤其是在不了解为什么这么做、期望什么结果的情况下，这跟直接在生产服务器上改代码一样疯狂。然而，等你有了一定了解时这么做是有好处并且安全的。

我会谈到实现连续部署需要的一些文化、技术上的转变：

• 运维和开发之间的相互信任
• 健壮的部署系统
• 对产品中所发生的情况要了如指掌
• 开发人员对进入产品的代码要有同样的责任感

还会谈到采用连续部署我们体会到的益处：

• 在故障和发现 Bug 时极大地提高平均恢复时间的水平
• 更快速地开发新功能
• 更强的信心，代码在按我要的方式运行
• 简单、强大的 A/B 测试，从而作出更好的产品决策
• 工程组织中更好的沟通

主要阐述在 Android 上设计开发性能敏感程序需要考虑的策略和需要注意的编程技巧。包括编程时需要关注的会对应用性能产生影响的微小细节，如何更有效的使用Android UI Widget，如何高效地渲染以及如何正确地创建和使用 HTTP 连接。

LVS是章文嵩博士于1998年创建的优秀开源软件，经过14年大量访问考验，它还有可以改进的地方吗？作为中国最大的互联网公司之一，阿里巴巴集团在LVS项目上有深入的研究和很大的贡献；阿里巴巴集团已经在线上环境长时间应用LVS，并针对大规模万兆网络环境进行了深入的优化；阿里巴巴将与大家分享LVS上相关优化的成果，并且该成果已经开源在LVS官网上。

将以问题驱动的方式介绍阿里巴巴对LVS功能上的改进和性能上的优化；功能方面，LVS添加了FULLNAT/SYNPROXY等新特性；性能方面，从硬件配置到系统软件进行了多层次优化改进，并提出了cluster部署方案。

1. LVS问题
2. LVS功能-FULLNAT
3. LVS功能-SYNPROXY
4. LVS性能优化

讲述百万甚至千万级别同时在线IM系统的细节，主要涉及四个方面：

• 协议设计：各类型协议优劣分析；
• 架构设计：高可用，可扩展，负载均衡，消息如何不丢不重；
• 交互流程：登陆，加好友，发消息都发生了什么；
• 功能细节：群，文件传输，推送等功能的难点与实现。

一天191亿成交，近亿笔订单，要做哪些运维工作来保障系统的平稳运行？从以下几个方面为您讲述阿里技术保障团队是如何做到的。

• 有效的评估系统能力建设
• 全面的风险评估
• 预案管理
• 活动现场管理

你知道你的网站还能更快吗？你知道还有哪些措施能减少用户的延迟时间？PageSpeed Insights 就是能帮到你的正确工具，它分析页面的内容然后给出提高页面速度的建议。

我将会讨论 PageSpeed Insights 整套工具，展示如何使用它们来减少用户延迟时间。

也许你会发现 PageSpeed Insights 给出的一些建议涉及的手动操作很麻烦，别担心，我会介绍一个工具——mod_pagespeed。这个 Apache 模块能自动应用所有 Web 性能的最佳实践，而不要求你修改现有的内容和工作流。

而且，如果你不想装这个 Apache 模块，甚至还有 PageSpeed 服务提供。你只需将 Web 指向 PageSpeed 服务一切就大功告成了。

我会探讨各种不同的 PageSpeed 产品来帮您找出最适合你网站的方法。

用户产生的数据是个老问题。系统和网络监测、页面分析和应用状态信息形成了不断扩张的“数据山”。搜集和存储这些数据绝不是单一应用就能做到的，也不存在一点用户可以深入系统、调试、重现一些棘手的错误。分布式系统需要对生产系统有一个清晰的了解，并且能访问到实时数据，从而来解决状态相关的复杂问题，同时还不能对用户体验有任何影响。

我会解释这些问题（痛苦）以及我们是如何解决的。在生产中开发，把代码推向开发端。

Web 网站和应用正逐渐开始和前端服务器脱离，把这部分任务交给互联网边界上的服务器来完成。这个概念通常称之为“边界计算（Edge Computing）”，越来越成为当下热潮。内容缓存和请求路由通常都被推给边界处理。随着这种趋势的发展很显然我们需要在边界端引入更多的处理能力，以支持更多应用。其中被讨论最多的办法就是支持 ESI(Edge Side Include)。这是一种简单的标记语言，在边界端提供内容装配能力。

在 Yahoo! 我们广泛地在高流量媒体项目（比如News、Lifestyle、Entertainments）中使用 ESI。本议程中将和大家分享我们的经验。我将从内容装配的简单实例开始，让大家马上熟悉这种极为简单和微小的模板语言，一分钟学会。然后我会给出两三个例子来阐明我们如何创新地大规模使用 ESI(例如用 ESI 构建一个 CSS/JS 联合处理程序，例如自动在边界缓存页面的静态版本，在前端服务器不能给出动态版本的情况下把这个静态版本给出去)，并且向大家展示其巨大的潜力。我们还会和大家分享 HTTP 软件（比如 Apache Traffic Server 和 Varnish）对 ESI 支持的情况，以及供应商（比如 Akamai）的支持情况。最后我们会讨论 ESI 当前的局限性和不足之处，并希望重振大家对该规范的兴趣共同朝着 2.0 版本前进。

1. Comet介绍
2. Comet实现方式介绍
3. 各种实现方式优劣对比（从性能、浏览器兼容、用户体验几方面对比）
4. 实战：在网易邮箱中使用Comet的新旧方案对比
5. 总结：在不同条件和环境下该使用哪种方案

作为中国最大的 Java 技术应用方，针对淘宝应用需求的 Java 虚拟机（JVM)的优化定制是必要且收益巨大的。TaobaoJVM 是基于 OpenJDK VM 并根据淘宝业务、应用特点及开发者需求开发的稳定，高效且深度定制的 JVM 版本。是国内第一个优化、定制且开源的服务器版 Java 虚拟机。目前已经在淘宝、天猫上线，替换了 Oracle 官方Hotspot VM，在性能、功能上都初步体现了它的价值。本议题会结合淘宝 Java 应用在性能、功能等方面的实际需求，介绍 TaobaoJVM 在 JVM 层所进行的优 化、定制内容，实现方法以及实现细节。

Facebook有超过十亿月度活跃用户（Monthly Active User, MAU)，其中超过百分之六十的用户通过移动设备来访问Facebook的各种服务。在这个报告中，我们将探讨Facebook移动开发中的令人兴奋的巨大潜力和挑战，我们将对Facebook的安卓应用开发进行剖析，以此来讨论Facebook移动应用平台开发中的故事、机遇、挑战、技术和经验等。

1. node.js构建游戏服务器带来的可伸缩性优势
2. 高可扩展的游戏服务器运行架构介绍
3. 开源游戏服务器框架pomelo的介绍
4. 游戏性能优化：包括优化工具，压力测试工具，性能优化经验，解决的性能瓶颈和解决方案

微博计数器是新浪微博平台非常核心的基础组件之一, 目前拥有千级亿的微博计数, 每秒承载着数百万次的访问. 在这个数据规模下, 业界并没有非常成熟和通用的设计方案, 因此本主题希望以微博计数器为例, 介绍新浪微博平台架构在发展过程中遇到的各种挑战和我们的设计思路, 与各位同行一起探讨。

1. 微博计数器在微博中的重要性, 发展历史以及遇到的挑战!
2. 详细阐述新的微博计数服务的架构设计以及背后的思考过程。
3. 微博架构设计的原则和经验。

随着互联网个性化时代的来临，很多需要通过多角度多属性进行实时分析的需求应运而生，如想即时统计最近任意几天、指定省份、指定地市、指定性别、指定年龄、指定频道的用户情况；如想结合用户的省份、地市、年龄、性别、偏好、最近购买情况给用户即时推荐最热门的商品；如想统计出多个关键词组合在省份、地市、年龄、性别、偏好等条件下的分布情况；而这些多维度多属性统计会存在无法穷举和无法通过离线计算进行预算的问题，如果固化业务逻辑则无法应对互联网业务的快速变化，在高并发互联网应用中解决这类问题则面临更大的挑战。

Garuda 是一个针对海量数据进行任意维度的密集计算与检索的支持高并发低延时的在线数据应用系统。目前在淘宝主站、SNS、数据魔方、淘宝指数等产品中得到了广泛应用，给这些产品提供高并发的实时计算服务；当前集群数据量已超过300亿条，平均每个请求涉及到300万条以上记录的实时多维度计算，请求响应时间小于50ms，QPS 超过300。本次分享将就Garuda设计原理、应用场景、历史变迁进行详细介绍，也将会介绍结合Redis、HBase的一些过渡方案的快速实现原理。

随着搜狗近几年用户量的爆发式增长和多项新业务的频繁上线， 在机器、人员有限的条件下，如何更高效的应对近百亿的业务请求量，如何高效的管理PB级海量日志数据，如何轻松的运维上百个产品？ 本次演讲与大家一起分享下搜狗运维部在推动平台化运维方面的一些收获和体会，主要内容包括：

1. 构建百亿级高性能web前端服务中解决的问题和经验分享
2. 统一，高效，易用的日志收集，管理和分析平台介绍
3. 搜狗与开源：开源软件本地化过程中的一些定制化开发项目
4. 搜狗在自动化运维方面的工具集合介绍