来自陈晧的 http://coolshell.cn/articles/4990.html 引用 学习Unix/Linux系统调用《Unix高级环境编程》，，了解系统层面的东西。 《Unix编程艺术》了解Unix系统领域中的设计和开发哲学、思想文化体系、原则与经验。你一定会有一种醍醐灌顶的感觉。 《Unix网络编程卷1，套接字》这是一本看完你就明白网络编程的书。重要注意TCP、UDP，以及多路复用的系统调用select/poll/epoll的差别。 《Unix网络编程卷2，进程间通信》信号量，管道，共享内存，消息等各种IPC…… 这些技术好像有点老掉牙了，不过还是值得了解。
http://wiki.apache.org/solr/SolrInstall#Setup 按这个说法，似乎要部署的对象有两份：一份solr.war，一份solr.home指向的solr应用. 在maven + svn 环境下，这种东西要怎么部署，需要好好想想。
solr不是一个jar库，而是一个java web app应用. 你的系统一般不是引入一个库，而是要与新搭建的solr webapp进行远程通信。 运行在servlet容器里的solr，在使用方式上相当于一个数据库，是独立的。 如果你一定要把solr当成jar库来用也可以，官方提供了一个"EmbeddedSolr"，看合不合你的胃口 ： http://wiki.apache.org/solr/EmbeddedSolr
引用 $vmstat -1 然后关注其中的si和so列，它们分别代表swap in 和 swap out 或者使用top命令，如果发现buffer和free都接近0，则意味着swap正在激烈地投入使用。
这里用的是FastVectorHighlighter，可以高效地对付大文件 <!–pom.xml–> <dependency> <groupId>org.apache.lucene</groupId> <artifactId>lucene-fast-vector-highlighter</artifactId> <version>3.0.0</version> </dependency> package player.kent.chen.temp.lucene.highlight; import java.io.File; import org.apache.commons.io.FileUtils; import org.apache.lucene.analysis.standard.StandardAnalyzer; import org.apache.lucene.document.Document; import org.apache.lucene.document.Field; import org.apache.lucene.document.Field.Index; import org.apache.lucene.document.Field.Store; import org.apache.lucene.document.Field.TermVector; import org.apache.lucene.index.IndexWriter; import org.apache.lucene.store.Directory; import org.apache.lucene.store.FSDirectory; import org.apache.lucene.util.Version; public class MyHighlightIndexer { public static void main(String[] args) throws Exception { String rootDir = "/home/kent/diskD/home-kent-dev/workspace/kent-temp/data/lucene-sanguo"; File contentDir = new File(rootDir, "content"); …
package player.kent.chen.temp.lucene.stemming; import java.io.IOException; public class MyLuceneStemmingDemo { private final static String allText = "The companies organized an better activity than the individuals."; public static void main(String[] args) throws Exception { Analyzer snowball = new SnowballAnalyzer(Version.LUCENE_30, "English"); doSearch(snowball, "company"); //搜不到 doSearch(snowball, "compani"); //搜得到 doSearch(snowball, "organize"); //搜不到 doSearch(snowball, "organiz");//搜不到 doSearch(snowball, "organ");//搜得到 doSearch(snowball, "good");//搜不到 doSearch(snowball, "act");//搜不到 doSearch(snowball, …
我原以为可以search阶段直接把特定的payload取出来，然后打印一下，但google了很久，似乎没有直接的API. Payload可能本来就不适用于这种用况。 Lucene in Action说， 引用 "… use it during search, either to decide which documents are included in the search results or to alter how matched documents are scored or sorted"
收藏一个非常轻量的性能测试工具： http_load 它跟apache ab比较类似，但有个优点是可以接收多个URL作为测试输入，而不像apache ab那样，一次只能使用一个URL.
阮一峰翻译的一篇文章里说单CPU的Load超过了0.7就不好，接近1.0时就要想办法降下来。 而著名运维余洪春的观点是：单CPU的Load只要在3以下，都属于“系统性能良好”。 到底那种说法更靠谱？ 首先，亲身经验表明第一种说法并不靠谱。对一个没什么I/O操作的应用来说，由于CPU开足马力为你服务，Load逼近1完全正常。 至于余洪春的说法，由于我自己经验不足，不敢说对还是错。 今天一个高手同事给出的观点是 [1.5， 2）范围内的load比较正常。 Load是等待队列和运行队列中的任务总和，一个运行、一个等，他认为是合乎性能要求的，我们的绝大多数应用也都是用这个值作为预警条件。
为什么有的应用响应快Load却很高？ 响应快 => 排队少 => Load应该更低吧？ 但今天比较了两个服务端应用，一个I/0比较多，响应比较慢，单核Load在0.7左右；另一个I/O比较少，响应非常快，单核Load却几乎达到了1.0 . 今天经高手指点，才终于明白。 I/O比较多的应用中，由于I/O阻塞，老是会有任务会被从队列里剔除，所以队列并不密集；而I/O较少的应用则相反。 如果把CPU队列比做一条高速路，汽车就是任务；任务发生I/O阻塞，相当于汽车发生故障，车子被暂时停到了路肩上。 对于I/O密集型的应用，路肩上停的车很多，路上跑的车却并不多，所以道路会感觉很松。 不过，响应快并不意味着Load就一定会高，两者没有简单的正比关系，必须具体情况具体分析。