我的永久链接结构的性能如何？

Question

我的永久链接结构的性能如何？

- 14
- 816 2010-10-29
我已经在wp黑客邮件列表,此论坛以及Google周围阅读了有关不同永久链接性能的讨论.

但是,我无法真正推断出我过去几年使用的永久链接结构是否良好:

/%postname%-%year%%monthnum%%day%.html

此组合将邮编直接放在/之后,并且年,月,日组合更加独特,因为许多邮编具有相同的名称.过去10年来,我一直在博客中使用html(甚至是pre wordpress),所以这是很久的.

我不知道这是对性能的提升还是对性能的下降,我该如何检查?

(我运行博客已有10年了,大约有10.000个帖子,其中包含许多链接)

链接:

http://codex.wordpress.org/Using_Permalinks

http://www.google.com/search?q=wordpress+类别+永久链接+性能

http://ottopress.com/2010/category-in-permalinks-considered -harmful/

http://lists.automattic.com/pipermail/wp- hackers/2010-October/035458.html
I have read the discussion on the performance of different permalinks on the wp hackers mailinglist, THIS forum and around Google.

I could however not really deduce if the permalink structure I have been using for the past years is good or not:

/%postname%-%year%%monthnum%%day%.html

This combination put the postname directly after the / and the year,month,day combination makes it more unique since many postnames carry the same name. The html addition is something I have been using for the past 10 years on my blog (even pre wordpress) so that is legacy.

I dont know if this is good for permance or bad for performance, how can i check this?

(I have been running the blog for +10 years and there are about 10.000 posts with many links in)

links:

http://codex.wordpress.org/Using_Permalinks

http://www.google.com/search?q=wordpress+category+permalink+performance

http://ottopress.com/2010/category-in-permalinks-considered-harmful/

http://lists.automattic.com/pipermail/wp-hackers/2010-October/035458.html
permalinks database performance

3 个回答

投票数

- 1
- 2010-11-12
我否决了接受的答案.重写规则的复杂性绝对不能衡量文章查找的性能.

尤其是,以帖子名称开头的永久链接似乎很糟糕；参见 http://codex.wordpress.org/Using_Permalinks#Structure_Tags

在没有研究Wordpress代码的情况下,我可以想象它们以某种方式索引了文章的层次结构.因此,永久链接中使用的变量应从左到右从最通用到最具体的变量排序.这种试探法强烈支持标准年份/月份/名称或类别/名称.

I veto the accepted answer. The complexity of the rewrite rules is in no way a measure for the performance of article lookup.

In particular, it seems that starting your permalinks with post names is bad; see http://codex.wordpress.org/Using_Permalinks#Structure_Tags

Without having looked into Wordpress code, I can imagine that they somehow index posts hierarchically. Therefore, the variables used in permalinks should be ordered from left to right from the most general to the most post specific variable used. This heuristic strongly favors the standards year/month/name or category/name.
- 实际上,如果存在大量页面,则实际上已经知道并确认"类别/名称"会导致性能问题.它与查找速度没有太大关系,而与推导正确的对象服务无关,并且重写规则的复杂性是完全相关的.
  
  `category/name` is actually known and confirmed as causing performance issues if large amount of pages is present. It is not as much related to speed of lookup as to deducing correct object to serve and complexity of rewrite rules **is** completely relevant.
  - 1
  - 2010-11-12
  - Rarst
- 您可以提供文件/代码参考吗?我只是略读了代码`(wp-include/rewrite.php`和`wp-include/query.php`)；虽然看起来确实很糟糕,并且不必要地复杂,但看起来基本上是收集并标识了零件,然后将其直接插入SQL查询中.我仍然不明白为什么不同的订单需要更长的时间.但是,当执行数据库查询时,必须执行多个连接,并且_here_顺序确实很重要.我似乎还记得MySQL在优化连接顺序方面特别糟糕.
  
  Can you give a doc/code reference please? I just skimmed the code `(wp-include/rewrite.php` and `wp-include/query.php`); while is looks really awful and unnecessarily complicated, it appears that basically the parts are collected and identified and then directly inserted into SQL queries. I still cannot see why this should take longer for different orders. But when the db-query is executed, several joins have to be performed and _here_ order really matters. I seem to remember that MySQL is particularly bad at optimising join order.
  - 0
  - 2010-11-12
  - Raphael
- 我不太了解数据库理论,但是您必须保持产品较小.在任何情况下,这都可能是一个错误,因为它的编程效率不高.
  
  I am not too deep into DB theory, but you have to keep products small. In any case, this might be a bug in the sense that it is programmed not as efficiently as it could be.
  - 0
  - 2010-11-12
  - Raphael
- 好吧...我读到以帖子名称开头很糟糕,其他答案的确显示每个条目多行(但对于我在wordpress上运行多年的10.000个帖子博客来说,在不丢失大量引用的情况下,我可能没有太多改变).我没有完全理解您在这里的答案和"否决权",当您否决答案时我需要做什么?
  
  Well... i read that starting with post names was bad AND the other answer shows indeed multiple lines per entry (but for my 10.000 posts blog which i run on wordpress for years there is probably not much I change without losing a lot of references). I did not completely understand your answer here and the "veto" though, what do i need to do when you veto an answer????
  - 0
  - 2010-11-14
  - edelwater
- 我只写了"否决权",这里没有这样的功能.我的观点是,更高的运行时间是由执行更多的代码或DBMS引起的.由于找不到任何可以暗示URL组件顺序不同的原因应该增加代码运行量的原因,因此我声称原因在于数据库查询.但是有这么多帖子,也许您的订单太慢了,因为您有这么多帖子.您是否使用缓存?
  
  I only wrote "veto", there is no such function here. My point is that higher runtime is caused by more code being executed or the DBMS. Since I could not find any reason that would suggest that different order of URL components should increase the amount of code run, I claim the reason lies with the database queries. But with that many posts, maybe any order is slow _because you have so many posts_. Do you use caching?
  - 0
  - 2010-11-14
  - Raphael
- 嗯,不是冒犯,但在没有仔细研究WP代码的情况下否决答案没有多大意义.FWIW,我编写,固定和优化了一般的WP代码,尤其是WP永久链接代码,以了解可扩展的内容和不扩展的地方.;-)详细的规则可能会导致options表中的设置很大,然后需要将其从数据库(或memcached)中拉出,并在每次页面加载时不进行序列化.我已经看到了后者的用例在2006年将中等负载的bi-xeon服务器带入了爬网.
  
  Err, no offense, but vetoing an answer without having thoroughly studied the WP code doesn't make much sense. FWIW, I authored, fixed and optimized enough WP code in general, and WP permalinks code in particular, to know what scales and what doesn't. ;-) Verbose rules can lead to a huge setting in the options table, that then needs to be pulled from the database (or memcached) and unserialized on every page load. I've seen the latter use-case bring a moderately loaded bi-xeon server to a crawl in 2006.
  - 0
  - 2010-11-14
  - Denis de Bernardy
- 好吧,那么您应该能够提供更多细节,而不是"不要冗长".这里的冗长是什么?变量的顺序重要吗?(因为Codex会这样做,而您的发言根本无法解释！)此外,如果必须在每次页面加载时拉一次此设置,为什么效果会增加更多的帖子呢?反序列化不应该_fast_吗?但是,是的,当然,我正在考虑有意义的级别,而不是代码中的含义.并非所有代码都有意义.
  
  Well, then you should be able to give more specifics than "don't be verbose". What is verbosity here? Does the order of variables matter? (since Codex says it does and what you say does not explain this at all!) Furthermore, if this setting has to be pulled once per page load, why does the effect increase the more posts there are? Should deserializing not be _fast_? But, yes, certainly, I am thinking on the level of what makes sense, not what is in the code. Not all code makes sense.
  - 0
  - 2010-11-14
  - Raphael
- 法典给出"一些提示"(请参阅法典),但没有具体说明完整的算法.但是它确实指向http://ottopress.com/2010/category-in-permalinks-considered-harmful/和http://comox.textdrive.com/pipermail/wp-testers/2009-January/011097.html所有总之,在人机交互领域中的url黑客攻击最佳实践与性能改进领域的性能之间存在某种摩擦.
  
  the Codex give "A few HINTS" (see Codex) and does not specificy the complete algorithm. It does however point to http://ottopress.com/2010/category-in-permalinks-considered-harmful/ and http://comox.textdrive.com/pipermail/wp-testers/2009-January/011097.html all in all there is a sort of friction between best practices of url hacking in the field of human computer interaction and performance from the field of performance improvement.
  - 2
  - 2010-11-14
  - edelwater
- 感谢您的指针ottopress.它改变了惯例,使每个页面url以`/page/`开头,每个发布url以`/post/`开头,从而消除了歧义.您应该能够自己执行此操作,将固定文本添加到永久链接结构中.无论如何,这可能是个好决定.如果我在FOO类别中有一个帖子BAR,而在FOO的子页面中有一个页面BAR,该怎么办?假设％category％/％postname％方案都将通过`/foo/bar/`来解决.还是在全球范围内独一无二?
  
  Thanks for the pointer ottopress. It appaers that changing conventions such that every page url would start with `/page/` and every post url with `/post/`, removing the unambiguity. You should be able to do this yourself, adding the fixed text to your permalink structure. This would probably be a good decision, anyways; what happens if I have a post BAR in category FOO and a page BAR that is subpage of FOO? Both would be addressed by `/foo/bar/` assuming the %category%/%postname% scheme. Or are slugs globally unique?
  - 1
  - 2010-11-14
  - Raphael
- 哦,据我所知,没有太多的帖子破坏了该系统,但是有很多页面,对吗?由于Wordpress最初是博客系统,因此很有意义.然后.
  
  Oh, and as I understand it not having many posts breaks this system but having many pages, right? Since Wordpress started out as blogging system, this made sense. Then.
  - 0
  - 2010-11-14
  - Raphael
- 是的,冗长的规则会使页面多且附件少,但帖子却不多.原因是,除非有其他规定,否则wp认为这是一个帖子.为了避免永久链接与帖子的冲突,wp在2005年引入页面时就引入了详细规则.仍然有一些票证(有些带有补丁程序,有些没有补丁程序)试图改善这一方面的情况.
  
  Yeah, having many pages and attachment is bad with verbose rules, but not having many posts. The reason is, wp assumes it's a post unless a rule specifies otherwise. Verbose rules were introduced when wp introduced pages, way back in 2005, in order to avoid permalink collisions with posts. There are still several tickets (some with patches, some without) that try to improve things on this front.
  - 0
  - 2010-11-14
  - Denis de Bernardy
- 哦,如果不清楚什么是详细规则,则其要旨是每个页面,附件和自定义帖子类型,而不是使用通用正则表达式来标识该类型的所有数据,而是以多个规则结束,因此regex-同样,按页面,附件或自定义帖子类型.仅此一项就足以显着降低速度,但真正的瓶颈实际上与拉扯和反序列化规则有关.
  
  Oh, and, in case it's unclear what verbose rules are, the gist of it is, each page, attachment, and custom post type, instead of using a generic regex to identify all data of that type, ends up with several rules and thus regex -- again, per page, attachment, or custom post type. This alone is enough to slow things down significantly, but the real bottle neck is actually related to pulling and unserializing the rules in the first place.
  - 0
  - 2010-11-14
  - Denis de Bernardy
- 因此,简单的正则表达式匹配可以解决的问题变得mess肿,仅仅是因为从一开始的某些假设就不再适用.行为未更改有特定原因吗?害怕因为旧的链接会断开?尤其是如今,页面和帖子之间的区别似乎是人为的,但这是另一个主题.
  
  So what could be solved by simple regexp matching is bloated to a horrible mess just because some assumptions from the beginning do no longer apply. Is there a particular reason why the behaviour has not been changed? Fear because old links would break? In particular, the distinction between pages and posts seems artificial nowadays, but that is another topic.
  - 0
  - 2010-11-14
  - Raphael
- "原因为何未更改"-> http://core.trac.wordpress.org/search?q=永久链接
  
  "reason why not changed" --> http://core.trac.wordpress.org/search?q=permalinks
  - 0
  - 2010-11-15
  - edelwater
- 618个错误是完全重新制作而不是保留它的原因.
  
  618 bugs are a reason to do it whole new, not to keep it.
  - 0
  - 2010-11-15
  - Raphael
- @Raphael:我怀疑这里的每个人都会同意这一点.但是,正如我们每个真正为WP Core贡献补丁的人都知道的那样,并且在618个搜索结果中有相当一部分会显示出来(它们并不是所有的bug,顺便说一句:也请注意补丁和变更集),WP核心开发人员不会随时提交贡献的错误修复和增强.特别是当它们是不重要的增强功能时.
  
  @Raphael: I suspect everyone here will agree on that. But as each of us who actually contribute patches to WP core know, and as quite a few of those 618 search results will reveal (they're not all bugs, btw: notice the patches and changesets too), the WP core devs do not readily commit contributed bug fixes and enhancements. In particular when they're non-trivial enhancements.
  - 0
  - 2010-11-15
  - Denis de Bernardy
- 当然.您不想为您甚至没有自己编写代码的中断负责.但是我们一直都在获得新功能.也许某个功能冻结,直到某些问题(我怀疑WP中有更多粗糙的边缘)得到妥善处理为止?
  
  Of course. You do not want to be responsible for a break you did not even code yourself. But we get new features all the time; maybe a feature freeze until some issues (I suspect there are more rough edges in WP) are handled is in order?
  - 0
  - 2010-11-16
  - Raphael
- 0
- 2010-11-15
仅针对工作流程质量检查:

答案是:不,这不是一个与性能有关的好的永久链接结构.

Just for the workflow QA:

The answer is: NO this is not a good permalink structure concerning performance.

Denis de Bernardy · Accepted Answer · 2010-10-29

8

2010-10-29

您可以通过查看数据库中rewrite_rules选项的大小来进行检查.如果它很小(我认为应该采用这种结构),那么您就不会使用冗长的规则.相比之下,如果您在每个静态页面上看到几行,则说明您使用的是冗长的规则,这不是很好.

不幸的是...每个静态页面GRIN都有几行.因此,这可能不是一个好的永久链接结构……嗯……这确实解释了我之前收到的错误消息:" WordPress数据库错误有一个大于'max_allowed_packet的数据包",我不得不在MySql中增加此设置.

unfortunately... there are several lines per static page GRIN. So this is probably not a good permalink structure...hmmmm... this does explain an error message I got a while ago "WordPress database error Got a packet bigger than 'max_allowed_packet", I had to increase this setting in MySql.
- 0
- 2010-10-29
- edelwater
再说一次...如果您几年来一直在增加页面,那么无论如何...您都会自动获得max_allowed_packet ...除非您恢复为非漂亮的永久链接...(我认为)如此...以便在未来30年内可扩展:)我可能将不得不恢复到非常漂亮的永久链接.我认为.

then again... if you keep adding pages during years you will automatically get max_allowed_packet no matter what... unless you revert to non pretty permalinks... (i think) so... to be scalable for the next 30 years :) I will probably have to revert to non pretty permalinks. I think.
- 0
- 2010-10-29
- edelwater
只要您使用的是非详细规则,页面,附件和自定义帖子类型规则都是通用的.因此,只要链接使用的是非详细结构,漂亮的链接在实践中就非常安全.

As long as you're using non verbose rules your page, attachment and custom post type rules are generic. So pretty links are quite safe in practice, so long as they're using a non verbose structure.
- 1
- 2010-11-11
- Denis de Bernardy