fangdeng / battleship Goto Github PK

防止影响线上应用的访问性能，金刚狼需要有访问连接超时及设置功能

大家可能都有很多疑问，为什么我们不用我们习惯的开发方式，建一个svn仓库，大家像平常开发需求那样开发？为什么我们要使用 github，而不是google code？为什么我们要麻烦地分成公共仓库和私人仓库？还要发个 pull request 让管理员（就是我。。）来把私人仓库的改动同步回到公共仓库？

我不擅长描述清楚概念，但是我尽量把我的想法写出来。

1. 沟通！沟通！沟通！
   在我们这个项目中，沟通比平常的项目更重要。
   • 这是探索性的项目，我们清楚我们要实现的目标，但我们无法一开始就确定最终的结构，甚至产品的形态。这将是一个不断摸索、调整、前进的过程。沟通可以避免在错误的尝试上浪费时间，保证我们一致地往最终目标前进。
   • 大家现在分散在不同的团队，平常很难聚一起，不说找一个都有空的时间开一个会，光是每天有5分钟的时间开一个站立晨会都是非常奢侈的事情。每天能有多少的时间看旺旺群的讨论？旺旺群里面抛一个话题，可能要很久才有人回应，也很难有所有人都参与。
   • 我的想法是把沟通分散化、持久化。
2. 分散化
   不以会议来沟通，而是把沟通分散到开发环节中。具体来讲就是 pull request 机制。
   pull request 是什么？你觉得这个功能应该这样实现，抛出来，希望大家review一下、评价一下、一起讨论一下，就发一个 pull request。大家讨论后没有问题，就同步到公共仓库，就是这样一个过程。
   每个pull request 都是阶段性的一个成果。大家在这样的时机深入了解一下其他伙伴的代码。
   这样会议上的沟通就尽量分散到各个pull request中，每次不用花太多的时间，每天能抽半小时，效果就非常不错了。
3. 持久化
   旺旺群很方便，但是新进的成员无法看到之前的聊天记录。聊天记录中有价值的话题，混杂在日常的交流中，不能很好地沉淀。
   因此有必要对重要的讨论持久地保存下来。 pull request 的地方非常适合。
4. Git vs. SVN
   6个人同时开发一个项目，用svn不方便。直接在主干上开发？各种冲突。大家各自打分支开发，然后合并回主干？稍好，但遇到冲突的时候一不留神就会污染主干，一团糟。 Git在分支处理方面非常有优势，因此适合这个项目——小团队并行开发项目。
5. Github vs Google Code
   Google Code也支持git了。两者都能满足我们的功能需求，但是github更加注重在pull request中沟通

结论：

这样的开发方式也是我们第一次尝试，不过并不是业界的第一次，github自身就是这样的开发方式。希望汲取有益于我们的部分，让我们的开发更顺利

16日用ab对金刚狼进行了压力测试，并发2000总计6000W请求，可惜ab蹦了没拿到结果，但服务器在承受6000W的请求没崩，这也算达到预期。后来做了1000并发+1000W请求的压力测试，其结果为：

This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.20.158.33 (be patient)

Server Software:
Server Hostname: 10.20.158.33
Server Port: 1337

Document Path: /?data=%7B%22taskId%22%3A%2220120329%22%2C%22browser%22%3A%7B%22name%22%3A%22IE%22%2C%22version%22%3A7%2C%22engine%22%3A%22%22%7D%2C%22os%22%3A%7B%22name%22%3A%22windows%22%2C%22version%22%3A7%7D%2C%22language%22%3A%22zh-cn%22%7D
Document Length: 0 bytes

Concurrency Level: 1000
Time taken for tests: 7700.73020 seconds
Complete requests: 10000000
Failed requests: 0
Write errors: 0
Total transferred: 640000000 bytes
HTML transferred: 0 bytes
Requests per second: 1298.69 #/sec
Time per request: 770.007 ms
Time per request: 0.770 [ms](mean, across all concurrent requests)
Transfer rate: 81.17 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 3.6 0 3109
Processing: 46 768 81.4 749 5265
Waiting: 0 563 144.8 562 4874
Total: 46 769 81.5 749 5265

Percentage of the requests served within a certain time (ms)
50% 749
66% 765
75% 781
80% 781
90% 796
95% 828
98% 890
99% 968
100% 5265 (longest request)

从结果看，单位请求处理时间在0.7ms左右，还算不错。