Jump to content
Sign in to follow this  
mastro.c

Server dedicato per "enorme" sito Wordpress

Recommended Posts

Il fatto è che non puoi confondere due ambiti, perché se lo fai continuerai a fare traslochi ogni tot mesi.

Trasloco ne ho fatto solo due (di test), dagli USA all'Italia perchè ero convinto che mi potessero dare vantaggi.

Dopo un po' di mesi me ne sono ri-scappato subito negli USA e lì rimango.

Notare che non avevo fatto il trasferimento per risparmiare: semplicemente perchè alcuni siti che avevo su un unmanaged stavano crescendo ed erano diventati business e volevo maggiore affidabilità e controllo, e non avevo più tempo nè me la sentivo più di giocare a fare il sysadmin .

In particolare un problema che non avevo materialmente tempo di risolvere e che stava rallentando un sito mi aveva convinto a passare ad un managed.

Non sono proprio la persona che continua a fare traslochi. Ho alcuni server da anni presso gli stessi provider (USA).

E' ovvio poi che uno parla delle esperienze in cui si è trovato male, E' inutile che parli di come mi sono trovato bene con LiquidWeb, StormOnDemand, Linode, WiredTree, SingleHop, e anche Hostgator, tanto che non mi sognerei mai di spostare i dedicati o VPS che ho presso di loro.

Le uniche due esperienze italiane che ho fatto sono state PESSIME, quindi ne ho parlato e ne parlerò. Sono sicuro che esistono aziende buone anche qui in Italia, ma non rischio più, non sulla mia pelle o su quella dei clienti. Per lasciare soldi poi a gente che al primo problema che si presenta dopo 9 mesi di hosting managed ti risponde: "io da qui vedo tutto bene e il sistema è a posto quindi non c'è nessun problema".

 

Non puoi scrivere che un provider non è adatto ad ospitare wp ad alto traffico perché non ti da dritte su dove andare a modificare lo script.

No, mi basta vedere che non ha altri siti WP ad alto traffico: controllo che bisognerebbe sempre fare (andando poi a vedere che effettivamente i siti siano hostati là, perchè molti fregano anche su quello).

Se mi deve dire solo che il sito è giù, ci arrivo anche io. Se magari il problema capita una volta all'anno, ci si mette insieme a risolvere il problema. E non significa che il sysadmin deve dirti la riga di codice, ma delle due una:

- o mi dà l'accesso root e ci lavoro io per trovare il bug;

- o mi fa arrivare lui il più vicino possibile all'errore senza farmi perdere due giorni di ping pong a colpi di ticket

 

Certo in Italia molti hanno anche il ricatto del contratto annuale, per cui spesso il cliente, dati i costi e i tempi necessari al trasloco e alla rescissione del contratto, abbassa la testa e accetta tutto.

Per questo consiglio anche di non accettare mai e poi mai contratti annuali (almeno sui dedicati), perchè è un suicidio se si becca il provider sbagliato.

 

 

Quindi, se non cambiano redicalmente script e/o demoni (cosa improbabile se fai i soli agg. di sicurezza, come si fa in ambiente di produzione), la fase di tuning non si esegue ogni giorno o settimana; questo se si procede come ho descritto, è ovvio che se si mette mano alle configurazioni una impostazione per volta quando si verifica un problema stai sempre lì a modificare.

d'accordissimo: se però capita un problema dopo mesi, non si fa lo scaricabarile. Si risolve. E dato che solitamente il cliente ha meno possibilità di reperire personale skillato rispetto al provider, a mio modestissimo parere è il provider che in situazioni eccezionali può fare lo sforzo.

Con questo escludo ovviamente chi vuol far girare siti enormi a costi ridicoli, sto parlando di dedicati managed pagati il giusto.

Share this post


Link to post
Share on other sites
d'accordissimo: se però capita un problema dopo mesi, non si fa lo scaricabarile. Si risolve. E dato che solitamente il cliente ha meno possibilità di reperire personale skillato rispetto al provider, a mio modestissimo parere è il provider che in situazioni eccezionali può fare lo sforzo.

Con questo escludo ovviamente chi vuol far girare siti enormi a costi ridicoli, sto parlando di dedicati managed pagati il giusto.

 

Ma scusa, se hai avuto problemi, il provider non ti ha fornito i log?

 

Parlo di access/error log del webserver + log di mysql (slow query & Co) + eventuali grafici relativi ad I/O, CPU, RAM così da capire se per caso i problemi sono lì.

 

Nel 90% dei casi il problema è relativo a query fatte male, il restante 10% a problemi di script (ma questo 10% lo escludi se non hai apportato modifiche allo script); quindi bene o male si capisce dove sta il problema.

Share this post


Link to post
Share on other sites
Ma scusa, se hai avuto problemi, il provider non ti ha fornito i log?

 

Il punto non è questo: soprattutto in riferimento alla richiesta originale del thread, se l'atteggiamento del provider è "cambia CMS" la soluzione del problema è molto più dura.

 

In ogni caso per un debug serio di problemi complessi non bastano i log. Serve anche fare dei test, poter stare alla console e fare un ps aux o un tail -f su qualche log quando ti serve, poter cercare stringhe nel codice, poter avere tutte le informazioni possibili in tempo reale.

Farlo solo con control panel (spesso settato male) e ftp è ridicolo.

 

Inutile offrire managed se questo si limita a far stare su il sistema e non ti fornisce tutti gli strumenti per poter affrontare problemi quando si presentano.

 

Nè io nè nessuna altra persona sana di mente accetta come consiglio "cambia CMS" a business già avviato.

Share this post


Link to post
Share on other sites

Scusate.... i post corono, corrono... corrono, ma se torno indietro leggo che stiamo parlando di un server unmanaged gestito da un bravissimo sysadmin.

Non voglio fare sempre il solito sospettoso e pensare che il sysadmin non sia tale e/o non sia bravissimo, ma non vedo perchè mettere in croce e puntare tanto sul fatto che qualcuno (provider o meno) abbia tra la varie cose consigliato di cambiare cms.

Giustamente qualcuno ha detto: con quello che spendi in più di server (e magari da upgradare ancora) fai ora a pagarti un programmatore che te lo fa su misura il cms.

Questo è il punto principale del thread che poi ha preso direzioni incredibili.

Chi lo ha proposto non si sta facendo più vivo (spero sia per le feste), forse perchè nessuno è in grado di dare dei magici consigli su una situazione che fino ad oggi è andata avanti a upgrade quando non si sapeva dove mettere le mani?

Share this post


Link to post
Share on other sites
Il punto non è questo: soprattutto in riferimento alla richiesta originale del thread, se l'atteggiamento del provider è "cambia CMS" la soluzione del problema è molto più dura.

 

In ogni caso per un debug serio di problemi complessi non bastano i log. Serve anche fare dei test, poter stare alla console e fare un ps aux o un tail -f su qualche log quando ti serve, poter cercare stringhe nel codice, poter avere tutte le informazioni possibili in tempo reale.

Farlo solo con control panel (spesso settato male) e ftp è ridicolo.

 

A dire il vero è ridicolo che il debug tu lo faccia il produzione eh, perché se hai gli access log puoi ricostruirti la dinamica che ha portato al problema sul tuo ambiente di test in locale (al limite ti fai passare php.ini, my.cnf e conf di apache per avere pressoché la stessa conf).

 

Nè io nè nessuna altra persona sana di mente accetta come consiglio "cambia CMS" a business già avviato.

 

Consigli forse no, analisi fatte per bene, con proiezioni dei costi di manutenzione/mantenimento/aggiornamento dell'infrastruttura si ;)

 

Comunque fai come vuoi, buona giornata.

Share this post


Link to post
Share on other sites
ndr. un provider che ti da accesso root a un server managed fa il più grave errore di sempre ... se a te scappa per sbaglio un rm -rf / poi la colpa di chi è?

ovviamente e' colpa del provider.

provider che - sbagliando - ti ha gia' dato l'accesso root, che ti deve seguire in tempo reale e che ti ha detto a che riga del TUO script correggere il problema, che vede il suo lavoro sminuito perche' "tanto apt-get dist-upgrade lo so fare pure io" mentre c'e' tutto un mondo dietro.

ah, dimenticavo, magari lo fa pure per quattro spiccioli al mese.

Share this post


Link to post
Share on other sites
ovviamente e' colpa del provider.

provider che - sbagliando - ti ha gia' dato l'accesso root, che ti deve seguire in tempo reale e che ti ha detto a che riga del TUO script correggere il problema, che vede il suo lavoro sminuito perche' "tanto apt-get dist-upgrade lo so fare pure io" mentre c'e' tutto un mondo dietro.

ah, dimenticavo, magari lo fa pure per quattro spiccioli al mese.

è proprio il motivo per il quale ho smesso di argomentare in questo thread ... sembra che un sysadmin si limiti a dare 2 righe al giorno di comandi e basta ... è come se io mi permettessi di dire a un webmaster che lui si limita a dare 3 click su un installer di un cms ... sminuire il lavoro di altri non è un buon punto di partenza :)

Share this post


Link to post
Share on other sites

Prima avete detto che WordPress non va bene per siti grandi.

E vi ho dato i link di siti grandi in WP.

 

Poi avete detto che non sono veri WordPress perchè usano cluster / load balancing / Varnish / CDN.

E vi ho detto e dimostrato che non è vero.

 

Poi mi avete messo in bocca cose che non ho detto.

E vi ho fatto notare che non era vero e neanche corretto.

 

Ora estraete delle mie frasi da un contesto (apt-get update lo so fare anche io etc) che erano in risposta ad una serie di argomenti, e nel contesto aveva senso.

 

Ora sostenete che ai managed non si dà accesso di root arrampicandovi sugli specchi, quando tutti i managed USA danno accesso root e non è che tutti i giorni i clienti si piallano le macchine.

 

Non vuoi darmi l'accesso di root? allora mi rispondi entro 10 minuti alle 3 di notte, come fanno TUTTI gli americani (che tra l'altro danno anche l'accesso di root). E se non mi dai modo di controllare che cosa sta succedendo sul mio server, la colpa è tua di default.

 

Se sai lavorare bene fai contratti mensili e dai l'accesso di root. Se non sai lavorare fai contratti blindati di un anno o più e non dai l'accesso di root, così puoi dire qualunque fregnaccia al cliente perchè tanto non è verificabile, e fai perdere 3 giorni per un debug che richiederebbe 4 ore.

 

Che dire? è proprio questa la mentalità di molti provider italiani da cui io e molti altri fuggiamo: diffidenza, contratti capestro, burocrazia e raccomandate di disdetta, incompetenza, arroganza, mancanza di capacità imprenditoriale, aggressività verso i clienti.

 

Che altro posso aggiungere, vi sta già punendo il mercato.. :-)

Share this post


Link to post
Share on other sites

Poi avete detto che non sono veri WordPress perchè usano cluster / load balancing / Varnish / CDN.

E vi ho detto e dimostrato che non è vero.

questo me lo sono perso

 

oltre un certo limite non si può scalare verticalmente, su questo concorderai spero

 

Ora sostenete che ai managed non si dà accesso di root arrampicandovi sugli specchi, quando tutti i managed USA danno accesso root e non è che tutti i giorni i clienti si piallano le macchine.

tutti?

Managed Hosting | Fully Managed High Performance Dedicated Servers

Note: Administrative "root" access is unavailable with Managed Hosting.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×