影响到search 性能的可能因素：
lucene 在执行每个查询时都要先获得segments 文件中存储的索引信息（包括segment段数量、每个segment 文件的位置、索引中的记录总量、索引中的field 信息等等），一般是在读取segments 文件之前先生成一个commit.lock 文件，这样可以阻止其他的程序对其进行访问(即以排他方式读取segments 文件中的信息)，在成功获取了索引信息后程序会自动删除commit.lock 文件。
在索引文件比较小、field 项比较少（如索引文件在500MB以下）的情况下获取索引信息的过程会比较快，一般在10ms 之内；但随着索引文件的增大，获取索引信息的过程就会拉长，当索引文件超过1000MB 的时候，这个过程一般会被拉长到10ms以上；索引文件在10000MB的时候这个过程会被拉长到40ms甚至更长。粗略统计，当索引文件超过1000MB的时候，获取索引信息的过程将占据整个查询过程的10%~15%。
另外，由于获取索引信息的过程是以排他方式进行的，所以在多个请求并发的情况下会发生等待的现象；在并发请求过多的时候甚至会出现commit.lock 长时间没有被删除的特殊情况，这时后续的查询请求将无法被正常处理、整个search 服务将被阻塞。
当初在设计WebLuceneServlet 的时候，为了能够正确的截取请求中的中文q参数，在执行request.getParameter("q")之前先调用了 request.setCharacterEncoding("gb2312")方法。这样做虽然避免了乱码的出现，但却使得 WebLuceneServlet 同时只能处理一种编码，无法实现类似于Google 的搜索效果，例如下面两个链接：
昨天，也就是2002-06-29，把对weblucene 的修改commit 到sourceforge.net上去了。sourceforge.net 的cvs 操作起来要稍微麻烦一些，必须先通过ssh 登录一次cvs.sourceforge.net，并把CVS_RSH 设置为ssh， 然后才能够通过ext 进行更新和提交，并且我得每次add、commit 操作都要数一次密码:(
$ export CVS_RSH=ssh
$ ssh -l lhelper cvs.sourceforge.net
$ cvs -d:ext:lhelper@cvs.sourceforge.net:/cvsroot/weblucene