Linux, PHP, MySQL, Windows, C#

Nella configurazione di mysql (mi pare anche nella standard da RPM delle redhat based) non viene configurato il parametro il parametro: tmpdir che normalmente assume il valore di default del sistema. Su Linux naturalmente /tmp.

Qualora per motivi di spazio o banalmente convinti che la /tmp non sia necessario renderla di ampie dimensioni, potrebbe accadere che durante certe operazioni molto pesanti su tabelle con quantitativi di record notevoli, il sistema esaurisca lo spazio nella partizione temporanea durante la fase di elaborazione dati e scrittura di una tmp table, proprio su questa partizione.

La query abortira’ con un messaggio del tipo no space left on device o qualcosa del genere.

In tal caso andra’ allargata la partizione tmp di sistema (o dove si appoggia mysql) o in alternativa cambiato il path (che deve essere scrivibile dallo user “mysql“), fermato il servizio mysql e riavviato.

Vedremo in questo articolo come poter lavorare con il server web apache per migliorare le prestazioni del proprio server web e risparmiare al contempo anche banda internet (preziosa e costosa).

Per fare questo si può utilizzare un fantastico modulo di apache, mod_deflate.

FUNZIONAMENTO

Prima di tutto comprendiamo il funzionamento di mod_deflate e cosa fa. Questo modulo si occupa di comprimere html, documenti, immagini e quantaltro prima di servirle al client.
In tal modo otterremo una diminuzione nell’utilizzo della banda e il sito sarà in parte più rapido anche per quei navigatori che dispongono di connettività non a banda larga o comunque non eccelsa.

QUANDO UTILIZZARLO E COME

E’ importante però comprendere quando possiamo utilizzarlo e soprattutto se non sarà un boomerang che ci torna sulla faccia. Per farlo bisogna quindi analizzare il problema.

A) Contenuto del sito web

Nel caso in cui il nostro sito web sia composto prevalentemente da elementi testuali (CSS, HTML, XML etc…) otterremo un’effetto eccezionale comprimendo tali contenuti. Nel caso invece il sito sia composto da Flash, immagini pesanti etc… l’effetto sarà praticamente nullo.

B) Il nostro server ha abbastanza processore?

Un altro aspetto è legato alla potenza del server, infatti se da un lato si ottiene un miglioramento sull’aspetto della banda, avremo come controindicazione un impatto sul carico della CPU che per ogni richiesta deve comprimere il file prima di inviarlo al client. Se ne evince quindi che in caso di poca potenza rischiamo di risolvere i problemi di banda e causarne sull’HW del server web.

ATTIVAZIONE DEL MODULO

Se apache come di default su CentOS 5.1 (presa in esame per l’articolo) ha già incluso il modulo, bisogna solo scommentare la riga relativa:

LoadModule deflate_module modules/mod_deflate.so

CAMBIO CONFIGURAZIONE SERVER WEB

A questo punto dobbiamo definire in apache come e dove utilizzare il modulo.
Per fare questo è davvero inutile andare a sprecare bit su questo articolo , per cui vi rimando direttamente alla parte di configurazione sul sito di apache stessa:

MOD_DEFLATE CONF

Una nota importante da fare, prima di chiudere l’articolo, è relativa alla possibilità di escludere alcuni browser che non supportano pagine zippate e di poter escludere file come ZIP, Immagini, flash etc… (visibile da docs su apache)

A partire dalla versione 5.1 mysql supportera’ praticamente per tutti i tipi di storage engine il partizionamento.

La versione 5.1 di mysql e’ al momento in release candidate.

Spero che nell’arco di 3/4 mesi possa uscire la prima release stabile.

Il partizionamento rappresenta una novita’ per il design di database in mysql molto forte e utile, soprattutto quando i record sono tanti.

Vi rimando ad un articolo stupendo che spiega benissimo (in inglese, ma e’ facile… ) i vantaggi che si possono ottenere lavorando con i partizionamenti.

My-SQL-Partitions

Ciao. Maxgrante
info[AT]massimo-caselli[DOT]com

Recentemente stanco di utilizzare il solito phpmyadmin (sempre valido ed eccezionale) ho deciso di provare qualche programma per la gestione di mysql alternativo.

Ho scoperto un ottimo tool in versione opensource che si chiama SQL Yog.

Lo potete trovare e scaricare dal sito ufficiale: http://www.webyog.com

La versione community è davvero molto valida ed affidabile. Di fatto presenta tutte le caratteristiche tipiche di questi programmi, ma rispetto a molti altri che ho provato in passato garantisce davvero un’ottima affidabilità.

Di seguito alcune tra le caratteristiche più interessanti:

• Possibilità di creare viste, stored procedure
• Ottima funzionalità di import/export dal classico dump
• Tool per table diagnostics
• Valida gestione dei permessi
• Editing il linea dei dati presenti nelle tabelle

Segnalo inoltre per chi fa un uso professionale di questi strumenti che esiste una versione Enterprise del costo di 70 euro + IVA circa per una licenza che permette alcune cosette davvero carine:

• Tunnelling SSH
• Tunnelling SSL
• Synchronization e Migration Toolkit da diversi database quali Oracle, SQL Server, Access etc…
• Query autocompletion
• Query builder
• Schema designer

Ciao. Maxgrante
info[AT]massimo-caselli[DOT]com

Di seguito propongo un rapidissimo How To per permettere il rate control del server di posta Postfix.

Nello specifico l’how to tratta un tuning orientato a limitare il rate control. Naturalmente facendo scelte diverse dalle mie è possibile aumentare le prestazioni del server di posta.

PROCESS LIMITS

default_process_limit = 10 (Valore di default, 100)

Impostando a 10 processi si limita moltissimo il numero di processi simultanei gestiti dal server di posta, in tal modo il flusso mail sarà rallentato e non banda a picco server e/o banda internet

CONNESSIONI CONCORRENTI

local_destination_concurrency_limit = 2 (Valore di default, 2)
default_destination_concurrency_limit = 2 (Valore di default, 20)

La prima impostazione definisce dopo quante email iniziare a regolare l’invio simultaneo di mail.
La seconda voce invece gestisce e indica a Postfix quante connessioni simultanee fare allo stesso server.

LIMITE SUI RECIPIENTS

smtpd_recipient_limit = 20 (Valore di default, 100)

Indica quanti destinatari Postfix accetta in una singola email spedita.

GESTIONE E TUNING DELLA CODA

smtpd_recipient_limit = 20 (Valore di default, 100)

Indica quanti destinatari Postfix accetta in una singola email spedita.

queue_run_delay = 100000 (Valore di default, 1000 seconds)

Identifica ogni quanto Postfix rilegge la coda per rispedire i messaggi deferred perché un host non era precedentemente raggiungibile.

maximal_queue_lifetime = 1d (Valore di default, 5 days)

Indica quanto tempo un messaggio che Postfix non riesce a spedire deve tenere in coda.

maximal_backoff_time = 100000 (Valore di default, 4000 seconds)

Identifica dopo quanto tempo almeno Postfix deve guardare dopo un delivery failure.

Ciao. Maxgrante
info[AT]massimo-caselli[DOT]com