Re: Trac 的博客问题,请教下

4 views
Skip to first unread message

Zoom.Quiet

unread,
May 17, 2012, 2:48:34 AM5/17/12
to 任我飞, trach...@googlegroups.com
在 2012年5月17日 下午2:44,任我飞 <renwo...@gmail.com> 写道:
> 大妈您好:
> 我们使用了Trac 并使用了fullblog插件来写博客,然后一帮人3年下来写了6000多个日志~,结果发现/blog访问越来越慢。
>
> 不知道你们是否遇到过这样的问题,fullblog插件本身可以支持显示多少个,可是实际上会查询所有的表,需要自己实现分页吗?

- 真心没有,,,俺使用的是维基多
- 不过,如果你使用的是 MySQL 的话,可能出现问题
- 如果导为 pg 的話,应该有自动优化的,就不会感觉慢了,,,
- 当然,继续 MySQL 的话,可以吼 fullblog 的作者,看有什么优化的方式,,,
- 俺猜,主要是那个进入时的所有日志列表的生成,完全动态,没有什么优化处理,导致慢了,,

--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/

Zoom.Quiet

unread,
May 17, 2012, 2:58:39 AM5/17/12
to 任我飞, trach...@googlegroups.com
在 2012年5月17日 下午2:53,任我飞 <renwo...@gmail.com> 写道:
> 没错。就是get_blog_posts函数sql语句没任何优化处理。。
>
>   sql = "SELECT bp1.name, bp1.version, bp1.publish_time, bp1.author, " \
>                "bp1.title, bp1.body, bp1.categories " \
>                "FROM fullblog_posts bp1 " \
>                + join_operation + where_clause \
>                + " ORDER BY bp1.publish_time DESC"
>
> 这个是他写的,我也不知道该如何优化。我们现在改成:
>   sql = "SELECT bp1.name, bp1.version, bp1.publish_time, bp1.author, " \
>                "bp1.title, bp1.body, bp1.categories " \
>                "FROM fullblog_posts bp1 " \
>                + join_operation + where_clause \
>                + " ORDER BY bp1.publish_time DESC limit 100"
> 这样只显示100个就快了。。。但是以前的就看不到,也索引不到了。
>

- 嗯嗯嗯,看来要 hack 一下,自个儿写分页效果而已
- 应该有很多示例的,玩一下?!

赖勇浩

unread,
May 17, 2012, 9:36:32 AM5/17/12
to trach...@googlegroups.com
2012/5/17 Zoom.Quiet <zoom....@gmail.com>:

> 在 2012年5月17日 下午2:44,任我飞 <renwo...@gmail.com> 写道:
>> 大妈您好:
>> 我们使用了Trac 并使用了fullblog插件来写博客,然后一帮人3年下来写了6000多个日志~,结果发现/blog访问越来越慢。
导出 rss,然后用 wordpress 之类的整一下?

>>
>> 不知道你们是否遇到过这样的问题,fullblog插件本身可以支持显示多少个,可是实际上会查询所有的表,需要自己实现分页吗?
>
> - 真心没有,,,俺使用的是维基多
> - 不过,如果你使用的是 MySQL 的话,可能出现问题
> - 如果导为 pg 的話,应该有自动优化的,就不会感觉慢了,,,
> - 当然,继续 MySQL 的话,可以吼 fullblog 的作者,看有什么优化的方式,,,
> - 俺猜,主要是那个进入时的所有日志列表的生成,完全动态,没有什么优化处理,导致慢了,,
>
>
>
> --
> 人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
> 俺: http://about.me/zoom.quiet
> 文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/
>
> --
> 邮件来自: Google 论坛"TraChinese"论坛。
> 发言: trach...@googlegroups.com
> 退订: trachinese-...@googlegroups.com
> 详细: http://groups.google.com/group/trachinese
> 工程: http://trac-hacks.org/wiki/TracChineseTranslation

--
web site:http://laiyonghao.com
twitter: http://twitter.com/laiyonghao

@@

unread,
May 17, 2012, 11:50:41 AM5/17/12
to trach...@googlegroups.com
没看过fullblog。 
不过按照trac的wiki表设计 页面多了肯定慢的。
他的历史和页面共用的一个表。。

你这个可以看看他的查询语句,考虑在那个表上加一个相应的索引试试。

2012/5/17 Zoom.Quiet <zoom....@gmail.com>

sniperpr

unread,
May 17, 2012, 11:54:28 AM5/17/12
to trach...@googlegroups.com
记得前阵子, openwrt的 trac  搜索列表出现 sqllite 失败情况.

后来修复了.貌似他们的 ticekt和channge太多了...也很慢.

可以询问下他们的开发者有对这个问题进行过处理没.
他们很开放.
Reply all
Reply to author
Forward
0 new messages