Parametri valutazione hosting

[teo80]

Salve a tutti,
da un po' compro hosting condivisi su vari provider.
Da quelli italiani, a qualcuno americano a qualcuno indiano.
Dove mi trovo bene con uno, mi trovo male con l'altro.
Qualcuno fa buona assistenza ma va male come hosting, qualcun'altro va bene ma non fa assistenza quando serve.
Ora io vi chiedo: quanto carico mi aspetto possa sopportare uno shared hosting da una 20ina di euro l'anno tenendo conto che è un sito dinamico (ASP.NET + MYSQL ..strana accoppiata ma funziona ) ?
Nel senso, posso aspettarmi che "regga" 1000 visite al giorno ? 10.000 ?
Io è qui che non riesco proprio ad orientarmi !
Potrei comprarmi un VPS ma... sono soldi buttati per 1.000 visite al giorno ? E per 10.000 visite al giorno ?
Diciamo, mi piacerebbe qualche indicazione stile tabella :
Per 10 utenti al giorno -> Questo hosting
Per 100 -> questo
per 1.000 -> questo
etc...

Grazie anticipatamente

[Ste]

Ciao Teo, benvenuto Non esiste una tabella come quella che chiedi, ne è possibile farla Semplicemente esistono diverse soluzioni di hosting, da shared a dedicate e tocca a te valutare provider (fascia di posizionamento: lowcost, intermedio, professionale).

Se ci fai un esempio reale basato su tuoi siti si può ragionarci meglio

[teo80]

Ad esempio uno degli hosting attuali che ho mi limita il numero di connessioni al database mysql a 5 (spesso ho l'errore : has exceeded the 'max_user_connections' resource (current value: 5))

Che mi dice che il numero massimo di connessioni "concorrenti" (almeno credo) è 5.
Cioè un po' pochino.
Visto che se mi si collegano 5 utenti insieme di sicuro il sito non andrà..

[Valeriano Manassero]

Ad esempio uno degli hosting attuali che ho mi limita il numero di connessioni al database mysql a 5 (spesso ho l'errore : has exceeded the 'max_user_connections' resource (current value: 5))

Che mi dice che il numero massimo di connessioni "concorrenti" (almeno credo) è 5.
Cioè un po' pochino.
Visto che se mi si collegano 5 utenti insieme di sicuro il sito non andrà..

E che te ne fai di 5 connesioni db contemporanee? Applicativo scritto coi piedi?

[Ste]

Ad esempio uno degli hosting attuali che ho mi limita il numero di connessioni al database mysql a 5 (spesso ho l'errore : has exceeded the 'max_user_connections' resource (current value: 5))

Che mi dice che il numero massimo di connessioni "concorrenti" (almeno credo) è 5.
Cioè un po' pochino.
Visto che se mi si collegano 5 utenti insieme di sicuro il sito non andrà..

Si è quello, si tratta di un limite abbastanza comune, che quasi tutti i provider impongono, come ti dice Valeriano (a modo suo) dovresti vedere cosa fa si che tu abbia quelle connessioni. Sarebbe però utile anche capire di quale fascia di servizio parliamo, lowcost?

[guest]

Beh, dovrebbero bastare anche 10-15 utenti online nello stesso momento per far scattare il limite delle 5 connessioni.

sono 5 connessioni nello stesso millisecondo (questa è la durata di una query scritta bene) fatte dallo stesso username mysql, se hai 10-15 utenti online non è difficile che il server si trovi a gestire 5 connessioni nello stesso istante.

[Uno]

Beh, dovrebbero bastare anche 10-15 utenti online nello stesso momento per far scattare il limite delle 5 connessioni.

sono 5 connessioni nello stesso millisecondo (questa è la durata di una query scritta bene) fatte dallo stesso username mysql, se hai 10-15 utenti online non è difficile che il server si trovi a gestire 5 connessioni nello stesso istante.

Al di la che ci vuole un sito mostruoso (ma mostruoso) per avere pù di 5 connessioni nello stesso millisecondo (o una applicazione scritta con piedi e 64 query solo per scrivere "benvenuto visitatore" in alto a destra) ma che questo crei più di tanti problemi al sito è esagerato.
Al massimo la pagina ritarderà di un paio di millisecondi....

[guest]

No, se ti vien fuori l'errore la pagina non ritarda, ti vien fuori il pataccone di PHP con scritto: Warning!

[Uno]

No, se ti vien fuori l'errore la pagina non ritarda, ti vien fuori il pataccone di PHP con scritto: Warning!

Mica viene fuori l'errore se superi il numero d query, ti mette in coda.
Certo se il server è un nintendo e prima di servire le tue query ci mette mezz'ora magari va in timeout tutto lo script. Ma se anche uno per qualche strano motivo facesse 6 o 10 query nello stesso millisecondo non si blocca il sito su un server normale.
Se poi è un "tutto illimitato" allora il discorso potrebbe cambiare.

[Valeriano Manassero]

Beh, dovrebbero bastare anche 10-15 utenti online nello stesso momento per far scattare il limite delle 5 connessioni.

sono 5 connessioni nello stesso millisecondo (questa è la durata di una query scritta bene) fatte dallo stesso username mysql, se hai 10-15 utenti online non è difficile che il server si trovi a gestire 5 connessioni nello stesso istante.

Vedi guest, il tuo discorso calza perchè, probabilmente, sei tu a dover sopperire alle porcate scritte nel codice del 90% dei siti che girano nel mondo. (non è che li hosti tutti tu, ma era per dare l'idea )

La verità è che quando parlo di 3 tier, non lo faccio per bullarmi o pisciare lungo, ma solo perchè un sano Business Object di mezzo, renderebbe un sito più manutentibile, più sicuro e, soprattutto non sfangherebbe i maroni al DB risparmiando un sacco di risorse.
L'applicativo deve chiedere i dati al BO e solo e SEMPRE al BO. Sarà poi il BO a processare, secondo una serie di strategie, le richieste in un determinato ordine e/o pool.
A quel punto, sempre secondo delle chiare regole di richiesta, il BO userà UNA connessione per gestire le richieste e magari, se è scritto bene farà anche un po' di caching.
Passare da una connessione ad un POOL è cosa buona e giusta quando la concorrenze delle richieste è tale da dover cominciare ad impattare sulle prestazioni della UI, ma quando ci arrivi, stai tranquillo che stai facendo *centinaia* di utenze contemporanee, non una decina.

Il buon software, sfrutta meno risorse e o fa in modo migliore.
Quando dico che spesso uso VM con 256 Mb di RAM, c'è gente che mi guarda come se raccontassi palle, ma la verità è che, un software ben scritto ed un server ottimizzato ad hoc può tranquillamente competere con macchine ben più performanti che poi devono subire schifezze come quella descritta dove 10/15 user incraccano in DB 5 connessioni... follia...

[guest]

Mica viene fuori l'errore se superi il numero d query, ti mette in coda.
Certo se il server è un nintendo e prima di servire le tue query ci mette mezz'ora magari va in timeout tutto lo script. Ma se anche uno per qualche strano motivo facesse 6 o 10 query nello stesso millisecondo non si blocca il sito su un server normale.
Se poi è un "tutto illimitato" allora il discorso potrebbe cambiare.

Come no. Ti scrive: "Warning: mysql_connect() [function.mysql-connect]: Too many connections in"

non ti mette in coda, ti si ammazza lo script.

[guest]

La verità è che quando parlo di 3 tier, non lo faccio per bullarmi o pisciare lungo, ma solo perchè un sano Business Object di mezzo, renderebbe un sito più manutentibile, più sicuro e, soprattutto non sfangherebbe i maroni al DB risparmiando un sacco di risorse.

Si, ok, ma non tutti possono sviluppare una applicazione a 3 tier o trovarne una di già fatta.
Considerato che chi fosse in grado di sviluppare una applicazione di tale livello sicuramente non sarebbe qui a chiedere info su come valutare uno shared hosting (lo saprebbe già fare per conto suo, visto il suo livello in ambito programmazione) devi considerare che in ambito web, le applicazioni consumer non sono mai a 3 tier, che ci piaccia oppure no.

Ed in tal caso, 5 connessioni, su un sito mediamente trafficato, su un database condiviso tra altri X*100 clienti (dove una query anzichè impiegare 1ms ne impiega magari 2) potrebbero essere poche.

Non dico di alzarlo di molto, noi ad esempio al momento abbiamo 15 come limite, ma 5 mi sembrano molto poche, se si vuol fornire un servizio 'per le masse' e non 'di nicchia' obbligando gli utenti a selezionare solo una determinata rosa di applicazioni.

[Valeriano Manassero]

Si, ok, ma non tutti possono sviluppare una applicazione a 3 tier o trovarne una di già fatta.

Vero.

Considerato che chi fosse in grado di sviluppare una applicazione di tale livello sicuramente non sarebbe qui a chiedere info su come valutare uno shared hosting (lo saprebbe già fare per conto suo, visto il suo livello in ambito programmazione) devi considerare che in ambito web, le applicazioni consumer non sono mai a 3 tier, che ci piaccia oppure no.

Perdonami, ma questo non è proprio vero. Chi fa hosting Rails lo sa bene visto che è lo stesso framework a fare pooling (tra l'altro configurabile ed overridabile).
Lo so che sono un rompipalle e che tiro fuori sempre Rails (parlo di ciò che conosco), ma vedi che alla fine della fiera le strutture esistono e sono fruibili anche da chi è meno informatizzato (un CMS Rails è tanto difficile da installare quanto un Joomla).
E torniamo al discorso dell'ecosistema che ti mette in posizione di lavorare bene e questo episodio è l'esatta dimostrazione di quando parlo dei forti limiti di PHP e soci che permettono le schifezze e poi tutti a fare le schifezze salvo lamentarsi con l'hoster che da *solo* 5 connessioni massime (o tu che ne dai quindici che sono un numero enorme).
E guarda che un codice strutturato bene, darebbe vantaggi proprio ai provider che potrebbero avere più applicativi sulla macchina.

Ed in tal caso, 5 connessioni, su un sito mediamente trafficato, su un database condiviso tra altri X*100 clienti (dove una query anzichè impiegare 1ms ne impiega magari 2) potrebbero essere poche.

Se la struttura è app -> db senza un minimo di gestione è vero.

Non dico di alzarlo di molto, noi ad esempio al momento abbiamo 15 come limite, ma 5 mi sembrano molto poche, se si vuol fornire un servizio 'per le masse' e non 'di nicchia' obbligando gli utenti a selezionare solo una determinata rosa di applicazioni.

Ma sì, per la carità, alla fine va bene tutto, però trovo ingiusto che gente poco informatizzata gioca al piccolo programmatore e poi vada in giro a piangere che gli hoster per 15 euri l'anno danno un servizio scadente (e capita spesso) quando scadente è l'applicativo.

[Uno]

Come no. Ti scrive: "Warning: mysql_connect() [function.mysql-connect]: Too many connections in"

non ti mette in coda, ti si ammazza lo script.

Si hai ragione, non mi sono mai posto il problema.
Beh non serve essere un genio della programmazione per trovare una soluzione sporca

 <?php

if (mysql_errno() == 1203) {
  // 1203 == ER_TOO_MANY_USER_CONNECTIONS (mysqld_error.h)
  header("Location: http://tuosito.com/pagina_coda.php");
  exit;
}
?>

Sulla pagina coda ci metto un'altra redirezione che mi riporta alla pagina gusta.

Lo inserirò nel software che sto facendo, hai visto mai che me lo compra uno che vuole installarlo su un hosting da 5 euro?

[guest]

(un CMS Rails è tanto difficile da installare quanto un Joomla).

Mandami in privato qualche nome di alcuni cms che reputi validi, cosi butto un occhio.

E torniamo al discorso dell'ecosistema che ti mette in posizione di lavorare bene e questo episodio è l'esatta dimostrazione di quando parlo dei forti limiti di PHP e soci che permettono le schifezze e poi tutti a fare le schifezze salvo lamentarsi con l'hoster che da *solo* 5 connessioni massime (o tu che ne dai quindici che sono un numero enorme).

Scrivere un codice fatto bene richiede lo stesso tempo di scriverne uno fatto male, indipendentemente dal linguaggio.
Prendi i linguaggi a tipizzazione forte. Alcuni dicono che sono migliori, altri no.
In un linguaggio a tipizzazione forte fai con 25 righe quello che con PHP magari ne fai in 5.
Questo non indica che PHP è fatto male, indica semplicemente che puoi usarlo *anche* per fare castronerie.
Però puoi benissimo implementare sistemi 3 tier, clusterizzati e quant'altro, esattamente come faresti con rails.

E' la voglia che manca alla gente, anche i nostri applicativi, bene o male che siano, girerebbero benissimo su VPS con 256M di ram, tant'è che le VPS molte delle nostre ad uso interno hanno proprio 256M di ram e 1 vCPU, e fan girare apache e MySQL.
Zero problemi. Wordpress li sopra non lo farai mai girare.

Questo non è un problema di PHP, è un problema di chi programma, se la gente non sa programmare non puoi incolpare il linguaggio.
Sarebbe come incolpare la Smart dicendo che è il suo cambio automatico a far guidare male la gente. Non è così.

E guarda che un codice strutturato bene, darebbe vantaggi proprio ai provider che potrebbero avere più applicativi sulla macchina.

Lo so bene, non sto mica dicendo che è sbagliato ottimizzare il codice.
sono però realista, come nel thread su MySQL. Se il codice in giro è questo, purtroppo, bisogna convivere con questo, altrimenti non mangi. Capisci che intendo?

E se devi convivere con questo, non puoi permetterti, se non in casi particolari come tophost, di tenere un numero così basso di query.

Se la struttura è app -> db senza un minimo di gestione è vero.

Questo è il 90% del software in giro per la rete.
Ed è con questo che noi provider dobbiamo convivere.
Te probabilmente sei un libero professionista, 'campi' per i fatti suoi, noi 'campiamo' con il software fatto da altri, e c'è una bella differenza. Tu puoi proporre un tuo software al cliente e farti pagare, noi dobbiamo fare in modo che il cliente possa usare il suo di software per farci pagare. Se non lo può usare, va da altri.

Ma sì, per la carità, alla fine va bene tutto, però trovo ingiusto che gente poco informatizzata gioca al piccolo programmatore e poi vadano in giro a piangere che gli hoster per 15 euri l'anno danno un servizio scadente (e capita spesso) quando scadente è l'applicativo.

Lo trovo ingiusto anche io...