@francois007 said:
Secondo il mio modesto parere il cloud è sprecato per un sito che saltuariamente registra dei picchi di 1500/2000 visitatori.
Opterei per un buon piano professionale ottimizzato per joomla...
Saluti.
Infatti anche secondo me aumentando le risorse e basta spenderei soldi e basta senza concentrare le risorse sulla criticità del mio caso.
Conosci qualcuno che fornisce tale soluzione? grazie
La soluzione che ho acquistato è la seguente
keliweb.it/cloud-hosting/offerte-cloudhosting.php?product=h4
Ma anche oggi ho avuto gli stessi problemi. Credo di dover passare ad un server dedicato. Che ne pensate?
Potete vedere nel link uno screenshot dell'utilizzo delle risorse. Da come si evince è tutto ok su ram, cpu e I/O, ma non nei processi di immissione.
Si, più il secondo paragone. Anche perchè non sono accessi, ma processi contemporanei. Però se il processo è complicato (ad es. query pesanti) ci mette di più a terminare e non lascia il posto agli altri.
ciao
Quindi, potrei ipotizzare che il timeout derivi dall'attesa di troppe query, comunque domani e dopodomani ci sono i match e lo metterò alla prova. Vi farò sapere.
Grazie a tutti per ora!!
@LorenzoRoma said:
Domanda senza polemica: ma se "ci sono 55-60 connections, ma ne vengono soddisfatte solamente 35" cosa c'entra quanto è pesante Joomla?
Perdona l'ignoranza, ma le connections derivano da richieste di query e di script php o mi sbaglio?
L'idea che mi sono fatto è che accedendo moltissimi utenti allo stesso momento creano molte richieste a livello di query ed esecuzione di script php, se l'hosting ne concede al massimo 35 per volta quelle 20-25 in più non le soddisfa.
Ha, dimenticavo, il sito in questione è questo tribunastadio.it
Grazie delle risposte, analizzando l'utilizzo risorse in cpanel praticamente il collo di bottiglia sta nelle connections simultanee. Rispetto ad utilizzo CPU, banda e RAM è tutto sotto crontrollo.
Praticamente vedo che in certi momenti ci sono 55-60 connections, ma ne vengono soddisfatte solamente 35, che è il limite appunto dell'hosting cloud in questione.
Ora, come dicevo, ho snellito le query ulteriormente, visto che utilizzavo un componente per la gestione dei risultati calcistici per joomla che ne aveva veramente troppe ed in generale ogni pagina si attesta su 15mb di ram e 20-25 query al massimo.
Dopodichè utilizzo il componente jotcache per joomla cosicchè le pagine vengano cachate (con scadenza 5 minuti, visto che i risultati si aggiornano molto spesso) e quindi le query suddette e l'utilizzo di memoria non si applicano ad ogni utente ma molto meno.
Aggiungo un'ultima cosa. Prima tale sito era realizzato in asp con db mssql, realizzato circa 10 anni fa e quindi molto più snello rispetto ai cms (comodi ma più pesanti) di ora, e girava senza problemi fino allo scorso su un hosting aruba condiviso: questa è la notizia più eclatante visto che ora con una spesa di circa 700 € l'anno non ce la fa a girare, mentre prima con 30 € l'anno funzionava. E' chiaro che è questione di codice.
che ne pensate?
Ciao a tutti, ho realizzato un sito web calcistico dove vengono inseriti tutti i risultati del calcio dilettantistico della regione, con migliaia di accessi simultanei tutti concentrati in circa 3-4 ore, durante le partite e dopo.
Sono circa 3 weekend che provo soluzioni diverse di hosting. All'inizio con hosting condiviso professionale e via via aumentando le risorse. Per farla breve il fine settimana scorso tenevo il sito su un cloud con disco ssd, 2gb ram e 35 connections e, anche se andava molto meglio rispetto alle volte precedenti, ad un certo punto l'hosting non ce la faceva a rispondere a tutte le richieste e a volte mostrava la pagina con numero massimo di richieste raggiunto (che non è il massimo).
Il CMS che utilizzo è joomla e dall'inizio l'ho ottimizzato sempre di più le query, togliendo quelle inutili, togliendo tutto quello che non serve, sfruttando la cache del del server, comprimendo i css, js, e l'html, ma ancora non ci siamo.
L'ordine dei visitatori è di circa 1.500 / 2.000 simultanei.
Cosa potrei fare di più? grazie 
