2012年1月20日星期五

Snova的C4在几个免费PaaS平台上的部署(Openshift, CloundFoundry, Heroku, Jelastic)

C4主要是从snova-heroku部分移植,修复了一些bug,性能大大增强,实用性大为增强,不再只是玩具试验性质的东东了。

Openshift

  • 注册帐号

          到这个链接注册https://openshift.redhat.com

  • 安装工具

          安装命令行工具rhc,安装依赖ruby以及gem, https://openshift.redhat.com/app/express#quickstart

          注意, gem安装rhc可能被防火墙中断,可能需要设置代理,代理可以用snova设置,如

                   gem install --http-proxy http://127.0.0.1:48100 rhc

  • 部署

           将snova-c4-server-[version].war 放到一个创建的空目录下,然后在命令行下进入该目录,逐个执行下面的命令:

      rhc-create-domain -n <domainName> -l <yourId> -p <yourPassword>  创建主域名, 部署新应用是这一步可不执行
rhc-create-app -a <appName> -t jbossas-7.0 -p <yourPassword> 创建app
cd <appName> 进入上一步创建的目录
mv ../snova-c4-server-[version].war <appName>/deployments/ROOT.war
git rm -r src pom.xml
git commit –m “delete”
git push 以上三步重新部署同一个app时可不执行
git init
git add .
git commit –m “deploy”
git push


CloundFoundry




  • 注册帐号



          注册, https://my.cloudfoundry.com/signup, 注意,注册不是马上成功,似乎是第二天才会收到注册成功的邮件




  • 安装工具



          安装命令行工具vmc,安装依赖ruby以及gem,和openshift的工具rhc安装过程类似



          http://start.cloudfoundry.com/tools/vmc/installing-vmc.html




  • 部署



          将snova-c4-server-[version].war放到任意的空目录下,然后在命令行下进入该目录,逐个执行下面的命令



      vmc target api.cloudfoundry.com
vmc login
vmc push <appname> —— 此处appname为任意名称,为域名一部分,此命令执行后有后面的交互,参照下面的输入Y/N
Would you like to deploy from the current directory? [Yn]: Y
Application Deployed URL [<appname>.cloudfoundry.com]: <回车>
Detected a Java Web Application, is this correct? [Yn]: Y
Memory Reservation (64M, 128M, 256M, 512M, 1G, 2G) [512M]: <回车>
Creating Application: OK
Would you like to bind any services to 'snova4'? [yN]: n
Uploading Application:
Checking for available resources: OK
Processing resources: OK
Packing application: OK
Uploading (843K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK



Heroku



参考snova中heroku的wiki即可



Jelastic




  • 注册帐号



          http://jelastic.com




  • 部署



          完全图形化的操作,无需安装工具,按照说明将war上传并deploy到ROOT下即可



          http://jelastic.com/docs/upload-deploy-application



后记:



这几个所谓的PaaS平台中,粗略观察下,纯以平台IO性能而言,似乎Openshift较差,CloundFoundry最好,已接近或超过AppEngine;部署上,Jelastic部署最为简单,完全界面上操作,其它几个则相对复杂,需要安装各种复杂的命令行工具部署,简直到了”非程序员不能为也的地步”了。

2012年1月9日星期一

字符串匹配算法

今日,研究了一天的字符串匹配算法,小有所得。主要是从这个链接学习, http://www-igm.univ-mlv.fr/~lecroq/string/

理论上,这里算法都比glibc中strstr的算法复杂度小,但在实际场景中,特别是和目前的开发的产品中关键字匹配场景下,无论是Boyer-Moore还是Knuth-Morris-Pratt等这些经典的算法实现都比strstr慢得多,而strstr的默认算法仅是一种高度优化过的Brute Force实现(Linux下C的测试结果证明如此,java下根据默认string.IndexOf算法看来,可能另有差别,需要进一步证明)。

目前得到一点结论是,这些经典的算法中都有预处理阶段,而Brute Force实现并无此阶段,当是预处理阶段耗时较多造成的差别。

(从200字节中查找20字节字符串1000000次, strstr:0ms, 其它最优的实现是250ms+)

2012年1月7日星期六

关于《郭嘉传》的一事

维基上关于林彪的条目中有一段说1966年9月,毛让林读《三国志》中的《郭嘉传》和《宋书》中的《范晔传》。

重读《郭嘉传》,契合当时环境下最重要的就是是曹操在郭嘉死时对大臣们说的一段话,就是毛对林的暗示,以太祖自喻,以郭嘉喻林。(林也是较为年轻,亦是多病之身)

毛这里借曹操之口告诉林值的以天下事相托,不过另外半句从《范晔传》中传达的信息却是险恶万分,这里暂且不谈。

”及薨,临其丧,哀甚,谓荀攸等曰:「诸君年皆孤辈也,唯奉孝最少.天下事竟,欲以後事属之,而中年夭折,命也夫!」“ ——《郭嘉传》

2012年1月2日星期一

百年一遇的2011

2011已经结束了, 无论是说今年是辛亥百年还是今年有世纪光棍日,这都是百年难遇的年份,似乎注定会发生不少值得纪念的事情。于己而言,在2012的开始,目前船票尚无的状态下,应该有必要对过去的一年写些什么。

2011年是我到目前这家公司的第二年,年中的时候开始了一个大的项目,由于在2010年底开始参考Netty实现断断续续地写了一个C++的多进程的网络服务框架,借助这个框架,倒是比较顺利地完成了这个项目(4人4个月的时间83,000L,代码稍多,这当中很佩服其中一位女程序员,可能是我见过的最聪明的一位女生了),另外最主要的成果是这个框架也已经成熟了,可以用在以后的工作中,另外若有机会,也可以考虑包装宣传一下。开源也可适当考虑。

另外,业余的开源项目方面,之前发布一年有余的一个开源项目在工作中的项目开始前不久就完全停滞了,一直到工作项目发布上线后一个月才想起;后来的一段时间基于前段时间的工作中的感悟,完全重构了这个开源项目,更名为snova,性能,扩展性都大幅提升,心里也有了小小的成就感,算是2011的善终吧。

2011发生的太多事情也使自己愈发变得愤青,却仍然奉行犬儒主义,不发一言,亦无任何行动,或是民族的劣根性?  这一年遇一所谓的“官二代”,其人其行其为于己格格不入,于此同时重读《俄国人》一书,感受良多,却仍只是慨叹“天凉好个秋”。读完乔治.奥威尔的《1984》也给自己相当长时间的震撼,同时试图研究卢梭,无果。

到年底,高高兴兴地过完百年难遇的世纪光棍节后,除了开始重构开源项目外,倒是"天下承平,四海无事“。 年底的最后,在政府的感召之下,开始萌发一丝拥有”广厦“一间的幻想,当然,大部分的幻想在破灭之前都真实地触手可及。

在2012的开始展望一下2012,发现除了随太白慨叹一句”欲渡黄河冰塞川,将登太行雪满山“以外,竟无一语其他。

关于snova-heroku的一二三

 

大约圣诞节前一天,发现了heroku这个PaaS平台,看了一下wiki以及heroku.com上的介绍,觉得有些意思;后来正好工作上没多少事情,花了半天仔细看了一下这个平台相关技术架构,虽然不甚了了之处仍有不少,不过大致上已经了解到从技术角度而言对于heroku,可以用来做些什么以及不可以做些什么。

heroku本质上是一个分布式环境,但对于开始的免费账户只提供一个dyno(heroku的特有概念,类似Instance),CPU大约是750h/month,带宽没有限制。支持的语言较多,主要是ruby,另外python/java目前也支持。Runtime上限制远比Google的AppEngine为少,以Java为例,从语言角度来看几乎没有任何限制,目前观察到的唯一“限制”就是App的input只能是HTTP请求,当然这是基于Web的PaaS的必要条件,也谈不上限制了。

后来的一天,着手写了一些代码,初步验证开始的想法正确;由于之前一段时间写了一个基于GoogleAppEngine的proxy,而这个proxy有不少Appnegine平台的限制,正好heroku没有这些限制,于是开始着手实现基于heroku的proxy。

实现的过程总体上是顺利的,除了当中偶发奇想用一些P2P技术代替HTTP请求耽搁了几天,最后大约2011.12.30完成所有实现。之后两天主要修改项目上的wiki以及snova项目的其它子项目,在2012到来的第一天正式release。

注:1. 用一些P2P技术代替HTTP请求从原理上任然是可行的,不过相对目前的实现几乎没有任何性能优势;2. 目前的实现通过异步IO+定期轮询绕过了较多的技术限制,但这种技巧在分布式环境中算是一种错误方法,只不过由于免费环境只有一个dyno才得以利用。

 

http://code.google.com/p/snova/wiki/HerokuInstallation

2012.01.02 小恙中记