LifeType 中文開發論壇

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

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

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

Thoughts?

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

James.

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

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

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

lss

1.1还在观望中。

1.2可在猴年马月。 :-)

開不了的原因是因為 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

那就慢慢等，慢慢觀望吧！  :-D

Mark

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

Hi mark,

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


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

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

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

lss

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


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

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

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

Mark

言之有理!

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

Cheers

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

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

maomaode：

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

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

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

呵呵！

Mark

最近发现修改文章速度特别慢， 我在自己的机器上做了试验， 修改文章所需时间仅为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中是否还存在类似问题， 有待测试...

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

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

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

谢谢

建议1.1以后不要再做升级， 直接上LT2， 重新设计架构。 根据LT1所积累的经验， 我想LT2将在设计、架构上会更好。
如果可行的话， 我也希望加入其中一员。
期待一个新的架构诞生...

对不起, 发布了一个错误警报, 那段代码是我自己加入的, 不好意思.
之前没有svn控制, 很多废弃代码仍然在代码里, 需要好好清除一下.

事实上修改文章的速度是很快的.

真希望php也能和java一样有checkstyle和pmd 这样就可以自动坚持是否有无用的代码.

 :-P