come si indicizzano le tabelle del db di joomla?

[salvocomplicazione]

Buona sera a tutti,
premetto che non sono nuovo di joomla e che purtroppo nelle ultime ore mi trovo in forte difficoltà con un mio sito.
Purtroppo negli ultimi giorni a causa di querytyme tropo lunghe il provider mi ha bloccato il sito in quanto rischiava di mettere in ginocchio il server che ormai da tre anni lo ospitava.

Mi hanno comunicato che per risolvere il problema ho le seguenti opzioni:

1 - Sistemate autonomamente gli indici del db in modo da velocizzare le queries sul db e diminuire il carico del server (che devo ancora capire come si fa  )

2 - Eseguiamo noi l'operazione al costo di due ore di assistenza tecnica (che culo!  )

3 - Passate ad una soluzione completamente dedicata,un server che verrà utilizzato solo per il vostro dominio,sul quale potrete effettuare il carico che desiderate. (in poche parole mi svenano  )

Purtroppo l'opzione 2 e 3 mi stanno un tantino antipatiche e non mi resta che mettere in pratica l'opzione 1.

Qualcuno può darmi qualche dritta su come si fa la suddetta operazione?

Attualmente è già tre giorni che ho il sito offline!! help 

Un grazie in anticipo a tutti.

[mau_develop]

a causa di querytyme tropo lunghe
----------------------------------

con joomla? ... e per far cosa? cioè, che sito è?


M.

[mmleoni]

query time non mi dice niente

aiutami un poco. hai detto che il sito è on line da tre anni quindi (e vado a tentativi):
. quanti articoli hai pubblicato?
. quali componenti hai installato?
. hai creato componenti tu stesso?
in altri termini, qual è la dimensione del dB?
. quante visite hai al giorno?
. non è che stai loggando tutti gli accessi a joomla?

=== my two cents ===
se stimano l'intervento in due ore o sono dei gran fighi o dei gran paraxxxx, tertium non datur

ciao,
marco
 

[salvocomplicazione]

intanto grazie ragazzi per il vostro interessamento.
inizio con il rispondere a mau_develop

a causa di querytyme tropo lunghe
----------------------------------

con joomla? si... e per far cosa? a dir loro ogni sorta di interrogazione verso il db, con tempi che prima superavano anche i 60 secondi per singola query cioè, che sito è? www.campanesionline.com


M.

Nel frattempo sto per rimettere online il mio sito in accordo con il provider per fare ulteriori test.
Il sito è ospitato su un server condiviso o meglio i classici host entry level o roba simile.
Durante un colloquio telefonico con il servizio di assitenza di questo provider mi è stato detto che il mio sito è quello che genera più traffico tra tutti i siti ospitati su quel server.
di articoli c'è n'è un totale circa 500 senza contare tutte le foto (oltre 2000) ecc... per un totale di circa 700 mb di roba tra i file di joomla & company e materiale vario.

Il sito è il seguente: www.campanesionline.com sviluppato dal sottoscritto più una diecina di collaboratori che inseriscono di volta in volta notizie in merito al nostro paesino.

query time non mi dice niente

aiutami un poco. hai detto che il sito è on line da tre anni quindi (e vado a tentativi):
. quanti articoli hai pubblicato? al momento 537 e più di duemila foto
. quali componenti hai installato? ti mando mp
. hai creato componenti tu stesso? no
. in altri termini, qual è la dimensione del dB? al momento e circa 13mb comprensivo dele tabelle di joomlastat
. quante visite hai al giorno? mediamente 200/250 giornaliere con una media di 3000 pagine
. non è che stai loggando tutti gli accessi a joomla? cosa significa?

=== my two cents ===
se stimano l'intervento in due ore o sono dei gran fighi o dei gran paraxxxx, tertium non datur

ciao,
marco
 

intanto grazie mille

[mau_develop]

..mah! ..il sito indubbiamente è grosso ma non da fare query di 60 sec, a meno di qualche ricorsività strana.
Il problema dell'indicizzazione non dovrebbe esistere per 500 articoli e il db di joomla è costruito sufficientemente bene.

L'unica cosa che mi lascia dei dubbi è la chat.
E' aggiornata? ..non mi sembra che abbia "una storia", piuttosto instable, e le prime versioni sono state corrette per qs problema

Removed the redundant MySQL database and table creation functions in the phpfreechat script.

non vorrei dire stupidate ma la tua è una 1.2, ci sono altri 6 aggiornamenti dopo...

M.

[salvocomplicazione]

Guarda non so che dire....
purtroppo nel giro di una settimana mi hanno bloccato il dominio ben 2 volte.
Dopo il primo sblocco avevo già rimosso firestat, che usava molto il db, ed eliminato le sue tabelle; il sito andava spedito come una scheggia ma dopo due giorni è arrivato il secondo stop, motivazione query time ancora alto.... a me sembrava il contrario!
Addirittura oggi ho disattivato anche joomlastat, ma a differenza della volta scorsa ora il sito va a singhiozzi...

Scusa la mia ignoranza, ma fino a che punto può incidere su un intero sito una chat non perfettamente aggiornata?
intanto graazie per il suggerimento, provvedo subito ad aggiornarla e speriamo che se è lei i problemi si risolvano

Salvatore

[mau_develop]

Scusa la mia ignoranza, ma fino a che punto può incidere su un intero sito una chat non perfettamente aggiornata?
-----------------------------------------------
non è tanto una chat o qualsiasi altro addons, io ti ho detto la chat perchè ho guardato un po' il sito e quello era il componente più indicato a generare casini.
Sono andato sul sito dello sviluppatore e ho visto che usa Ajax e che il pacchetto aveva problemi di ridondanza di query...

basta uno script fatto male che ad ogni refresh mi attraversa chissà quante tabelle cercando nei contenuti chissà cosa e il tutto ripetuto magari da 20 utenti che chattano... puoi immaginare quel povero db.

Comunque devi per forza avere o qualche tabella con contenuti "sostanziosi" o qualche query fatta male.
A me è successo una volta (ho dovuto finire su un dedicato) per un database con 180.000 righe su una tabella "donatori"; tutte le volte che facevi estrazioni e incrociavi le tabelle venivano query da più di 60sec, infatti riusciva a mandare in timeout.

Capita! Non è che con 8 euro l'anno si può pretendere chissà che..

M.

[salvocomplicazione]

Ciao mau_develop,
intanto molte grazie per il tuo interessamento.

Ieri pomeriggio purtroppo il server andava veramente a singhiozzi per cui non ho avuto modo di apprezzare le modifiche che mi avevi suggerito.

Infatti in serata ho messo offline il sito onde evitare di essere dinuovo accusato di essere il colpevole del sovraccarico del server.

Oggi credo proprio che disinstallerò del tutto la chat, che tanto per adesso non mi serve evediamo cosa succede.

Mentre il server che mi ospita non è quello da 8 euro
li ne ho un'altro di sito ma nada problemi per il momento 

ancora grazie
Salvatore

[mau_develop]

scusa, ma sono incasinato, sto scrivendo un plugin mentre preparo il pranzo...
comunque, rispondendo ad un'altro post mi sono reso conto di una cosa, non ti ho ancora suggerito uno dei primi test che si potevano fare.... il debug o comunque qualcosa che ti misura la durata delle query, anche questo sarebbe un test interessante.
Ti ho spiegato i motivi per cui "sospetto" della chat, ma non è detto che sia quella... spero che anche tutto il resto dei componenti che hai aggiunto non facenti parte della base joomla, siano aggiornati (... non ti chiedo la vers di J. perchè spero tu sia all'ultima ;, anzi lo do per scontato..)

M.

...ma portarlo in locale e spulciarselo un po' lì?

[salvocomplicazione]

joomla è aggiornato.. almeno quello, e a parte la chat bene o male il resto dei componenti direi di si.

ti mando in pv la lista completa

in locale non saprei come spulciarlo 

eventualmente lo farò in serata e vediamo cosa mi salta fuori 

[salvocomplicazione]

debug..... um allora vediamo un po
all'avvio della home page genera ben 62 query attualmente

la durata della query è quella qui di sotto?

Informazioni Profilo

Application afterLoad: 0.000 seconds, 0.23 MB
Application afterInitialise: 0.142 seconds, 4.10 MB
Application afterRoute: 0.261 seconds, 6.41 MB
Application afterDispatch: 0.618 seconds, 10.75 MB
Application afterRender: 0.621 seconds, 10.84 MB

Utilizzo Memoria 11459792

Anche perchè dentro il resto delle 62 query non ho visto niente che si riferisse ai tempi delle stesse.

fammi sapere così vediamo come procedere

[mau_develop]

... e hai ragione anche tu..
credo però tu sia online, perchè ho provato qs script che da i risultati che vuoi, solo che visualizza le query..

http://www.cmsmarket.com/resources/dev-corner/104-display-joomla-database-query-runtimes-with-debug-info

M.

cmq 64 query non sono tante, però cominciano a diventare un numero importante.
Il mio è un sitarello e ne ho 12

[salvocomplicazione]

Grazie mau_develop,
ora provo a fare la modifica segnalata ma in locale....

in locale (sto usando un mac snow leopar) dove ho già provato a replicare il sito, installando mamp, che tra l'altro funziona egregiamente, no problem con nuove installazioni di joomla, ma quando provo ad accedere al backend del mio vecchio sito, replicato in locale, mi restituisce solo una pagina bianca, pertanto mi devo arrangiare modificando a mano il file configuration.php...

ora vado a vedere il file che è da modificare e vediamo cosa succede 

se tutto va bene passo a quello online e vediamo cosa mi dice....
ci si aggiorna a breve....

[salvocomplicazione]

ok... ci sono riuscito 
ho fatto la modifica prima in locale  e successivamente sul sito online, i tempi delle query vengono fuori in millisecondi.
Ho notato che esegue due volte la stessa query sulla tabella dei contenuti....

incollo qui la parte della query che dicevo:

#
#
(!!!!! 4040.95649719): SELECT a.id, a.title, a.alias, a.title_alias, a.introtext, a.fulltext, a.sectionid, a.state, a.catid, a.created, a.created_by, a.created_by_alias, a.modified, a.modified_by, a.checked_out, a.checked_out_time, a.publish_up, a.publish_down, a.images, a.attribs, a.urls, a.metakey, a.metadesc, a.access, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(':', a.id, a.alias) ELSE a.id END AS slug, CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(":", cc.id, cc.alias) ELSE cc.id END AS catslug, CHAR_LENGTH( a.`fulltext` ) AS readmore, u.name AS author, u.usertype, g.name AS groups, u.email AS author_email, cc.title AS category, s.title AS section, s.ordering AS s_ordering, cc.ordering AS cc_ordering, a.ordering AS a_ordering, f.ordering AS f_ordering
  FROM jos_content AS a
  INNER JOIN jos_content_frontpage AS f
  ON f.content_id = a.id
  LEFT JOIN jos_categories AS cc
  ON cc.id = a.catid
  LEFT JOIN jos_sections AS s
  ON s.id = a.sectionid
  LEFT JOIN jos_users AS u
  ON u.id = a.created_by
  LEFT JOIN jos_groups AS g
  ON a.access = g.id
  WHERE 1
  AND a.access <= 2
  AND a.state >= 0
  ORDER BY  f.ordering
  LIMIT 0, 10
#
(!!!!! 36841.1540985): SELECT a.id, a.title, a.alias, a.title_alias, a.introtext, a.fulltext, a.sectionid, a.state, a.catid, a.created, a.created_by, a.created_by_alias, a.modified, a.modified_by, a.checked_out, a.checked_out_time, a.publish_up, a.publish_down, a.images, a.attribs, a.urls, a.metakey, a.metadesc, a.access, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(':', a.id, a.alias) ELSE a.id END AS slug, CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(":", cc.id, cc.alias) ELSE cc.id END AS catslug, CHAR_LENGTH( a.`fulltext` ) AS readmore, u.name AS author, u.usertype, g.name AS groups, u.email AS author_email, cc.title AS category, s.title AS section, s.ordering AS s_ordering, cc.ordering AS cc_ordering, a.ordering AS a_ordering, f.ordering AS f_ordering
  FROM jos_content AS a
  INNER JOIN jos_content_frontpage AS f
  ON f.content_id = a.id
  LEFT JOIN jos_categories AS cc
  ON cc.id = a.catid
  LEFT JOIN jos_sections AS s
  ON s.id = a.sectionid
  LEFT JOIN jos_users AS u
  ON u.id = a.created_by
  LEFT JOIN jos_groups AS g
  ON a.access = g.id
  WHERE 1
  AND a.access <= 2
  AND a.state >= 0
  ORDER BY  f.ordering

dove nella prima il tempo di esecuzione è abbastanza ragionevole, mentre al secondo passaggio non è più la stessa cosa anzi....
Come si può fare per ridurre i tempi di esecuzione di questa query?
Da un analisi veloce, di tutte è la query che ha il query time più alto di tutte

grazie
salvatore

[mmleoni]

ciao,
difficilmente si potrà ottimizzare la query in questione, data tutta la serie di left join.
la prima prende solo i primi 10 articoli, la seconda tutti: ed ecco il problema!
la domanda è perché effettua la seconda query? su che pagina è? magari ti basta imporre un limite agli articoli visualizzati per pagina.

non penso che nel caso specifico serva a molto, ma hai provato ad ottimizzare le tabelle in questione?

ciao,
marco

[mau_develop]

ciao Marco, sai che anche a me da' lo stesso output?... anch'io stavo cercando di capire perchè..., non vorrei che fosse lo script (magari tu che hai + capacità prova a dargli un'occhiata)
ovviamente avendo molti meno articoli i miei tempi sono inferiori...

M.

[salvocomplicazione]

Ciao mmleoni,
la query si riferisce alla home page, la quale mostra l'intro di solo 10 articoli, dopo di che basta non ha neanche i link per altri articoli se non che lo scorrimento delle pagine contenente altri articoli.

Volendo puoi visualizzare la home del mio sito per rendertene conto di persona cliccando qui.

Per l'ottimizzazione della tabella in questione c'ho già pensato ed ho anche provveduto a installare un plugin che lo fa in automatico, per tutte le tabelle del db ogni 24 ore..... ma questo solo di recente e cioè un paio di giorni fà, mentre la query è di ieri sera.

Stamane ho riattivato il debug per qualche secondo, giusto il tempo di aprire la home e vedere il query time, e poi l'ho subito disattivato.
Purtroppo la query in oggetto non è migliorata per niente anzi!

Speriamo di trovare qualche soluzione altrimenti è un bel casotto 

grazie
salvatore

[salvocomplicazione]

Buondì a tutti 
io la butto li perchè non so più che fare...
Ma se io archiviassi un po di articoli, secondo voi cambierebbe qualcosa? 

[mmleoni]

scusate ma oggi sono un poco di fretta (di tanto in tanto dovrei fare anche il lavoro per cui mi pagano ) e quindi non ho molto tempo per verificare: quindi lo dovete fare voi

mi pare che il problema possa essere il mod_latestnews.
provate a disabilitarlo.

ciao,
marco

[salvocomplicazione]

Ciao Marco,
intanto grazie ancora per l'interessamento e per il tempo che ci dedichi.

Ho appena applicato il tuo suggerimento, ma così facendo ho ridotto di una query (query che non avevo riportato nei messaggi precedenti ma che aveva dei tempi di interrogazione pure lei di circa 16 secondi, e come lei anche quella degli articoli più letti) ma i tempi della query incriminata non accennano a scendere 

#
(!!!!! 1714.94483948): SELECT a.id, a.title, a.alias, a.title_alias, a.introtext, a.fulltext, a.sectionid, a.state, a.catid, a.created, a.created_by, a.created_by_alias, a.modified, a.modified_by, a.checked_out, a.checked_out_time, a.publish_up, a.publish_down, a.images, a.attribs, a.urls, a.metakey, a.metadesc, a.access, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(':', a.id, a.alias) ELSE a.id END AS slug, CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(":", cc.id, cc.alias) ELSE cc.id END AS catslug, CHAR_LENGTH( a.`fulltext` ) AS readmore, u.name AS author, u.usertype, g.name AS groups, u.email AS author_email, cc.title AS category, s.title AS section, s.ordering AS s_ordering, cc.ordering AS cc_ordering, a.ordering AS a_ordering, f.ordering AS f_ordering
  FROM jos_content AS a
 
#
(!!!!! 39402.0080566): SELECT a.id, a.title, a.alias, a.title_alias, a.introtext, a.fulltext, a.sectionid, a.state, a.catid, a.created, a.created_by, a.created_by_alias, a.modified, a.modified_by, a.checked_out, a.checked_out_time, a.publish_up, a.publish_down, a.images, a.attribs, a.urls, a.metakey, a.metadesc, a.access, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(':', a.id, a.alias) ELSE a.id END AS slug, CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(":", cc.id, cc.alias) ELSE cc.id END AS catslug, CHAR_LENGTH( a.`fulltext` ) AS readmore, u.name AS author, u.usertype, g.name AS groups, u.email AS author_email, cc.title AS category, s.title AS section, s.ordering AS s_ordering, cc.ordering AS cc_ordering, a.ordering AS a_ordering, f.ordering AS f_ordering
  FROM jos_content AS a

Salvatore