내 영구 링크 구조의 성능?

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-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 쿼리에 직접 삽입되는 것처럼 보입니다.다른 주문에 대해 더 오래 걸리는 이유를 여전히 알 수 없습니다.그러나 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
- Err,불쾌하지는 않지만 WP 코드를 철저히 연구하지 않고 답변을 거부하는 것은 의미가 없습니다.FWIW,나는 일반적으로 충분한 WP 코드를 작성,수정 및 최적화했으며,WP는 특히 코드를 영구 링크하여 스케일이 무엇이고 무엇이 아닌지 알 수 있습니다.;-) Verbose 규칙은 옵션 테이블에서 거대한 설정으로 이어질 수 있으며,데이터베이스 (또는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
- 코덱스는 "몇 가지 힌트"(Codex 참조)를 제공하며 전체 알고리즘을 구체적으로 지정하지는 않습니다.그러나 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는 게시물이라고 가정하기 때문입니다.포스트와의 영구 링크 충돌을 피하기 위해 2005 년 wp가 페이지를 도입했을 때 자세한 규칙이 도입되었습니다.이 문제를 개선하기 위해 여전히 여러 티켓 (패치 포함,일부 제외)이 있습니다.
  
  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
- 따라서 단순한 정규 표현식 일치로 해결할 수있는 것은 처음부터 일부 가정이 더 이상 적용되지 않기 때문에 끔찍한 혼란으로 가득 차 있습니다.동작이 변경되지 않은 특별한 이유가 있습니까?오래된 링크가 끊어 질 까봐 두렵습니까?특히 최근에는 페이지와 게시물의 구분이 인위적으로 보이지만 이는 또 다른 주제입니다.
  
  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
- @Raphael : 여기있는 모든 사람들이 그것에 동의 할 것이라고 생각합니다.그러나 실제로 WP 코어에 패치를 기여하는 우리 각자가 알고 있고,그 618 개의 검색 결과 중 상당수가 드러날 것입니다 (모든 버그는 아닙니다.btw : 패치와 변경 세트도 주목) .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을 얻게됩니다 ... 예쁘지 않은 영구 링크로 되 돌리지 않는 한 ...) 아마도 비 예쁜 영구 링크로 되돌려 야 할 것입니다.나는 생각한다.

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