对于上线优化这个事情，个人来说更加倾向于使用一些快速的调优模式首先来解决 80% 的问题。感觉上这篇“Battle ready Nginx – an optimization guide”讲得还是很到位了。所以随手翻译了，分享给大家。
———— 翻译分隔线 ————
作者：Zachary Orr
大多数关于 Nginx 的指南只告诉你那最基本的部分：apt-get 一个包，修改这里和那里的某些行，然后就得到了一个 web 服务器！而在大多数情况下，一个常见的 nginx 安装也能为你的网站提供良好的服务。然而如果你的确想进一步压榨 nginx 的性能，那么就必须走得更远一些。在这个指南中，我将会解释通过调整 nginx 中的哪些设置可以得到更好的性能，来应对大量客户端请求。同时要注意，这不是完整的调优指南。只是对一些可以调整来改进性能的设置的简单概述。请务必具体情况具体对待。
理解竞态对于并发编程来说很重要，如果能通过某种手段来了解程序中存在的竞态，以便进一步的调整避免竞态，也是非常有效的优化手段。Go 1.1 的工具链引入了竞态检测器可以检测并展示程序中存在的竞态情况。Go 团队撰写了博文详细介绍了这一工具的原理和使用。原文在此《Introducing the Go Race Detector》。
————翻译分隔线————
Dmitry Vyukov 和 Andrew Gerrand
竞态条件几乎是最为隐蔽和难以发现的程序错误。它们通常会导致诡异且无法解释的错误，尤其是在代码已经部署到生产环境很长时间之后。虽然 Go 的并发机制使得编写清晰的并发代码变得容易，但是它们无法避免竞态条件。认真、勤快的测试是必须的。而工具可以给予帮助。
我们很高兴的宣布 Go 1.1 包含了竞态检测器，一个用于发现 Go 代码中的竞态条件的新工具。它当前在 64 位 x86 处理器的 Linux、MacOS 和 64 位 x86 处理器的 Windows 系统中可用。 (more…)
原文在此：http://en.munknex.net/2011/12/golang-goroutines-performance.html
————————–翻译分割线————————–
在这篇文章里，我将尝试评估 goroutine 的性能。goroutine 是类似轻量级线程的东西。为了提供原生的多任务，它（协同 channel 一起）被内建于Go中。
文档告诉我们：
它实际上是在同一个地址空间里创建成百上千个 goroutine。
因此，这个文章的重点就是测试并明确在如此巨大的并发运行函数的情况下所能承受的性能压力上限。
(more…)
原文在此：http://ziutek.github.com/web_bench/
由于是早上看到 鱼哥，在推上的推荐，我实在忍不住……这是中午的草率之举，所以 鱼哥 对本文的翻译负全责。
PS：别说我工作状态不饱满，我在等丫的程序执行完……
————翻译分割线————
我通常使用 Python 来构建 Web 应用。一年前，在兴趣的驱使下，我开始学习 Go。 在此期间，我重写了一些原本由 C 开发的 CGI 应用，包括运行于 chroot 环境下的同 thttpd 服务器一起的应用。我开始寻找可以开发易于 chroot、且内置 Web 服务器的独立 Web 应用的工具。那时，我开始玩 web.go 框架、mustache.go 模板、Go 原生 http 包和 GoMySQL 数据库 API。我发现，有 http、mustache.go GoMySQL 包的 Go 可以是我用来工作的不错的工具组合。因此，我决定使用 Go 编写我的应用。
(more…)
没错，标题我没打错。这里不是最佳实践，而是最快实践。在服务器上线，巨大的压力导致相应缓慢的时候，最佳实践已经毫无意义。这个时候，目的只有一个：最快改善性能，给开发人员重新设计、调整应用留出一定的时间。
这里不是细腻的微调，而是最粗旷的拉升。用最简单（可快速实施），变更最少（尽量避免变更引入新的 bug 和问题）的方法迅速改善 mysql 的性能。所以我这里的最快实践，不一定是最好的，不一定是最有效的，但是一定是最快能看到性能改善的方法。 (more…)
没办法整理成长篇大论了，就写点只言片语吧。
起因看这里：http://www.javaeye.com/topic/305801?page=1
－－－－－－－－－－－－－－－－－
看了一遍，忍不住了，插句嘴～～
webgame 根本没有，也不需要什么大量实时数据要处理～～
例如类似部落战争的行军，这个其实早就根据所选兵种、指挥官、宝物等等生成了一个事件存放在事件队列中（可能是内存对象、可能是某种数据缓存更有可能是数据库的某条记录），然后服务器在那个事件事件到达的时候取出事件对象执行一下，得到一个结果，接着存起来。至于行军途中到哪个位置如何如何，那是给玩家想象的，服务器根本不管。总之，事件运算有三种方式：1。玩家请求时已经运算完成，到了特定时间通知玩家。2。事件执行时间运算完成，并通知玩家。3。在服务器空闲时，处理待处理的运算，到了特定时间通知玩家。
webgame， MMO 实时性不是首先考虑的。例如资源增长，如果服务器有 10W 激活用户，在同一时间增长资源是几乎不可能的。那就将一分钟划分60秒（废话），每秒开一个新线程来处理一部分用户（10W/60）的资源增长。资源增长基本上就是浮点数加减乘除，对于现在的 cpu 来说，并不是很高。何况服务器 N 个 cpu……
简单的说，webgame 不像 MMO 需要“随时”客户端跟服务器端通讯。更多情况，web 服务器通过某种方式从 game server 中获得一个当前游戏状态的快照返回到浏览器。并从浏览器接收数据，然后在一个可接受的，合理的时间内去修改 game server 的状态。请再次注意，again！这不是“实时”的！
最后再罗嗦一下，webgame 的 game server 更多情况下是一个 task server。它不需要去预测客户端行为，也不需要计算碰撞、寻找可行路径……
另外，我个人的体会，RPG 类型的 webgame 在运算负载上来说，远小于策略形的。并且通常只需要 3 台服务器配合：web server、task server、db server。
哦，还有，如果用 flash 的 socket 方式开发，不在上述范围内。当这种模式是个客户端能力稍差的 MMO 好了。