Category: Web

尝试VPS中

前两周俱乐部买了一个VPS服务器,几天下来基本上明白VPS是个怎么个用法儿了。
首先VPS是一个运行在服务器上面的虚拟机,你可以通过ssh等方式来控制它。我们买的这个是centos的系统,搭配了Kloxo来进行管理。Kloxo是一个通过网页方式来控制VPS的管理程序,功能非常强大,域名、DNS、WEB服务器、配额管理、文件管理、进程管理、文件操作、文件解压,什么都可以做。通过Kloxo可以直接添加域名,设置web服务器的基本配置,启动服务,中间不用一个配置文件都不用改。

Kloxo另外一个很有用的功能是“客户”功能。你可以在Kloxo里面添加“客户”或者“代理”,他们就会拥有自己的一个Kloxo账户,还会自动生成Linux帐号、服务器配置文件、FTP帐号等等。客户和代理的区别在于后者拥有添加客户的权限。而对于每一个Kloxo帐号还可以添加一个子帐号来共同管理同一个Kloxo帐号(说的真绕,不知道说明白没有)。你可以买一个VPS然后给几个朋友分别开一个客户,分上限额,共同来用这个VPS。甚至都可以不会用命令行,只要明白了Kloxo那个网页界面就成。

通过ssh远程控制服务器的感觉的确比较酷,不过也出现了没有想到的问题。首先VPS价格会比普通的虚拟空间要贵,这直接导致我们买了只有128M内存的VPS。然后就是VPS不够稳定,这一点在我们这个小内存VPS上面就非常明显。一开始web服务器默认使用的是lighttpd,在换成apache以后一天之内死机了两次,而且都是在几乎没有流量的情况下发生的。检查了一下发现是内存用完了导致的死机。apache一启动以后就会有6个线程,每个线程显示占用20-30M内存。虽说实际使用的并没有这么多,但是随便来一点点访问量内存就全部耗完了。不得以换回了lighttpd,发现传说中lighttpd省内存还真不是吹的。

使用seige对VPS进行了一个小小的压力测试(其实没有多大访问量)。使用15个并发访问,每两次访问之间间隔1秒钟,也就是说每秒访问15次。总共持续10分钟。服务器方面,放了3个域名,分别对应了mediawiki, wordpress, drupal三个php程序。seige随机的访问三个域名中的任意一个。

seige统计如下:
Date & Time,      Trans,      Elap Time,      Data Trans,    Resp Time,    Trans Rate,    Throughput,    Concurrent,    OKAY,    Failed
2009-11-10 21:20:17,       5886,         598.99,        41,        1.02,        9.83,        0.07,        10.02,        5163,    0
这10分钟总共有接近6000次http访问,平均响应时间是1.02秒,最长响应时间7.7秒,最短0.49秒。

服务器端使用vmstatm每隔十秒记录一次内存使用量,内存余量一直在20-30M之间波动,在测试的后半段系统把一部分内存移到了swap分区,物理内存空余量回到了接近40M。CPU占用率一直在30%左右。

用GAE开发wiki

  我越来越发现我out了,GAE都出来这么久了我才发现在google code上面有一个google官方的项目,里面塞满了各种使用GAE来做应用的例子。于是国庆这段时间把它整个下了下来,将其中的cccwiki这个例子修改了一下成了一个可用性更强一点(但是功能仍然很弱,国庆闲暇时候做的东西不要有太高期待哈)的wiki。点这里可以看到例子,如果对源代码感兴趣的话可以在这里找到(使用Mercurial版本管理)。

wiki-screenshot

wiki-screenshot

  最初的cccwiki只是很简单的把每一个页面的html源代码保存并展示出来。我做了以下修改:

  • 增加了revision功能,把修改的历史记录都全部保存了下来
  • 使用wiki标记语法,而不是直接标记html
  • 用MarkItUp替代原先的TinyMCE作为编辑器。因为前者支持wiki语法,而且貌似也更灵活
  • 加入了CreoleParser来解析wiki标记语法。不过Creole语法和MarkItUp所支持的wiki语法不大一样,还需要对MarkItUp进行修改
  • 对界面进行了一点点修改,看起来似乎是要好一些了?

  整个修改的过程非常的顺利。我是用的Eclipse+Aptana PyDev来开发的,虽然整个过程中没有用一个完整的rails或者django之类的框架,但是效率并不低,很多功能很快就实现了。

  一方面是因为GAE特殊的数据存储机制。GAE中不能使用通常意义上的数据库,而是用的google自己开发的使用的分布式数据存储(官方管这个叫做 Google App Engine datastore)。感觉上应该很适合wiki这种数据。经过GAE包装以后感觉用起来非常像Ruby on Rails中存储数据的方式--你只需要声明一个类,然后把数据直接赋值给它的某些成员变量,然后调用一个叫做put的成员函数就保存进去了。对于查询也可以用类似Rails的类成员函数的方法来进行,同样的如果想要进行复杂的查询的话也可以使用GQL(一个google自己搞的类似于SQL的语言)来弄。总而言之,你不需要也不能和数据库打交道,也就免去了很多数据存储方面的代码量。这方面整体感觉和Rails非常像。
另一方面,虽然GAE并没有提供创建项目的一些脚本,但是这对于开发效率的影响其实也并不大。众所周知,那些脚本无非是给你创建一些文件夹和没有多少行代码的文件,在Eclipse中干这些事情也不会多花几分钟。

  django的粉丝肯定会对GAE非常不爽,因为数据库不能用直接导致django的MVC中的Model一层完全就不能用了。不过另一方面,自己重新写一个Model层也不会很费事,google已经把datastore弄得很好用了。真正让人觉得不舒服的是GAE中的诸多限制。你只能通过GAE中的接口通过http方式访问外部的资源,发邮件也是如此。如果你的程序太消耗CPU,或是带宽,或是其他什么硬件资源,那么它会被停掉。不过相对于其他的免费空间GAE已经算是很不错了。

  GAE上线到现在时间已经不短了,但是仍然没有多少出名的应用部署在GAE上面。这个结果似乎也是显而易见的:虽然GAE的软件部分已经开源了,但是其中的关键技术--分布式的计算和存储--却是其他人所很难复制的。为了开发GAE上面的应用我必须遵从它的软件接口,那也就意味着这个东西如果不想在google上面跑的时候就必须面临大量改动。而且谁也不能保证什么时候google会不会像关闭其他半途而废的项目一样关掉GAE。对GAE这个东西玩玩就好了,要是真想做东西的话还是用django吧。