uliweb性能之优化思考

性能与功能的确有些矛盾。因为开发uliweb更多是从功能上考虑，因此在性能上我一直没有太仔细测试和分析过。最近找了一个主机部署了一下，别人告诉我刷新一下CPU占用很高，于是我想有机会的确还是要好好搞一下。于是加了一些跟踪，发现了一些问题：

1. get_apps() 的问题

因为uliweb是采用app方式来组织，而且app是允许使用python的包形式。在启动时，为了查找app下的settings.ini和config.ini等信息，使用的是pkgresource的resource_filename，它是要导入才可以的。但是一个导入可能会使得加载变慢。这块的确有些问题。为了查找包的目录，因此要导入，但是后面的处理未必会使用这个包，显得有些浪费。因此我修改了这块处理。如果包是由a.b.c这样形式构成的，我会只导入a，后面两个直接根据a的目录生成一个路径。这样只要保证a的__init__.py中没有太多的耗时的代码就可以了。这样优化后减少了一些时间。

2. pytz的问题

因为uliweb的ORM会处理时区的问题，而且我写了一个utils/date.py模块专门来处理时区转换。因此在启动时，为了省事，我自动导入了date.py模块，它会自动导入pytz模块。但是我发现pytz的导入非常慢。这样造成整个uliweb的启动变慢。因此这块我直接去掉了，让用户自已来处理好了。

3. 可能会引起问题的地方。app的__init__.py文件。因为考虑有些bind的代码会写在__init__.py中，因此在启动app时会自动导入所有app。因此如果有app在这里写了很耗时的代码会影响整个uliweb的启动速度。也许你会认为不好，不过uliweb已经提供了许多静态化的方法，如：bind和expose可以静态化，即在settings.ini中进行配置，这样__init__.py中可以是空的。

这里的问题主要是由于方便性考虑产生的：采用自动化的方式，减少用户的导入或初始化的工作，结果使得处理范围扩大化，影响启动效率。

注意我说的主要是启动时的效率，一旦启动不退出，效率要好一些。

因此uliweb如果每次都是重新启动必然会造成性能下降，比较好的方式还是驻留式，不要每次启动。象mod_wsgi, fastcgi应该是可以支持的。是不是自带一个web server采用反向代理会更好呢？象java一样。