私のパーマリンク構造のパフォーマンス？

Question

私のパーマリンク構造のパフォーマンス？

- 14
- 816 2010-10-29
wpハッカーのメーリングリスト、このフォーラム、およびGoogle周辺でのさまざまなパーマリンクのパフォーマンスに関するディスカッションを読みました.

しかし、私が過去数年間使用してきたパーマリンク構造が良いかどうかを実際に推測することはできませんでした:

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

この組み合わせでは、/の直後に投稿名を配置し、年、月、日の組み合わせを使用すると、多くの投稿名に同じ名前が付けられるため、より一意になります. htmlの追加は、私が過去10年間ブログで使用してきたものであり(ワードプレス以前でも)、それはレガシーです.

これがパフォーマンスに良いのかパフォーマンスに悪いのかわかりませんが、どうすれば確認できますか?

(私は+ 10年間ブログを運営しており、多くのリンクを含む約10,000件の投稿があります)

リンク:

http://codex.wordpress.org/Using_Permalinks

http://www.google.com/search?q=wordpress+カテゴリ+パーマリンク+パフォーマンス

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

http://lists.automattic.com/pipermail/wp- hackers/2010- 10月/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`は実際には既知であり、大量のページが存在する場合にパフォーマンスの問題を引き起こすことが確認されています.ルックアップの速度とは関係がなく、提供する正しいオブジェクトを推測することと、書き換えルールの複雑さが完全に関連しています.
  
  `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クエリに直接挿入されているようです.注文ごとにこれに時間がかかる理由がまだわかりません.ただし、db-queryを実行するときは、いくつかの結合を実行する必要があり、_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
- 私はDB理論にあまり深くは入っていませんが、製品を小さく保つ必要があります.いずれにせよ、これは、プログラムがそれほど効率的ではないという意味でバグである可能性があります.
  
  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
- ええと...私は投稿名で始めるのが悪いことを読みました、そして他の答えは確かにエントリごとに複数の行を示しています(しかし私が何年もワードプレスで実行している私の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パーマリンクコードを作成して、何がスケーリングされ、何がスケーリングされないかを把握しました.;-)冗長なルールは、オプションテーブルに巨大な設定をもたらす可能性があり、データベースからプル(または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はそう言っており、あなたの言うことはこれをまったく説明していないので！)さらに、この設定をページの読み込みごとに1回プルする必要がある場合、なぜ効果によって投稿が増えるのですか?デシリアライズは_高速_ではありませんか?しかし、はい、確かに、私はコードにあるものではなく、意味のあるもののレベルで考えています.すべてのコードが意味をなすわけではありません.
  
  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
- ポインタオットプレスをありがとう.すべてのページの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
- ああ、そして、冗長なルールが何であるかが不明な場合、その要点は、そのタイプのすべてのデータを識別するために一般的な正規表現を使用する代わりに、各ページ、添付ファイル、およびカスタム投稿タイプであり、したがっていくつかのルールになります正規表現-繰り返しますが、ページ、添付ファイル、またはカスタム投稿タイプごとです.これだけで物事を大幅に遅くするのに十分ですが、実際のボトルネックは、実際には、そもそもルールのプルとアンシリアル化に関連しています.
  
  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
- したがって、単純な正規表現マッチングで解決できることは、最初からいくつかの仮定が適用されなくなったという理由だけで、ひどい混乱に肥大化します.動作が変更されていない特別な理由はありますか?古いリンクが壊れるので恐れますか?特に、最近はページと投稿の区別が人為的になっているように見えますが、それは別のトピックです.
  
  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=permalinks
  
  "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
- @ラファエル:ここの誰もがそれに同意すると思います.しかし、実際にWPコアにパッチを提供している私たち一人一人が知っているように、そしてそれらの618の検索結果のかなりの数が明らかにするように(それらはすべてのバグではありません、ところで:パッチとチェンジセットにも注意してください)、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
ワークフローQAの場合:

答えは次のとおりです.いいえ、これはパフォーマンスに関する優れたパーマリンク構造ではありません.

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