Alice & Alex's TravelTravel, Lifestyle & Observation

As we’re coming to the end of this year, everyone starts to look towards the next one and there will no doubt be an upsurge of articles predicting the web trends of 2010 in the next days to come. However, in this article, we’ll be talking about what’s actuallydriving these trends now, and what they mean for the future of the internet.

1. CSS3, HTML5 and Fonts as a Service
2. Ways we browse the web
3. Social media
4. JavaScript
5. Software as a Service (SaaS)

read this: http://sixrevisions.com/web-development/five-technologies-that-will-keep-shaping-the-web-in-2010/

今年终于完成了风险管理这门课程前两周的练习，总算赶上一门课程的进度，当初学概率用英文还一知半解的东西，现在竟要用英文学习。好在现在所学的概率只是一些简单理论的应用，而计算则大部分由已经编好的程序完成。

在正式开始本文重点内容之前，先简单总结一下所学的内容。

本文导读：

1. 关于概率
2. 关于计划分析（Schedule analysis）
3. 想法：从概率的角度分析程序出错的可能性
4. 理论联系实际：应用构想
5. 附录:相关资料

关于概率：

1. 概率的基本概念：随机事件、样本空间、概率定义、随机变量
2. 贝叶斯法则（Bayes rule）
3. 概率分布：函数、期望值、中值、标准差、双期望值定理（Double Expectation）
4. 常用概率分布曲线：Normal、Exponential、Triangular、PERT Distribution
5. 概率分布的运算：Sum, Product, Maximum

关于计划分析（Schedule analysis）：

1. 网络图：起点、终点、活动、里程碑、不确定性、虚拟节点、顺序
2. 目的：为整个项目过程、部分活动或里程碑建立累计的概率分布函数；衡量项目中某个活动导致整个项目延迟的可能性；
3. Critical Path Method(CPM)：利用Most likely value找出网络中的关键路径（最长），但是此方法缺陷是只能用于处理确定的活动，无法处理过程中的不确定性因素。
4. Program Evaluation and Review Technique(PERT)：用于将不确定性因素考虑在内的关键路径上的衡量，但是此方法的缺陷在于，如果存在多条期望时间重叠的路径，此方法无法处理。
5. Successive Schedule Planning(SSP)：将项目过程中所有活动纳入分析范围，考虑到各个节点、路径的不确定因素，可以完整的分析和衡量整个项目过程消耗时间的方法，最终建立一个累积的概率分布曲线。
6. Monte Carlo Simulatoin：通过大量随机实验，获得数据绘制分布曲线，从曲线上读数。

这门课程头两张的内容比较抽象，练习也都是概念上的计算题。从这两周的课程中我认识到一点，从不确定性以及概率的角度看待工作活动似乎更加合理。倒不是说一定要用这些公式或模型去套用，只是因为工作中不确定性的因素太多，你要接受它们，并充分估计不确定性因素所带来的负面影响。

想法：从概率的角度分析程序出错的可能性

工作的时候，一直有个想法。想法的背景是这样的：因为几乎每个新写的程序都是独特的，相当大数目的程序从开发到传输的生命周期不超过40人时，甚至不超过10人时。在如此短促的开发过程中，几乎没有可能应用所谓的软件工程或质量保证什么的，因为那样会极大的增加成本。

我的想法是，能否用一种自动化的方法，衡量程序的质量或复杂程度？我曾经在工作中通过对程序文法分析获得程序中的IF、LOOP、CHECK、SUBROUTINE等代码块的数量，为每一种代码块设定一个参数，将各方面数据做累加，用于衡量程序的复杂度。当时遇到了一些问题，就是无法将各种代码块有效、合理的组合在一起，并且没能设定合理的参数。

应用构想

这个想法现在看来仍然值得继续尝试，在这两周学习的背景知识下，作出如下调整：

• 分析历史数据（变更、版本），获取一部分数量的样本数据，50~100个程序，其中包含各类以及小、中、大规模的程序，按如下方式记录，此表格中的缺陷概率(M)将作为特征代码缺陷概率的中值（MEAN），其中 缺陷概率= 缺陷次数/出现次数，缺陷比重=缺陷次数/缺陷总次数：

  特征代码	出现次数	缺陷次数	缺陷概率(M)	缺陷比重
  IF…ELSE…	150	9	6%	20.9%
  WHILE	50	2	4%	4.7%
  CHECK	15	4	26.6%	9.3%
  SELECT…	300	25	8.3%	58%
  DELETE…	40	3	7.5%	6.9%
  …
  TOTAL/AVG	555/111	43/8.6	10.48%	100%

• 假定我们有一个程序：Program A，其中包含各种特征代码，相关数据如下表所列：
  

  特征代码	正确概率	出现次数	正确概率的n次方，n=出现次数
  IF…ELSE…	94%	2	0.8836
  WHILE	96%	3	0.884736
  CHECK	73.4%	1	0.734
  SELECT…	91.7%	5	0.648405
  DELETE…	92.5%	4	0.732094
  		概率乘积	P(A)=27%（整个程序的正确概率）

  事实上，在本例中，我们将本程序分解为15个相互独立的随机事件，那么所有缺陷事件均不发生的概率就是每个事件正确概率的乘积。

• 根据工作需要，设定P(A)的临界值，如当P(A)<=40%时，需经过非程序员本人的质量测试方可传输。

这其中的参数（主要是缺陷概率）可通过对历史数据的观察获得初始值，并随项目进展更新，缺陷概率随开发人员水平不同而变化，随开发时间不同而变化，本构想尚未对其他参数进行设定，但增加相应参数则可以扩展模型的适用范围及准确度。

此工具在工作中的应用，可以自动、快速的分析程序结构，依据历史数据计算程序出错的概率，开发人员可直观判断一个程序的风险，并增加相应的质量保证活动。对于短周期、小规模开发、频繁变更的项目尤其有效。若能在应用的同时增加数据的收集，可用于矫正模型参数以及评估质量改进的效果。

目前，这还只是一个构想，写到这里，我想我又犯了一个错误：在写下这些构想之前，没有翻阅资料，也许这些想法早有人实现甚至有成熟的工具，也有可能这根本就是没有意义的胡言乱语，总之下次，我会在构想一件事之前，看看别人是怎么想的。

附录：一些相关资料

• 软件质量管理实践：软件缺陷预防、清除、管理实用方法 7.6 缺陷度量
• 软件代码缺陷分类及其应用

“3000万业务数据导入的性能调优始末” 这项工作开始于本周一，对即将在SAP R/3系统中导入3000w数据进行性能调优，最低目标是可以达到每天200w导入数据量，而事实上，我们舍弃了一小部分功能，从而达到了超过800w/天的导入能力。本文将向您讲述这段性能调优功能的始末。

首先我们简单说一下导入的数据，物料主数据的基础视图是先前已经创建好的，我们所要做的是扩展到所有的工厂下，因此调用BAPI: BAPI_MATERIAL_SAVEDATA，但是由于有一个视图plant stock不能通过BAPI创建，我们使用了BDC方法。

1. 问题的出现

问题出现于上周五，30w物料主数据，将被扩展到约95个工厂下，也就是说将会产生约3000w条工厂级物料数据，那么如何能保证每天200w导入能力的最低目标成为一个难题。

200w/天 ≈ 83333 / 小时 ≈ 1388 / 分钟 ≈ 23 / 秒 合 每条数据只有0.04秒的时间

而事实上，最初我接手时的程序在开发机仅能达到2.6秒/条的速度，那么很显然，2.6与0.04之间相差65倍，接近2个数量级，自然我们首先想到的就是并发，一般来讲，20进程并发，应可提升一个数量级的速度。但是我们仍然相差接近一个数量级。

2. 第一天

第一天我们做了很多无用功，但是这是后来证明的，在一开始，我们都很有信心。首先我们通过简单的观察程序和测试运行发现，有一个包含BDC过程的子程序占用了超过60%的运行时间，根据常理我们也都认可BDC速度远远低于BAPI，即使是简单的操作。因此我们把第一个重点放在了如何解决这段BDC。于是我们把第一天的全部时间都用在了如何将BDC那段功能用BAPI实现。

第一天我们三个人一直搞到晚上10点多，头晕脑胀也没能解决问题，这其间还遇到一些假象，但后来证实行不通，由于本文重点在于讲述性能优化，这段故事就不详细说了。但是结果并不理想，我们也没有达到预期的目标。

对于第一天来说，最漫长的已经过去，但最重要的还没有到来，之所以说第一天做了很多无用功，是因为第二天一大早的一个重大发现。

3. 第二天

在我们基本放弃解决BDC的问题后，我开始仔细的看程序，因为程序不是我写的，我并不是很熟悉。正当一筹莫展之际，我发现了第一个重大发现，在实现BDC功能的子程序中，居然有一条这样的语句：WAIT UP TO 2 SECONDS。这让人无法接受，后来证实，是先前一位经验不足的开发人员为了避免锁定的问题写上的，看到这里，你一定和我们当时想的一样，2.6-2 = 0.6秒，3600 / 0.6 * 24 = 14.4w，也就是说一个进程一天可以跑14.4w数据，20个进程并发就可以达到288w。

在去掉了WAIT UP TO 2 SECONDS后的第二天，我们的重点转向了并发情况下的性能测试，之所以要测试，是因为简单的将14.4 * 20计算是不合理的，因为并发将导致进程之间竞争资源，从而使得单个进程效率下降，但是下降多少，我们并不知道。我们的开发机是一台4C 8核的1.6 GHz的P520，测试数据如下：

• 1进程*100条数据 47s
• 4进程*100条数据 65s

从上面的数据可以看到，4进程并发，虽然单位实现效率上升约190%，但是单个进程效率下降近38.3%，这让我们很担心，40个进程并行的时候但个进程性能会下降多少？是否还能达到总效率提升的效果呢？由于开发机只设置了4个后台进程，因此只能测试到4进程并发，我们非常期待在生产机测试。

除了并发可能导致效率下降，还必须考虑由于一次导入的数据量增加，会否使程序的效率恶化，虽然在此时我们还没有预见到程序中有一个致命的问题，但是这种考虑显然帮了我们大忙。我们决定在第二天晚上，跑一个4w条数据的量，看看执行效率如何，该进程在这一天晚上午夜12点启动了，同时也希望能测试一下服务器负载较低时，数据导入的效率能否更好一些。

4. 第三天

一大早我们期望看到结果，然而等待我们的却是远远超出预期，而且还未结束的进程。这让我们不得不担心程序中存在随数据量增长以指数方式恶化的情况。

通过调试程序，我们发现程序中存在一段两重循环外加一个READ TABLE，也就是检索。正是这个两重循环导致这段逻辑成2次方指数恶化，而在此循环内部的READ TABLE命令，也将本已恶化的性能推向了崩溃的边缘。在一个GENERIC TABLE中做READ TABLE操作，平均命中率是一半，相当于半个循环。

虽然循环中基本都是ABAP命令，极少有数据库读取，但是数据量的增大仍然导致了不可接受的后果，让我们来简单计算一下：

• 100条数据*50个字段 = 500，这个500就是本段循环的基础值，两重循环将使内部的循环次数达到500*500 = 25w
• 4w条数据*50个字段 = 200w，两重循环将使内部的循环次数达到200w * 200w = 4亿
• 500条数据的READ TABLE的平均查询次数为250次
• 200w条数据的READ TABLE的平均查询次数则为100w次

从上面的数据不难看出，4w/100 = 400倍的数据量，而循环次数则提高了1600倍，read table的查询次数也提高了4000倍，仅read table一项的查询次数就比原来增加了640w倍，这就是三次方指数的恶化。

经过进一步的分析，我们认为，原计划4小时左右跑完的进程，即使是跑了9个小时，也还没有完成这一小段逻辑。而在整体运行过程中，这一小段逻辑，还占不到整个程序消耗时间的1/100。早先的测试都是重点在于功能，由于最大测试数据不超过20条，虽然比1条数据扩大了8000倍的运行时间，但由于绝对占比不到1/100，根本没能发现。

好在最后我们将这个问题解决了，将三重循环改为顺序处理，说到这里，很多次处理数据的时候，在效率方面，我都从大学时代的编译原理课程受益匪浅。

在解决了这个问题之后，程序的复杂度终于随数据量增大符合线性增长了，早上9点40解决了问题之后，我们启动了同一个4w数据的进程，结果在不到4个小时的时间顺利运行完，这一次测试，我们得到的数据是0.3s/条的导入速度。

这一天下午，生产机准备好了，我们将全部精力投入在在生产环境的测试上。由于生产系统的配置尚无法支持业务数据的导入，因此我们想到了一个办法，首先对数据库进行压力测试，测试方法为复制一个MARA表，然后对其进行大数据量写入，然后对大并发进行测试。请看下面的测试结果，顺便提一下，生产机应用程序服务器共5台P595做负载均衡2台16C 32核 128G内存，3台8C 16核 64G内存，主频都是2.2GHz ，数据库服务器是一台P595，16C 32核 2.2GHz主频 128G内存：

• 1w条数据 * 1进程，开发机19s，生产机14s
• 1w条数据 * 4进程，开发机平均22.5s
• 1w条数据 * 10进程，生产机平均20s
• 1w条数据 * 20进程，生产机平均31.45s
• 10w条数据 * 20进程，生产机平均399s

从上面的测试数据看，生产机比开发机性能好，但是在生产机10进程并发和20进程并发分别下降42.8%和124.6%，10w条数据的写入时间换算后，进一步衰减177.7%，可见并发时的衰减还是很大的，并且也没能达到数量级的提升，这主要的原因是影响单个进程运行速度的主要因素是CPU速度、内存和磁盘速度，而生产机比开发机在单一性能上并没有强多少，因此生产机应该能在提供更大的吞吐量，我们猜测大量的并发可以提高总体效率。由于以上测试使用的程序几乎99%时间消耗在数据库上，因此我们推测，实际业务数据导入的时候，衰减会好一些。数据量加大后，同样是20进程，衰减再进一步扩大，这一点我们没有很好的解释，但依据次数据，我们推测导入业务数据时20进程的衰减应该在三者平均值约114%左右。

这一天，我们再次干到快午夜才离开单位，明天生产系统中会准备好业务数据供我们进行实际测试，希望接下来一天的测试能给我们一些好消息。

5. 第四天

我们将程序改好后传输到生产系统，由于先前我们认为BDC仍然是影响速度的一个关键因素，最终我们通过沟通决定暂时不导入最后一这部分，这让我们的导入提升接近一倍。我们对100条数据、500条数据做了单进程测试，可以达到0.125秒/条的速度。在晚上下班后，我们又做了500条数据*10进程并发的测试，单进程速度衰减100%，比我们预测的要好一些，接下来再做200条*40进程并发测试，单进程速度衰减仍然是100%，这让我们看到了服务器高吞吐的能力，也让心里有了底。

这一天还有BASIS的两位同事帮我们在做测试的时候监控系统后台资源使用状况，我们曾考虑到一些可能影响性能的参数，经过几次调整，虽然没有大幅提升，但是让系统资源得到了充分的利用。我们尝试了关闭Oracle redolog，尝试了Oracle服务器的进程设置等等。

按照0.125/条速度，30进程并发，速度下降100%计算，一天24小时系统可以接受1036w的数据导入，即使是考虑到去掉的BDC功能再跑一次，也可以接收超过500w的数据，目标完成。接下来就是完善程序的功能，包括修改输出日志、增加可调参数等等。在这一切都完毕之后，我们遇到了新的问题，数据。

以第一个导入数据的子项目来说，6w主数据扩展到96个工厂，总共是576w条，如果按照4w/文件计算，需要创建144个文件，可是事实上将来只有一两个人会做这项工作，如何能在一天之内准备144个数据文件、定义后台作业成了难题，因此我们决定扩大单个文件的数据量，提高到19.2万条数据/文件，这样刚好是30个文件，30个进程，每个进程将运行14个小时左右，时间刚刚好，30个进程并发也刚好使我们的预期。

这里我们还在担心一些问题，19.2w数据的excel文件将达到200M，需要消耗内存超过300M，保存一次需要近1分钟，保存的文件约74M，转换有的txt文件约60M，对19.2w的数据进行操作很有可能因为资源不足无法Ctrl+Z，这必然给数据整理工作造成及其大的障碍，对于这一问题，我们暂时不考虑了，从技术的角度讲，系统已经达到1036w数据/天的导入速度，而剩下的则是人的工作了。

5. 第五天

这一天，我的大部分时间用来写这篇文章，像东总说的，这是一次非常有价值的Performance Tuning工作，虽然我们只是对程序做了少量的修改和调整，但这一切都是基于4天没日没夜的测试、评估与计算上，没有这四天一次一次的测试数据，我们也无从知道大数据量、大量并发的情况下系统将如何表现。

总的来说这次性能调优还是收获很大，当然除了本文总结的内容，还有很多值得总结的地方，今天时间太紧张，日后如有可能再补上吧。这很有可能是我此次暂离公司之前做的最后一件事情了，按计划，下周回来，我要去找人力经理办理离职手续了，在临近离开之前，做这样一件事，好像是老天安排我一个收官之作，希望一切顺利，一切安好。

在此，我想感谢在这次工作中一起奋斗ABAP兄弟，Allan Zhu和Jamey Qi，还有BASIS洪老大、小熊，没有你们我做不好这事，也做不了，谢谢！

截止到现在，我已经结束了本周的工作，即将启程去上海，宝贝已经在上海等我了。

ps. 本周只做了这一件事情，所以只写了一篇文章。

Google App Engine

        其实很早就听说过Google App Engine，但是我发现我一直就是后知后觉的，虽然一直会有各种各样的idea，但是总落后于时代，后来我把这种结果归结于自负，的确，很多时候，我都愿意自己去“创造”，可是我一直忽略了这个时代的进度，也就是说，绝大多数情况下，我一直是落后的，那么所谓的“创造”，最多也是上个时代的东西。

        我写文章，就爱写题外话，总是写跑题的，言归正传，今天要说的是Google App Engine，简称其为GAE。GAE是在2008年上半年上线的，上线的时候只是支持Python语言，现在支持Java了，每个Google Account支持3个应用程序，而现在已经支持10个，原来支持2G流量，现在支持10G了。不过我最大的感觉是Google App Engine简单来说就是一个虚拟主机，只是它支持的脚本语言是Python，跟一般虚拟主机策略不同，GAE只支持自己的BigTable，并不支持最流行的PHP，Mysql等流行开源技术，我的理解是GAE要建立自己的Web应用平台，而且GAE有绝对的自信，即使是不支持那些流行技术，同样可以做的很好。

        Google经常会给人们熟知的服务起一个新的名字，但是慢慢的，我发现，Google总是给它们赋予新的含义。GAE也是这样，既然叫App Engine，就必定不同于以往的虚拟主机，GAE希望能建立一个统一的Web应用平台，而这正是多年前Google曾希望的，将全世界的数据纳入同意平台管理一样。

        GAE现在为每个应用程序提供46.3CPU小时的时间，10G数据流量，1G数据存储，2000个Email发送，超过这个限制的，则要花费0.1美元/G流量，价格还是非常低廉的，和国内8元/2G/月的流量比起来的确很不错。

       GAE因为是支持Python为主，虽然支持Java了，但是对于大多数Web应用，我指的是blog、论坛、CMS等，是以PHP+MySQL为主，GAE的支持者转向python+bigtable仍需一定的理由，但在今天，我也的确发现了不少优秀的Blog程序，相信GAE会获得越来越多的支持。其实我一直关心的是，GAE在Google的战略中是一个怎样的地位。并不是怀疑，而是暂时还未看清。向我文章开头讲的，我一向后知后觉。

      最后，说完一大堆啰嗦的事情，简单说说GAE能做什么：

• GAE像一般的虚拟主机一样，可以用于托管应用程序，但是目前支持Python和Bigtable数据存储
• GAE可以让用户绑定自己的域名，以独立域名的方式访问服务
• 每个GAE账户支持10个应用程序，每个应用程序可以免费占用1G存储空间、10G/日流量、2000Email/日发送，超出部分需要交纳费用
• GAE可以用来建立Blog、图片共享等一切Web应用，也已经有人做过校内等SNS社区插件，效果不错

      Google App Engine的技术其实并不新鲜，无非是多了一种数据库、一种编程语言的支持，但是其蕴含的战略，的确值得关注。

       我发现我总是喜欢在文章最后再说点别的，GAE虽然不支持PHP，但是Google支持Java，而Java中的Resin或Jetty+quercus则可以完美支持PHP 5.2+，所以，从这个角度讲，在GAE上跑PHP也是没有问题的。

        大概是半年前的时候第一次听说Tiny URL，当时没理解，为什么要把网址缩短，反正都是复制粘，何苦呢？今天我恍然大悟了，原来是因为微信息时代催生了对Short URL的需求。

        什么是Short URL？中文称为“缩短网址”，就是将一个很长很长的网址缩短为十几个字符的短网址，比如本文的地址是http://www.alicenalex.com/2009/06/short-url-service-with-tiny-blog/，共67个字符，通过bit.ly可以缩短为：http://bit.ly/yMIeo 。

        过去的几年里，越来越多的网址超过50个字符，而在SNS与微信息的这个时代，缩短的网址变得越来越重要。看看Twitter的信息长度限制为140个字符，叽歪的信息长度为70字符就能明白为什么了。

        Short URL服务是合适开始出现的呢？要追踪Short URL的历史，我从Google Blog Search中翻阅过去的言论。”Short URL”第一次出现于2006年1月22日一篇博客日志中，当时提供缩短网址服务的那个网站是Orz.net，现在已经无法访问了。2006年1月~6月共有11篇文章与此有关；“缩短网址”的中文关键字，第一次出现在2006年6月30日的一篇日志中，提到的是www.kuso.cc，这是一个繁体中文的网站，现在仍然健在。此后“Short URL”2007、2008以及2009年截止到目前查询的数据则分别为1557、14723、14831，从这个数据中我们可以看出Short URL服务是在2006年初开始出现的，2007年~2008年每年都以接近10倍的速度被人们谈论着。而Short URL服务的网站也从最初的个位数激增到数十家。

        Short URL作为一项服务，事实上我很关心的一个事情就是它将如何盈利。目前大多数Short URL服务还都没有明显的盈利模式，少部分则在用户访问缩短的url时并非直接跳转到目标网址，而是附投放展示广告或一些B2C平台的产品销售广告，这种模式在很多Web2的服务中已经被无数次验证其可行性，而创建Short URL的用户则也可以从中分成。

        我曾不止一次在互联网上探寻简单而又具有巨大需求的功能，缩短网址算是十分符合预期的一个。记得哪位投资人事讲过商业模式简单的恰恰是容易成功的。不过Short URL服务商要想长期、健康的生存下去恐怕并非十分容易，毕竟门槛不高，同质化竞争会逐渐加剧，行业洗牌在所难免。