Производительность моей структуры постоянных ссылок?

Question

Производительность моей структуры постоянных ссылок?

- 14
- 816 2010-10-29
Я прочитал обсуждение эффективности различных постоянных ссылок в списке рассылки wp hackers,на ЭТОМ форуме и в Google.

Однако я не мог понять,хороша ли структура постоянных ссылок,которую я использовал в последние годы:

<код>/%postname%-%year%%monthnum%%day%.html

Эта комбинация помещает имя сообщения сразу после/,а сочетание года,месяца и дня делает его более уникальным,поскольку многие имена сообщений имеют одно и то же имя. Добавление html - это то,что я использовал последние 10 лет в своем блоге (даже до 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.Я до сих пор не понимаю,почему это должно занимать больше времени для разных заказов.Но когда выполняется 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
- Я не слишком углубляюсь в теорию БД,но вы должны делать продукты небольшими.В любом случае это может быть баг в том смысле,что он запрограммирован не так эффективно,как мог бы.
  
  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 сообщений,который я веду на wordpress в течение многих лет,я,вероятно,не так много меняю,не теряя много ссылок).Я не совсем понял ваш ответ здесь и "вето",что мне делать,если вы наложили вето на ответ????
  
  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
- Я только написал "вето",здесь нет такой функции.Я хочу сказать,что более высокое время выполнения вызвано большим количеством выполняемого кода или СУБД.Поскольку я не смог найти никаких причин,по которым можно было бы предположить,что другой порядок компонентов 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) и десериализовать при каждой загрузке страницы.Я видел,как последний вариант использования заставлял умеренно загруженныйbi-xeon сервер сканировать в 2006 году.
  
  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
- Что ж,тогда вы должны иметь возможность дать больше конкретики,чем «не будьте многословны».Что здесь за многословие?Имеет ли значение порядок переменных?(поскольку Кодекс говорит,что это так,а то,что вы говорите,совершенно не объясняет этого!) Кроме того,если этот параметр нужно извлекать один раз при загрузке страницы,почему эффект усиливается с увеличением количества сообщений?Разве десериализация не должна быть быстрой?Но да,конечно,я думаю на уровне того,что имеет смысл,а не на уровне кода.Не весь код имеет смысл.
  
  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/`,устраняя однозначность.Вы должны иметь возможность сделать это самостоятельно,добавив фиксированный текст в структуру постоянной ссылки.В любом случае,это,вероятно,было бы хорошим решением;что произойдет,если у меня есть BAR сообщения в категории FOO и BAR страницы,которая является подстраницей FOO?Оба будут адресованы `/foo/bar/`,предполагая схему% category%/%postname%.Или слизни уникальны в мировом масштабе?
  
  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
Только для контроля качества рабочего процесса:

Ответ: НЕТ,это плохая структура постоянных ссылок с точки зрения производительности.

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