XWIKI效率问题

 

Xwiki 效率：

      

Xwiki 效率瓶颈之一，表与表之间的关系过于复杂，每次开启 XWIKI 的时候都需要去查询多张表，而在运行过程中关联表的查询过多 , 主要有以下几个方面，当你编辑一篇文章的时候，它会把你这篇文章给锁住，当你要保存的时候它就会去数据库里面的查询看看这篇文章是否被锁定，如果有就删除，然后插入数据库，单单 lock 表就有两张；每一个类都有它对应的表，比如 NumberClass,PropertyClass 这都有它自己的表 , 当你需要创建的时候它会去查询看看你创建的类，有没有相关的记录；在 Xwiki 中就属于它的垃圾回收站机制不错，但是当你是超级管理员的话，你去查询这条数据的时候，发现 XwikiDoc 里没有记录，它也会到回收站表里面去找看看有没有相应的记录，如果有它会把它给查询出来，因为存在表里面的记录是用 XML 的形式来存储的，它需要用 DOM 来解析它，然后再显示，如果说你要从回收站里恢复这条记录的话，它又会从内存中获取数据然后插入到 XwikiDoc 这张表，这样多次操作会非常的影响效率 ，单从这一点来说效率就会相对慢很多，还有就是 Hibernate 过于灵活导致效率有一定的影响，其实 Xwiki 在中很多的功能我们并没有用到而且每一次都需要去加载，例如国际化和 PDF 导出等，这些都需要占用过多的资源。

 

 

       Xwiki 效率瓶颈之二，集成了过多的框架，例如他采用了 lucene ， captcha 等，为了能识别图片文字采用 captcha 这个框架，这个框架属于人工智能的框架，内容非常的多，如果我们在框架整和方面简单化，速度方面会有一个变化。

 

      

Xwiki 效率瓶颈之三，变态的灵活性，这样导致在设计方面会非常的精密，需要过多的代码实现，例如：所见即所得的 HTML 编辑 , 提供 XML/RPC 的 API 和元数据，表单设计引擎等，这些东西都需要庞大的资源

 

 

       Xwiki 效率瓶颈之四，用户权限系统， Xwiki 的权限系统，属于网状模式的，它有着复杂的表关联关系，每一次用户去访问一篇文章的时候， Xwiki 就会做判断，首先获取你的用户名 ID ，然后拿到关联表里面去查询看看你有没有对此篇文章有操作的权限。

Xwiki 效率瓶颈之二，集成了过多的框架，例如他采用了 lucene ， captcha 等，为了能识别图片文字采用 captcha 这个框架，这个框架属于人工智能的框架，内容非常的多，如果我们在框架整和方面简单化，速度方面会有一个变化。
这个还好吧，俺觉得，lucence做信息查询几乎是必须的，至于captcha，我只知道用它搞个验证码。。。

Xwiki 效率瓶颈之三，变态的灵活性，这样导致在设计方面会非常的精密，需要过多的代码实现，例如：所见即所得的 HTML 编辑 , 提供 XML/RPC 的 API 和元数据，表单设计引擎等，这些东西都需要庞大的资源
感觉你说的这些东西都是一个方面，比如所见即所得的 HTML 编辑，这个东西不能算占资源吧，你不喜欢可以不用啊，

Xwiki 效率瓶颈之四，用户权限系统， Xwiki 的权限系统，属于网状模式的，它有着复杂的表关联关系，每一次用户去访问一篇文章的时候， Xwiki 就会做判断，首先获取你的用户名 ID ，然后拿到关联表里面去查询看看你有没有对此篇文章有操作的权限。
这个是没有办法的事情，还好有cache不是。