Prestazioni della mia struttura permalink?

Question

Prestazioni della mia struttura permalink?

- 14
- 816 2010-10-29
Ho letto la discussione sulleprestazioni di diversipermalink sullamailinglist degli hacker di wp,su QUESTOforume su Google.

Tuttavia,non sono riuscito a dedurre se la struttura dipermalink che ho utilizzatonegli ultimi anni èbuona oppureno:

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

Questa combinazionemette ilnome delpost direttamente dopo/e la combinazione di anno,mesee giorno la rendepiù unicapoichémoltipostnameportano lo stessonome. L'aggiunta html è qualcosa che ho usatonegli ultimi 10 anni sulmioblog (ancheprima di wordpress),quindi èeredità.

Non so se questo sia unbene per lapermance o unmaleper leprestazioni,comeposso verificarlo?

(Gestiscoilblog da +10 annie ci sono circa 10.000post conmolti linkin)

link:

http://codex.wordpress.org/Using_Permalinks

http://www.google.com/search?q=wordpress+ categoria +permalink + rendimento

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

http://lists.automattic.com/pipermail/wp- hacker/2010-ottobre/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 risposta

voti

- 1
- 2010-11-12
Pongoil veto alla risposta accettata.La complessità delle regole di riscritturanon èin alcunmodo unamisuraper leprestazioni della ricerca di articoli.

Inparticolare,sembra cheiniziarei tuoipermalink coni nomi deipost sia sbagliato;vedere http://codex.wordpress.org/Using_Permalinks#Structure_Tags

Senza averesaminatoil codice di Wordpress,possoimmaginare chein qualchemodoindicizzanoi postin modogerarchico.Pertanto,le variabili utilizzatenei permalink dovrebberoessere ordinate da sinistra a destra dalla variabilepiùgenerale a quellapiù specifica utilizzata.Questaeuristicafavoriscefortementegli standard anno/mese/nome o categoria/nome.

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.
- "categoria/nome" èeffettivamentenotoe confermato come causa diproblemi diprestazioni se èpresente unagrande quantità dipagine.Non ètanto correlato alla velocità di ricerca quanto alla deduzione dell'oggetto corretto da serviree la complessità delle regole di riscrittura ** è ** completamente rilevante.
  
  `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
- Puoifornire un riferimento a un documento/codiceperfavore?Ho appena lettoil codice `(wp-include/rewrite.php`e` wp-include/query.php`);mentre sembra davvero orribilee inutilmente complicato,sembra chefondamentalmente leparti vengano raccoltee identificatee quindiinserite direttamentenelle query SQL.Non riesco ancora a capireperché questo dovrebbe richiederepiùtempoper ordini diversi.Ma quando vieneeseguita la db-query,devonoessereeseguiti diversijoine l'ordine _here_ è davveroimportante.Mi sembra di ricordare che MySQL èparticolarmentepessimonell'ottimizzazione dell'ordine deijoin.
  
  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
- Non sonotroppo approfonditonellateoria DB,ma devimantenerei prodottipiccoli.In ogni caso,questopotrebbeessere unbugnel senso chenon èprogrammatoin modoefficiente comepotrebbeessere.
  
  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
- Bene ... ho letto cheiniziare coni nomi deiposterapessimo E l'altra rispostamostraeffettivamentepiù righeper voce (maperilmioblog di 10.000post cheeseguo su wordpressper anniprobabilmentenon c'èmolto che cambio senzaperderemolti riferimenti).Non ho capito completamente latua risposta quie il "veto"però,cosa devofare quandometti il veto a una risposta????
  
  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
- Ho solo scritto "veto",nonesiste unatalefunzione qui.Ilpunto è che untempo diesecuzionepiùelevato è causato dapiù codiceeseguito o dal DBMS.Dalmomento chenon sono riuscito atrovare alcuna ragione che suggerisca che l'ordine diverso dei componenti URL dovrebbe aumentare la quantità di codiceeseguito,sostengo cheilmotivo risiedanelle query del database.Ma con cosìtantipost,forse qualsiasi ordine è lento _perché hai cosìtantipost_.Usiil caching?
  
  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
- Ehm,senza offesa,maporreil veto a una risposta senza aver studiato afondoil codice WPnon hamolto senso.FWIW,ho scritto,correttoe ottimizzato abbastanza codice WPin generalee codice WPpermalinkin particolare,per sapere cosa scalae cosano.;-) Regole dettagliatepossonoportare a un'enormeimpostazionenellatabella delle opzioni,chepoi deveessereestratta dal database (omemcached)e non serializzata ad ogni caricamento dellapagina.Ho visto quest'ultimo caso d'usoportare un serverbi-xeonmoderatamente caricato a una scansionenel 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
- Bene,allora dovrestiesserein grado difornirepiù dettagli di "nonessereprolisso".Cos'è la verbosità qui?L'ordine delle variabili èimportante?(dalmomento cheil Codex dice di sìe quello che dicinon lo spiega affatto!) Inoltre,se questaimpostazione deveesseretirata una voltaper ogni caricamento dipagina,perché l'effetto aumentapiùpost ci sono?La deserializzazionenon dovrebbeessere _veloce_?Ma sì,certamente,stopensando al livello di ciò che ha senso,non a ciò che ènel codice.Nontuttoil codice ha senso.
  
  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
- il Codex dà "Afew HINTS" (vedi Codex)e non specifica l'algoritmo completo.Tuttaviapunta a http://ottopress.com/2010/category-in-permalinks-considered-harmful/e http://comox.textdrive.com/pipermail/wp-testers/2009-January/011097.htmltuttiintutto c'è una sorta di attritotra lemiglioripratiche di url hackingnel campo dell'interazione uomo-computere leprestazioninel campo delmiglioramento delleprestazioni.
  
  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
- Grazieperilpuntatore ottopress.Sembra che lamodifica delle convenzioniin modotale che ogni URL dipaginainizi con "/page/"e ogni URL dipost con "/post/",rimuovendo l'univocità.Dovrestiesserein grado difarlo da solo,aggiungendoiltestofisso alla struttura delpermalink.Questa sarebbeprobabilmente unabuona decisione,comunque;cosa succede se ho unpost BARnella categoria FOOe unapagina BAR che è la sottopagina di FOO?Entrambi sarebberoindirizzati da `/foo/bar/` assumendo lo schema% category%/%postname%.O le lumache sono uniche almondo?
  
  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
- Oh,e da quanto ho capitonon averemoltipostinterrompe questo sistemama averemoltepagine,giusto?Da quando Wordpress ènato come sistema diblogging,questo aveva senso.Poi.
  
  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
- Sì,averemoltepaginee allegati è unmale con regole dettagliate,manon averemoltipost.Ilmotivo è che wppresume che sia unpost ameno che una regolanon specifichi diversamente.Regole dettagliate sono stateintrodotte quando wp haintrodotto lepagine,nel lontano 2005,alfine dievitare collisioni dipermalink coni post.Ci sono ancora diversiticket (alcuni conpatch,altri senza) che cercano dimigliorare le cose su questofronte.
  
  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,e,nel casonon sia chiaro quali siano le regole dettagliate,il succo è,ognipagina,allegatoe tipo dipostpersonalizzato,invece di utilizzare un'espressione regolaregenericaperidentificaretuttii dati di queltipo,finisce con diverse regolee quindiregex - dinuovo,perpagina,allegato otipo dipostpersonalizzato.Questo da solo è sufficienteper rallentare le cosein modo significativo,mail vero collo dibottiglia èin realtà correlato all'estrazionee alla deserializzazione delle regolein primo luogo.
  
  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
- Quindi ciò chepotrebbeessere risolto con un semplice abbinamento diespressioni regolari ègonfio di un orribilepasticcio soloperché alcuneipotesi dall'inizionon si applicanopiù.C'è unmotivoparticolareper cuiil comportamentonon è statomodificato?Pauraperchéi vecchi collegamenti si rompono?Inparticolare,la distinzionetrapaginee post sembra algiorno d'oggi artificiale,ma questo è un altro argomento.
  
  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
- "motivoper cuinon è cambiato" -> 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
- 618bug sono unmotivoperfarlo completamentenuovo,nonpermantenerlo.
  
  618 bugs are a reason to do it whole new, not to keep it.
  - 0
  - 2010-11-15
  - Raphael
- @ Raphael: sospetto chetutti qui saranno d'accordo su questo.Ma come sa ognuno dinoi cheeffettivamente contribuisce con lepatch al core WP,e come alcuni di quei 618 risultati di ricerca riveleranno (non sonotuttibug,btw:notate anche lepatche i changeset),gli sviluppatori del core WPnon lofannocommettereprontamente correzioni dibuge miglioramenti apportati.Inparticolare quando sonomiglioramentinonbanali.
  
  @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
- Ovviamente.Non vuoiessere responsabile di un'interruzione chenon hainemmeno codificato da solo.Ma riceviamo semprenuovefunzionalità;forse unblocco dellefunzionalitàfino a quando alcuniproblemi (sospetto che ci sianopiùbordiirregolariin WP)non vengonogestiti èin ordine?
  
  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
Soloperil controllo qualità delflusso di lavoro:

La risposta è: NO questanon è unabuona struttura dipermalinkper quanto riguarda leprestazioni.

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

Puoi controllareguardando la dimensione dell'opzione rewrite_rulesnel database.Se èpiccolo (cosa che credo dovrebbefare con questa struttura),non stai usando regole dettagliate.Al contrario,se vedipiù righeperpagina statica,stai usando regole dettagliatee non vabene.

sfortunatamente ... ci sono diverse righeperpagina statica GRIN.Quindi questaprobabilmentenon è unabuona struttura dipermalink ... hmmmm ... questo spiega unmessaggio dierrore che ho ricevutotempofa "Errore database WordPress Ho unpacchettopiùgrande di 'max_allowed_packet",ho dovuto aumentare questaimpostazionein 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
poi dinuovo ... se continui ad aggiungerepagineper anni otterrai automaticamentemax_allowed_packet,nonimporta cosa ... ameno chetunontorni anongraziosipermalink ... (penso) quindi ...peressere scalabileperi prossimi 30 anni:) Probabilmente dovròtornare apermalinknon carini.Credo.

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
Finché utilizzi regolenon dettagliate,latuapagina,le regolepergli allegatie itipi dipostpersonalizzati sonogeneriche.Quindii collegamenti carini sono abbastanza sicurinellapratica,purché utilizzino una strutturanon dettagliata.

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