SHA-1 vs SHA-256

标签:JavaScript, Python, 性能

最近想在GAE上实现一个验证码,但又不想用传统的键盘输入方式。一来是习惯用鼠标,切换到键盘很麻烦;二来是生成图片的成本很大,在GAE上还不能用C实现;三是在让机器难以识别的同时,也会造成用户的困惑。
所以想到Google曾经提出的一个技术:提供一组选项,用鼠标将正确的选项拖动到指定位置,然后提交。

Java、PHP、Python与MySQL交互的性能测试

标签:Java, PHP, Python, 性能

这几天看源码弄清了一件事:WEB服务器接收浏览器请求、将请求传给PHP/Python进程(FCGI等)、与数据库进行交互都是用socket(套接字)。
也就是说,这些行为都是进程间通信。一台WEB服务器在硬件、操作系统不变的情况下,它的性能主要取决于socket通信的速度。如果所有进程都在一台服务器上的话,这个速度就取决于通信的效率了。

G-WAN Web服务器:用C脚本来生成动态页面

标签:性能

今天发现一个叫G-WAN的轻量级Web服务器,居然可以用ANSI C脚本来生成动态页面。
在它的主页贴出的测试结果可以看到,比其他Web服务器快了很多,甚至在1000并发时,比Nginx还快25倍!

sqlite3的性能不错

标签:性能

Python 2.5里内置了sqlite3模块,可以直接创建sqlite数据库。虽然是个小型的数据库,不过测试后发现性能确实不错,看来足以用于嵌入式开发。

选择Google App Engine框架:慎用Django

标签:Google App Engine, 性能

GAE开发者或许会注意到这点,查看控制台的访问记录时经常会发现红色或黄色标记,表明该访问使用了较多的CPU时间。
对用户而言,0.5秒以内的响应时间(含网络延迟)比较完美,1秒以内尚可接受,2秒以上就会觉得很慢了。
而我使用的cpedialog,初次访问首页将花费1.9秒的CPU时间和0.7秒的API CPU时间(约1.6秒响应时间,不含网络延迟),紧接着的访问只需0.35秒的CPU时间和0.17秒的API CPU时间(约0.2秒响应时间),隔几分钟后访问则需要1.1秒的CPU时间和0.17秒的API CPU时间(约0.8~1.2秒响应时间)。
由于这个blog我基本不使用,所以只有约5%的概率可以让用户感觉不错,这个性能确实很糟糕。

« 看看还有什么好玩意