Massimizzare le performance e ridurre i costi

Questa sezione e' utile ai clienti Unbit che vogliono migliorare le performance dei loro progetti o per i nuovi clienti che sono indecisi sul tipo di offerta da acquistare.

Non spaventarti se troverai parole come "lento","inaffidabile" o "brutto" applicato a un nostro servizio, non e' colpa nostra (quasi) ma delle attuali tecnologie (hardware e software). Che i nostri colleghi/concorrenti non ne facciano parola a noi riguarda poco. (e voi continuerete a comprare costoso,rumoroso e inquinante hardware dedicato per un blog che fa 4 visitatori al mese...)

Hardware

prima le brutte notizie: storage I/O

I dischi sono lentissimi, sempre e comunque, e sara' cosi' per ancora molto tempo, chiunque giuri che il suo sistema di dischi non e' un collo di bottiglia si sta prenotando un biglietto per un posto molto caldo che ha reso famoso un certo Dante...

La prima regola e' quindi: RIDUCETE AL MINIMO GLI ACCESSI DISCO.

L'infrastruttura Unbit si basa su una divisione equa (ma non certo perfetta) delle risorse hardware tra i clienti, privilegiando (ovviamente) quelli che spendono di piu'. Nella peggiore delle ipotesi (che e' quella su cui dovete sempre basarvi) l' I/O su cui potete fare conto per l'accesso al disco e' di circa 4 Megabytes al secondo. Il calcolo e' basato sulla divisione esatta tra la banda totale disponibile (i sistemi sono tutti raid 1 con 3 dischi) e il massimo numero di processi (raggruppati per ambiente) che possono essere eseguiti su un server.

E' un valore molto basso (anzi bassissimo) ma in un ambiente condiviso e' difficile (noi scommettiamo che e' impossibile) che riusciate a ottenere performance migliori. Inoltre avete un vantaggio: non scenderete mai sotto quel valore. I server di hosting classici, o i VPS che potete comprare dal fruttivendolo non possono darvi questa garanzia (a meno che non vi fate amministrare il VPS da noi).

Quindi, l'I/O dei dischi e' il principale collo di bottiglia, tenetelo sempre a mente, e se non potete fare a meno di scrivere i dati su disco (attenzione per disco intendiamo il vostro spazio, non i database) scrivete una mail allo staff. E' molto difficile che non vi siano alternative.

Per aiutarvi a tenere sotto controllo gli accessi disco, potete andare nella gestione processi e cliccare sul PID di interesse, vi fornira' il numero di read (bio_read), write (bio_write) e stat. Le stat possono essere ancora piu' pericolose delle read/write perche' implicano quasi sempre lo spostamento delle testine.

CPU come se piovesse

Ebbene si', di risorse di calcolo ne abbiamo a iosa. Una (paradossale) applicazione che gira su un server Unbit senza fare I/O andrebbe molto probabilmente piu' veloce di qualsiasi server abbiate mai istallato. Questo perche' il nostro scheduler privilegia (e sempre privilegera') chi fa poco I/O (su disco ovviamente).

Inoltre, se la vostra applicazione ha bisogno di ancora piu' risorse di calcolo, potete acquistare uno dei servizi di clustering disponibili da giugno 2010 fino a un massimo di 10 nodi.

una Memoria da Elefante

(L'animale scelto e' un messaggio subliminale che vi indirizzera' verso un certo database engine N.D.R.)

Vi basta fare la somma dell'address space fornito da un piano base per rendervi conto di quanta memoria avete a disposizione su un singolo server Unbit. Ogni processo ha il suo quantitativo di address space dedicato (e cosi' si riduce anche il problema dello swapping) ma il vero fattore chiave e' che piu' memoria e' disponibile piu' page cache si potra' usare. La page cache e' l'area della memoria dedicata al "caching" (ma guarda un po') dei dati presenti su disco. Piu' la page cache e' grande piu' l'impatto dei birboni che fanno tanto I/O sara' mitigato.

L'address space e' una risorsa preziosa (e' probabilmente il limite piu' incisivo) ma lasciarlo inutilizzato e' un vero peccato. Quindi se avete address space libero per un processo trovategli un utilizzo o magari chiedete un downgrade (fino a un minimo di 8 mega).

Un esempio e' utilizzare la shared area di uWSGI, o il modulo APC di php per fare caching. Magari, se siete bravi, potete ridurre l'I/O usando mmap() su qualche file.

Networking

Di solito (diciamo sempre) e' un dato poco rilevante, a meno che non abbiate lavorato su sistemi con schede di rete del decennio scorso non dovreste mai aver avuto problemi di networking I/O.

In ogni caso (per tranquillizzarvi e tirarcela) potete contare su 2 reti (di cui una dedicata esclusivamente al traffico tra i server Unbit che torna molto utile per il clustering) giga ethernet.

Software

Attenzione a MySQL

Ebbene si', tutti i fornitori da cui vi siete serviti si sono dimenticati di avvertirvi di un paio di problemini di questo famoso e usatissimo database engine.

Il principale (gli altri li lasciamo al lettore) e' che il suo sistema di caching e' condiviso tra tutti gli utenti. E' molto probabile quindi che le vostre query non finiranno mai nella preziosa cache (che e' impostata a valori giganteschi ma insufficienti a contenere tutti i database di un server) con il risultato che i tempi di risposta dei siti aumenteranno (ovviamente parliamo di siti con un carico sostanzioso)

Come ovviare al problema (a parte cambiando engine) ?

Per prima cosa riducete gli accessi al db. Iniziate col disabilitare il caching delle pagine web su db. Non serve a nulla, stressate il database inutilmente e probabilmente le vostre pagine si genereranno ancora piu' lentamente. Se volete un buon sistema di caching chiedete allo staff quale e' la migliore soluzione del momento (eh si ancora non abbiamo trovato quella perfetta per tutti).

Riducete al minimo l'uso di BLOB e campi TEXT, se gia' era difficile che le proprie query finissero in cache, utilizzando questi due tipi di dati diventa impossibile. (E' una scelta architetturale di MySQL, noi non c'entriamo nulla)

Ove possibile utilizzate connessioni persistenti, almeno vi evitate i tempi di handshake iniziali e in caso di sovraccarico del server mysql avete comunque uno slot prenotato (eh si, chi tardi arriva male alloggia).

La maggior parte dei framework supportati operano con connessioni persistenti, quindi il problema non dovrebbe porsi.

Se proprio non potete fare a meno di mysql, ma vi serve che sia "veloce", l'unica soluzione e' acquistare un servizio mio-mysql. Avrete il vostro database server che gira nel vostro account configurato come vorrete. Se lo configurerete tenendo a mente la prima sezione di questo articolo (quindi no accessi disco) avrete un server mysql piu' potente e veloce di quello fornito da noi.

Vi starete chiedendo (visto che personalizziamo tutto) come mai non modifichiamo mysql per fargli gestire le cache in maniera piu' utile ai nostri scopi. Beh, non ci va. Facciamo piu' soldi vendendo i mio-mysql che tra l'altro instillano senso di onnipotenza al cliente (anche se il nome ricorda un formaggino)

Se possibile affidatevi a Postgresql

Sebbene le interfacce di amministrazione che forniamo per postgresql siano ridicole rispetto al supporto che diamo su mysql, non fatevi trarre in inganno. Siamo semplicemente consapevoli che gli utenti Postgresql sono mediamente piu' belli e alti (ah no, volevamo dire "preparati").

Il funzionamento di PostgreSQL, basato su processo e non su thread, si sposa perfettamente con la nostra piattaforma (in particolare grazie ad alcune scelte fatte per lo scheduler), e inoltre potrete contare su una cache dedicata per ogni connessione (ovviamente deve essere persistente).

A questo aggiungete il supporto per i linguaggi esterni, una piattaforma fantastica per il GIS e tanta altra roba appetitosa. Siamo ben consci che molti postgresql-maniaci vogliano configurare il loro server ad-hoc, per questo e' disponibile (come per mysql) il servizio mio-postgresql.

Ricordatevi che la versione 9 (che uscira' nel corso del 2010) includera' una piattaforma di replica integrata che potrete utilizzare sulla piattaforma di clustering Unbit (e' ovviamente necessario un servizio mio-postgresql)

NoSQL, hash server e altri gingilli

Se potete servitevi di strumenti come memcached, redis, couchdb e tutti gli altri applicativi che vanno tanto di moda ultimamente. Lavorano in ram e quindi sono velocissimi su qualsiasi server Unbit.

Attenzione a MongoDB, sebbene sia (forse) il piu' avanzato tra quelli disponibili, il suo uso estremo di mmap() lo rende poco idoneo ad ambienti con address space limitati come Unbit. Se contate quindi di salvare grandi moli di dati su MongoDB quasi certamente avrete dei problemi (ma stanno comunque lavorando a dei nuovi sistemi di storage).

i famigerati 64 bit

I sistemi Unbit sono ibridi: kernel a 64 bit e userspace a 32. Per il kernel la motivazione e' semplice, dobbiamo gestire quantitativi abnormi di ram e HIGHMEM e' una pessima scelta.

I 32 bit per lo userspace sono invece una scelta obbligata, poiche' le applicazioni a 32 bit in media occupano molto meno address space di quelle a 64.

Se volete, potete ricompilare i vostri applicativi a 64bit ma onestamente non ne vediamo un gran vantaggio.

Personalizzate,compilate e configurate

Se possibile non affidatevi esclusivamente al nostro parco software. Nel corso degli anni abbiamo imparato che non c'e' una configurazione che vada bene per tutti (ecco perche' quella mole inaudita di parametri che forniamo) quindi cercate di istallare le versioni dei vostri software preferiti in home. Questo, oltre a tutti i benefici che si possono trarre delle versioni piu' recenti, vi permettera' anche di dormire tranquilli quando facciamo gli aggiornamenti di sistema

E infine ...

SIATE PUNTUALI CON I PAGAMENTI attualmente non esiste nessuna tecnologia che vi tuteli dal reparto amministrativo