Lifetype的性能问题

[maomaode]

昨天有一位朋友, 从blogbus将他的文章转入博客蓝, 他有371篇文章, 287个tag, 1400多个评论.
我目前的做法是将blogbus的tag转换成bokeland的文章分类.
这个时候, 导入本身没有问题.
但是完成以后, blog怎么也打不开了. php执行时间设置为默认的60s

通过删除文章分类, 删节到100个, 才算解决问题. blog可以在3s内显示出来

我个人感觉,  plog_articles/plog_articles_categories/plog_article_categories_link 这三个表设计可能复杂了. 在大数据量操作情况下, 花费时间太长.

Thoughts?

[james]

可以請你在LT 1.1上試驗看看嗎?
LT1.1的效能和目前LT1.0.x相比有大幅度的提升。
我個人認為資料庫的架構目前應該不適合做更動(因為影響太大了)
相信LT1.1應該會讓你滿意的 

James.

[lss]

這是 tag 和 category 本質上的不同吧。

雖然兩者都是分類用途，但是本質上的不同，會讓 tag 和 category 在實作上有很大的不一樣。

等到 1.2 版時， LifeType 就會支援 tag 了。

lss

[freediscuz]

1.1还在观望中。

1.2可在猴年马月。

[markwu]

昨天有一位朋友, 从blogbus将他的文章转入博客蓝, 他有371篇文章, 287个tag, 1400多个评论.
我目前的做法是将blogbus的tag转换成bokeland的文章分类.
这个时候, 导入本身没有问题.
但是完成以后, blog怎么也打不开了. php执行时间设置为默认的60s

通过删除文章分类, 删节到100个, 才算解决问题. blog可以在3s内显示出来

我个人感觉,  plog_articles/plog_articles_categories/plog_article_categories_link 这三个表设计可能复杂了. 在大数据量操作情况下, 花费时间太长.

Thoughts?

開不了的原因是因為 memory_limit ... 而非 php execution time.

以 1.0 來看，這麼大的文章分類的量，可能要訂為 32MB，才比較適合吧！

另外，以我來看，我不覺得這個表有什麼不適合。因為他是非常『正常』的正規化後的 table .... 但是問題就在這。

如果是我，我會在 articles 這個 table，再加上一個 catategories 的欄位，然後把 categories 的 id array，serlization 後放在這個欄位裡。這是很常用的 de-normalize 的技巧。

這樣可以減少 join。這可以方便查到 article 的 categories ...

反過來，由 category，要查裡面有多少 articles .... 這邊應該可以不用再動。

可是，1.1 雖然不是這樣改，但是在 1.1 應該會改善不少，因為透過 object cache，只有在系統沒有 cache object 的時候才去 query 資料庫，有 cache 後，將不會再動到任何資料庫。

不過第一次的 query 還是一樣 ... 

所以你說有沒有問題？依照課本上的教法，這是對的設計。但是在實際應用上 ... 就是有缺陷。

我建議你，先 implement tags，然後再來作匯入的動作。否則文章分類真的不適合拿來當tag 用。

Mark

[markwu]

1.1还在观望中。

1.2可在猴年马月。

那就慢慢等，慢慢觀望吧！ 

Mark

[maomaode]

与其观望, 不如多做测试, 如果有时间的话, 多帮社区做点贡献.
开源就这样的. 重在参与.

[maomaode]

Hi mark,

我目前MEM确实已经设置为32M了. 但是还是不行. 唯一可行的办法就是减少文章分类的数量. 我并不知道极限值是多少, 但我大概知道应该在100~150之间.

如果是我，我會在 articles 這個 table，再加上一個 catategories 的欄位，然後把 categories 的 id array，serlization 後放在這個欄位裡。這是很常用的 de-normalize 的技巧。

似乎也有点问题, 如果想找某一个category的文章, 会比较麻烦.  不知道做一个视图, 是否能解决问题, 不过有的数据库可能不支持视图.

据说1.2要实现TAG, tag这个字段, 是否是直接加在article 表里呢?
还是有一个TAG表, 将所有文章ID, 做为一个字段

[lss]

...
据说1.2要实现TAG, tag这个字段, 是否是直接加在article 表里呢?
还是有一个TAG表, 将所有文章ID, 做为一个字段
...

要講效能的話，兩邊都做最快。只要系統運作沒意外的話，兩邊的 tag 資料應該不致有出入。實作上應該也沒什麼問題吧！

lss

[markwu]

Hi mark,

我目前MEM确实已经设置为32M了. 但是还是不行. 唯一可行的办法就是减少文章分类的数量. 我并不知道极限值是多少, 但我大概知道应该在100~150之间.

还是有一个TAG表, 将所有文章ID, 做为一个字段

mmm... 那你可以試試看裝上 xdebug 來查查看 memory 的用量。另外，你查一下你的 mysql status，看看 slow query 是哪些。還有，把 error notice 打開，看看到底是哪些錯誤。

如果是我，我會在 articles 這個 table，再加上一個 catategories 的欄位，然後把 categories 的 id array，serlization 後放在這個欄位裡。這是很常用的 de-normalize 的技巧。

似乎也有点问题, 如果想找某一个category的文章, 会比较麻烦.  不知道做一个视图, 是否能解决问题, 不过有的数据库可能不支持视图.

据说1.2要实现TAG, tag这个字段, 是否是直接加在article 表里呢?
还是有一个TAG表, 将所有文章ID, 做为一个字段

這裡你誤會了。我是說，這三個 table 還是留著。但是在 lt_articles 多 implement 一個 category id 的 serialization。這個方便用來查這個文章的 Categories.

而由 categiory 來查詢文章，可以透過 articles_categories_link 來查詢。 這會很快的。

多作一個 view ... 這是很好的 idea 啊！可是在 mysql 4.1 下是沒有用的  。除非我們改用mysql 5.0, postgreSQL 或是 Oracle 了。 

Mark

[maomaode]

言之有理!

那么我能想到的唯一缺点就是, 对于删除和更改操作, 需要改动的地方多了一个.
但是考虑到我们最多使用的是query, 似乎也不是太大的问题.

Cheers

[maomaode]

要講效能的話，兩邊都做最快。只要系統運作沒意外的話，兩邊的 tag 資料應該不致有出入。實作上應該也沒什麼問題吧！

意外的事情很难讲, 不过只要发生一次, 就足够用户受了. 如果非要做两个的地方, 而且非要保持一致的话, 可以通过trasaction来做, 不过好象有的数据库并不支持trasaction.

不过我还是赞同你的说法, 两边都做.因为数据库大部分时间是在做query.只要query足够快, 系统就足够快.

[markwu]

maomaode：

不過，大部分 1.0 的 slow query 在 1.1 應該不會出現了！因為我們已經 de-normalize 很多東西了。

看看吧！ 1.2 繼續 de-normailize ....

所以啊！這樣的程式，一開始就應該要設計好，要不然每次都要改 tabl，作 database migration，這是很累的！

呵呵！

Mark

[maomaode]

最近发现修改文章速度特别慢， 我在自己的机器上做了试验， 修改文章所需时间仅为2s， 而点击修改文章时， 却需要34s左右， 经过调试发现
class/view/admin/admineditpostview.class.php 中的
      $articlecategories = $this->getArticleCategories();

总共耗时32s，

getAticleCategories 总共操作了3张表， plog_articles(24473条目), plog_articles_categories(1420条目)和plog_article_categories_link(25862条目)

这个数据量应该来说算是轻量级的。

所用系统为LT1.0.4， 不知道1.1中是否还存在类似问题， 有待测试...

[maomaode]

不知道大家用什么来做性能测试？ 我是自己写了一段脚本， 来测试运算总共耗时， 特别老土的办法。

如果那位有什么先进的武器， 记得推荐一下，

最好能将某一个操作的stacktrace， 已经每个步骤耗时打印出来。
记得c里面是有这个工具的。

谢谢