昨天按照一些文安装配置了mod_limitipconn，但是其实大部分的文章在说明的时候并没有说清楚，其中最大的一个问题就是安装以后安装程序修改httpd.conf文件是有问题的，默认情况下是添加了：
LoadModule limitipconn_module modules/mod_limitipconn.so
AddModule mod_limitipconn.c
其实后面的那个AddModule mod_limitipconn.c是要删除的，否则apache2不能正常启动，AddModule似乎是apache1.3的语法。
可以限速的找到两个，一个是Bandwidth Module，Version 0.5rc1， Bandwidth and Connection control per Virtual Host or Directory， Last Updated January 28th, 2005，http://www.ivn.cl/apache/
另外一个mod_cband，Version 0.9，A virtual host
bandwidth-limiting module provided to solve the problem of limiting
virtualhosts bandwidth usage，Last Updated September 07th, 2005，http://cband.linux.pl/
可以限制连接数的也有两个：
mod_vhost_limit，v0.1，
Restrict the number of simultaneous connections per vhost，
Last Modified : 2004.02.26，http://www.ivn.cl/apache/
上次提到要重写JR的系统，其实最想做的还是底层的框架。
这几年看了或者用了很多东西，最开始了解并深入学习的就是jive，以后还有junit，spring以及hibernate，都是让我感觉比较好的东
西，然后在工作的过程中看到别人设计的各种框架，感觉都有很多优点，但是使用起来又不是那么舒服，因此想总结一下自己的经验，看看能不能做一个让自己满意
的系统。
其实做这个系统的最开始的出发点就是嫌各种东西比较麻烦，第一就是代码重复，第二就是需要一些学习成本，第三有些不太直观，第四就是麻烦。
我考虑的第一个出发点就是减少配置，使用规则替代，这样可以避免一些前后不符的情况，对于以后的维护比较好；
第二就是简单，使用的技术的门槛尽量低，类合理的少。
第三就是尽量直观易用，尽可能提供一步到位的功能。
系统的核心是javabean，或者是POJO，他是数据库操作和页面表现层的核心，数据库的内容可以直接提取出来变成javabean，页面也可以使用
javabean完成数据表现，web请求中的参数直接填写到javabean中，数据库的持久不是自动的，但是只需要调用API触发一下。
目前系统的各个部分的设计还没有考虑好，有些甚至还没有确定能否解决，需要慢慢的细化，也许需要找几个人一起来做。
一直都在考虑是否重写JR的系统，主要的原因就是目前JR的系统已经比较乱了，数据库方面的代码已经有三套了，由于没有写过单元测试的代码，因此全部更新
为一套是不太可能的；另外就是缓存的管理已经有些混乱了，有些是进行缓存的，有些没有，有些出于性能的考虑改用了自定义的缓存形式；想增加某些功能的时候
不太好加，因为对系统的损伤太大，这个已经在我的JR缓存系统的思考中提到过；页面的代码也不理想，重复的代码太多了，要进行某种改动，为了统一需要改动很多地方，这个也是历史遗留问题。
另外一个很重要的原因是想试验一下自己积累的代码，验证一下自己的一些想法。如果重写，肯定要重新设计一些底层的东西，简化类似系统的开发并且简化代码，争取消除大部分的重复代码（类似的问题在JIVE中也是同样存在）。
这段时间可能会整理一些想法，更加清晰的表达出来，也相当于进行设计了吧。
今天看到了JBuilder2006的对等协作功能的介绍，给我的感觉是很不错，目前项目都是合作开发，而小组内的成员的合作方式还不是很好，如果在开发工具中集成了协作功能，特别是和工程密切相关的内容的共享协作功能，那么应该算是一个巨大的进步，今天晚上下载下来用用看了。
今天公司组织了一个培训，培训方式是通过web和电话会议，你可能会对这种培训形式很奇怪，我也一样。
通过web，我们可以看到类VNC或者终端服务这样的效果，讲课的人在那边操作，可以播放PPT，旁边是一个文字聊天栏，或者一个小的聊天栏加一个那边的电脑屏幕的实时截屏（效果不是很理想，比较慢），而这个功能是
集成在一个applet里面的，但是看上去的效果和单纯的web是一样的，要不是浏览器状态栏的applet
window的信息提示，你不太可能想到这是个applet；而语音是通过电话会议解决的。
今天给我的感触到不是完全因为他们做的那个在线培训的东西，而是回想这段时间以来的一些事情，由于系统架构和开发方式的变化，我们现在引进了很多东西，和
我关系比较紧密的一个就是引入crystal
report，另外一个就是引入agile的开发方式，并购买了rally的服务，这些都是会加大成本的。在刚开始使用crystal
report的时候，有些内容通过看用户指南并不直观，结果经过几天后，架构师告诉我他买了一个tutorial，让我从公司的FTP上下载，一看，竟然
有1.2G，不出所料，是视频的资料，也不知道多少钱；然后是rally的服务，按人头按月收费，我们有三十多个人，又是一笔开支；买了rally的服
务，但是我们不是很会用，然后就是今天的在线培训，明天还有；还有crystal
report的，由于我们不是很懂，那边说要找个人咨询一下，又是一笔钱。
说了这么多，最后的感觉就是美国人在IT上舍得花钱，只要是自己没有的或者不懂的，但是觉得需要的，那么肯定舍得花钱买服务、请人培训、买资料或者请人咨
询一下。而国内，更多的恐怕还是寻求免费的服务和资料。这个和国家的情况是吻合的，但是趋势还是像美国的情况一样，专业细化，形成共赢。
最近增加的关键字功能可能会对JR系统的整体性能造成比较大的伤害，原因就是JR的系统中最值得称道的缓存功能的限制。
按照原来的情况，JR的缓存系统在90％的情况下会工作得很好，这个和系统的特点有关。
JR的用户，很多是按照我们的页面给出的顺序查看我们的内容，当然也有一些是通过各种搜索引擎搜索得到某个内容，但是按照比例而言，按照顺序浏览的可能比较多，因此大部分的人查看的内容都在缓存中，不在缓存中的内容会再到数据库取，因此系统的效率比较高。
而在增加了关键字功能后，关键字相关的文章列表中的内容很可能不在我们的缓存中，因此要把文章相关的内容都从数据库中取出来，这个时候缓存的功能就没有发挥应用的作用甚至成为了负担，因为缓存的内容的频繁交换在这种情况下做了很多无用功。
其实这个问题并非不能解决，甚至可以增加各种排序功能（按照目前的情况增加排序功能对系统的损害是致命的），方法就是改造缓存系统，将目前的单级缓存修改为多级缓存。
按照jive的缓存设计，每个被缓存的对象需要提供一个大小信息，而缓存管理器会维持一个大小受限的缓存池，如果采用二级缓存，内容的主要信息缓存下来（例如标题，作者，发布日期，回复数，最后更新日期，查看数，最后回复者等等），
而帖子的内容一级回复作为二级缓存的内容，按照一定的比例分配一级缓存和二级缓存的大小，而系统中经常查看的可能是内容列表而非内容，这样
缓存的功能就可以大大增加，即使把全部的帖子信息都缓存下来也是可能的，因为这个信息相对帖子的内容而言很小。
这个改造的难点在于缓存是系统的一个非常核心的功能，缓存相关的代码可能比较多，进行重构并不容易，当然应该是值得研究下的。
目前JR的关键字功能比较简单，一个关键字实际上由并列的几个关键字构成，例如ioc，di以及控制反转都是作为同样的关键字对待的，每篇文章包含的每个
关键字都是有权重的，权重的算法目前也非常的简单，如果是标题中包含关键字，那么权重是出现的次数X关键字的长度X5，如果正文中包含关键字，那么权重是
出现的次数X关键字的长度，如果标题中包含某个关键字，那么正文中的同一关键字的权重将再乘以2，目前看，对于单一关键字这个权重的结果还是比较好的，基
本上能够反映出所有文章中和关键字的匹配程度。对于英文的单词，目前是全词匹配的，否则误判很高，例如di这个关键字，很多单词都包含这个字母序列，而我
们在判断是否包含关键字的时候都是转换为小写进行处理的。
目前正在开发中的是文章相关性功能，初步的设想是从原文章中取出其权重最高的五个关键字，然后看看其它的包含这些关键字的文章，其权重的和最高的就认为是
最相关的，目前看结果不是很理想，可能对于原文章中的关键字的权重大小不同对目前文章的关键字的权重进行相应的处理后得到的才能是比较好的结果。但是这个
也需要检验。
这个是这个工具的地址，里面有很多功能可以帮助进行网页的开发以及调试，我刚刚从别人那看到，还没有怎么用就给大家推荐了，因为这个第一印象已经很让我震撼了，更可贵的是他只有94K大小。
看看将JR的表格边界都显示出来的效果的截图吧：
今天看了一下JR在google的page rank，就拿JR的首页来说，可以用很多个URL访问到，但是对于同一个页面他给出的page rank值是不同的，也许我太苛刻了？
下面是不同的URL的page rank的值：
© 2025 解惑
本主题由Anders Noren提供 — 向上 ↑