Joomla.it Forum
Non solo Joomla... => Database => : salvocomplicazione 15 Jan 2010, 22:51:37
-
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 ;D)
2 - Eseguiamo noi l'operazione al costo di due ore di assistenza tecnica (che culo! :-X)
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 :o)
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.
-
a causa di querytyme tropo lunghe
----------------------------------
con joomla? ... e per far cosa? cioè, che sito è?
M.
-
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
-
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
-
..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.
-
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 ;D
Salvatore
-
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.
-
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
-
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ì?
-
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 ;D
-
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
-
... 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
-
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 ;D
se tutto va bene passo a quello online e vediamo cosa mi dice....
ci si aggiorna a breve....
-
ok... ci sono riuscito ;D
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
-
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
-
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.
-
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 (http://www.campanesionline.com).
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 ;D
grazie
salvatore
-
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? ::)
-
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
-
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
-
di fretta dicevo :(
volevo dire mod_newsflash e non mod_latestnews, sorry.
ciao
-
ops pardon!
a parte la svista, io il mod_newsflash è un po che non c'è l'ho più pubblicato.
ancora grazie.
magari rispondici pure in un momento che hai più tempo.
Salvatore
-
avevo visto nel codice un potenziale 'bug' che poteva causare il problema.
sul sito hai parecchi moduli che fanno riferimento alla tabella contents, prova a disabilitarli uno alla volta ed a verificare.
ciao,
marco
-
ok...
sono arrivato a disabilitare tre moduli dalla home page che fanno sicuramente riferimento alla tabella content, ma niente da fare.
dopo di che ho provato ad aprire un articolo di quelli presenti in home page, ed ho fato il debug della pagina.
I tempi di interrogazione della tabella content sono ancora alti.
inizia a venirmi qualche dubbio sul modulo "vedi anche".
Prima di concludere provo a disabilitarlo, ricarico la home page ed i tempi sono sempre alti.
Se vuoi, quando hai tempo, ti mando in pvt il debug della pagina se ti è utile.
Salvatore
-
...allora, la prima query è quella che gli serve per costruire l'homepage, infatti andando a cambiare il numero degli articoli esposti cambia il limit della query.
Quindi la prima è corretta, visto che nelle altre pagine non si ripete è un problema dell'homepage.
Rimane il problema sul perchè fà quella query su tutti gli articoli, ho disabilitato praticamente tutto.
M.
EDIT: lo fa anche nelle sezioni e nelle categorie, sempre con lo stesso meccanismo, la prima query con il limite che abbiamo stabilito nei parametri, la seconda tutto
-
stesso risultato pure da me ::)
-
in effetti, pare che la query sia nel com_content.
provate questo template per fugare i dubbi
<html>
<body>
<jdoc:include type="component" />
<jdoc:include type="modules" name="debug" />
</body>
</html>
in questo caso, tralasciando gli hacks al codice, l'intervento opportuno sarebbe sul db.
ho verificato che diversi campi della citata query, usati come filtro o come ordinamento, non hanno un indice associato.
ciò costringe mysql alla creazione di una tabella temporanea e qui i tempi di query crescono notevolmente.
prova a vedere se l'aggiunta degli opportuni indici ti risolve il problema.
ciao,
marco
-
marco, ma hai anche tu lo stesso problema?
Cioè è un bug?
Credo che sia dovuto ad un errata gestione del parametro riguardante gli articoli mostrati, quello che chiama #link
nel modulino dei parametri: principali->n,intro->n,colonne->n
praticamente fa ugualmente la query anche se tu imposti 0 e poi non li restituisce nel rendering della pagina, ma nel buffer dovrebbero esserci
.... segnaliamo come bug?
M.
-
la cosa per me si fa complessa ;D
eventualmente dopo mi potete segnalare come fare... sono un po acerbo su certe cose ;D
grazie
Salvatore
-
marco, anche col "tuo template" continua a farlo e lo fa anche se il template lo togli
M.
-
confermo anche io
ho appena fatto la prova :'(
Salvatore
-
beccato ;)
il problema, non è esattamente un bug, è in come è scritto il codice nella view frontpage del com_content.
la prima query legge i parametri da menù ed imposta correttamente il limit (quindi qui non c'è bug), subito dopo questa ve ne è una altra per ottenere il numero totale di articoli. quest'ultima (metodo getTotal nel model) esegue nuovamente la prima query senza il limit e conta il numero di records (ma che c... ) >:( .
ora, anche a sostituirla con un count(), si risparmierebbe un po' di memoria, ma non penso che si guadagni un granché in termini di velocità dato quanto detto prima a proposito di join e di indici.
le soluzioni a mio avviso sono due:
1.
provare ad agire sugli indichi/chiavi del db (più pulita, ma non facile)
2.
eliminare la seconda query e la paginazione dalla view (è un hack sul codice e qui non è, giustamente, molto amata come soluzione)
ciao,
marco
-
dimenticavo: ovviamente se la prima query impiega 17 secondi sarebbe opportuno l'intervento sul db.
ciao,
marco
-
ebbravo Marco :) ero lì in giro anch'io ... ma io volevo proprio rimuoverla :):):)
------------------------
è in come è scritto il codice nella view frontpage del com_content.
------------------------
..mi sa non solo nella view frontpage... infatti eliminando la paginazione si incontrano problemi negli altri componenti.
M.
-
ciao salvatore,
ho visto un errore 404 sul server e non so se siate stati voi od il provider.
fammi sapere se ti serve ancora di risolvere il problema, e nel caso se il problema era solo in home page.
BTW: 500 articoli e 13mb di db stanno anche ad indicare che il provider non è che si sia 'sbattuto' più di tanto nel fornire la macchina...
ciao,
marco
-
Ciao Marco,
ho appena acceso il pc, e anche io vedo la agina di errore 404.
Aimè credo proprio che mi hanno rinominato la root del sito affinchè restituisse un errore 404 per non affaticare il server.
E' ovvio che mi interessa risolvere il problema, e come detto oggi nei vari post a ruota dopo mau_develop ho la stessa problematica con gli stessi sintomi, solo che il suo server magari è più performante e non gli crea tanti problemi.
L'altro giorno parlando con l'assistenza tecnica del mio provider, mi ha detto che anche passando ad un servizio pro, ma non dedicato, il problema persisterebbe, e che per risolverlo avrei dovuto indicizzare il database.
Spero che troviamo al più presto una soluzione perchè il problema mi obblica a restare offline come puoi vedere.
grazie di tutto
Salvatore
ps. mi sa che è meglio la prima soluzione suggerita da mmleoni, che è anche il chiodo su cui batte il provider ;)
-
non so cosa loro intendono per indicizzare, ma indicizzare i contenuti non è banale e le altre tabelle non vedo dove debbano essere indicizzate, soprattutto se hai tolto il componente più rognoso che è la chat...
Secondo me sono messi malino anche loro.
Visto che te l'han tolto io proverei ad hostarlo su un servizio free,..così ...per curiosità...se hai tempo...
M.
EDIT: ci sono anche dei bei tool di analisi e risoluzione online,... stavo vedendo anch'io di incrementare un po' la velocità
http://www.websiteoptimization.com/services/analyze/
http://flumpcakes.co.uk/css/optimiser/
-
ho giocato un po' con il query analyzer: il problema principale è ORDER BY in coda alla query che non ha un indice da seguire e che costringe a usare una tabella temporanea.
non ricordo più la tua home se fosse la home classica o meno(com_content con view frontpage), nel caso prova queste impostazioni:
Ordinamento categoria : Nessuno, solo Ordine primario
Ordine primario : predefinito
togliendo l'ordinamento per categoria il sistema non dovrebbe più creare la tabella temporanea.
l'analisi delle query è un'operazione che però andrebbe fatta pagina per pagina: la vedo dura :(
per curiosità, se hai una copia speculare del sito, quali sono i tempi sul tuo pc? perchè i tempi del provider mi quadrano poco...
ps non è che l'ip del server sql è 127.0.0.1 ? ;)
ciao,
marco
-
Ciao mau_develop,
ti ho mandato un messaggio pvt, mentre per quanto rigurda il dominio non è bloccato del tutto, riesco ad usare la posta ed a vedere il db tramite phpmyadmin.
Ho anche il sito replicato sul mio pc, e anche se non riesco ad accedere al pannello dicontrollo qualcosina riesco a fare, ma se preferisci possiamo anche provare un hosting free per qualche test.
ps.
con l'inglese sono una frana ;D
-
si ma Marco, il tuo lavoro è splendido, perchè molto professionale, ma non ho mai sentito di utenti fermati per qs problemi con joomla...
M.
-
Ciao Marco,
sul sito non posso più accedere, mi dovrei appoggiare a quello locale ma quando l'ho replicato qualcosa non è andato a buon fine perchè quando provo ad accedere al backend mi restituisce una pagina bianca.
ho giocato un po' con il query analyzer: il problema principale è ORDER BY in coda alla query che non ha un indice da seguire e che costringe a usare una tabella temporanea.
non ricordo più la tua home se fosse la home classica o meno(com_content con view frontpage), nel caso prova queste impostazioni:
Ordinamento categoria : Nessuno, solo Ordine primario
Ordine primario : predefinito
togliendo l'ordinamento per categoria il sistema non dovrebbe più creare la tabella temporanea.
l'analisi delle query è un'operazione che però andrebbe fatta pagina per pagina: la vedo dura :(
per curiosità, se hai una copia speculare del sito, quali sono i tempi sul tuo pc? perchè i tempi del provider mi quadrano poco...
ps non è che l'ip del server sql è 127.0.0.1 ? ;)
ciao,
marco
Ti mando in pvt il debug del sito in locale e se vuoi anche l'html che forse da li riesci a capirci che tipo di configurazione abbia.
l'ip del sito locale o di quello online?
Salvatore
-
Ciao mau_develop forse ne sono la prova ::)
e comunque non credo che siamo solo noi due ad avere lo stesso problema
chissà quanti altri ne sono afflitti e non se ne rendono conto..... andando poi a finire su server dedicati :-X
si ma Marco, il tuo lavoro è splendido, perchè molto professionale, ma non ho mai sentito di utenti fermati per qs problemi con joomla...
M.
-
hai ancora il sito off-line
sinceramente, non si fa così, ad un mio amico l'hosting ha cambiato macchina senza fiatare..
non faccio nomi ma il mercato è molto vasto, senza andare all'estero ovviamente.
non si fa così, non si mette offline un sito joomla, perchè sanno benissimo che per un sito che lavora ne hanno cento o più che non lo vede nessuno..
>:(
-
Ciao Francesco,
la cosa che mi fa arrabbiare e che lo fanno senza nessun preavviso!! senza perdere neanche un secondo a scrivere due righe per informarti!!
E dire che mi sono raccomandato più volte di avvisarmi! sarei stato io stesso a mettere offline il sito senza che loro si sarebbero dovuti sforzare minimamente, dandomi altresì la possibilità di continuare a svolgere i miei test assieme a voi.
:-X :-X :-X :-X :-X :-X :-X
Salvatore
-
... ma non ho mai sentito di utenti fermati per qs problemi con joomla...
M.
ed infatti, come ho detto a salvatore in risposta ad un pm, mi è venuto il dubbio che non sia su un server ma su un desktop! non ridete, non avete idea di cosa veda girando le varie webfarm di milano :o
500 articoli e 13 mega di db non possono dare origine ad una query di 60 secondi!! ma siete in 10000 su quel server? o è un desktop con dei cavolo di dischi sata da 7200 giri e magari in raid software?
il tuo hosting non mi convince, e come dice 56francesco, il mercato è molto vasto. ;)
ciao,
marco
-
:D :D
http://www.robtex.com/dns/campanesionline.com.html
M.