GPG-BODY

Sempre per chi deve usare un cloud: si, ho capito il punto. Di fatto, gpg sta usando male la compressione. Il valore di default e' 6, che fa in modo che gpg tenti di comprimere, abbia senso o meno, ogni messaggio in entrata. Questo fa spendere CPU per nulla su email contenenti jpg,mpg,zip &co. Anche se le email non contengono mai binario in se', usando base64 , dando cosi' un falso senso di comprimibilita', un settaggio fisso produce una fatturazione ingiustificabile sui cloud.

Del resto, pero', non comprimere il comprimibile sarebbe un peccato, perche' sui cloud si paga lo storage. Cosi', la soluzione e' di comprimere quando il costo di CPU vale lo spazio su disco. Ho implementato un controllo basato sull'entropia dell'informazione contenuta nel body.

Se abilitate zlib sul file di configurazione, gpg_body andra' a calcolare l'entropia dei file, e sulla base di questa scegliera' il livello di compressione. Ho creato un file di tutti zeri da due MB e me lo sono spedito, e il risultato e' stato questo: (ecco il file di dump di cui parlero' dopo)


Microsec: 1: From status entering to 0 : Starting State Machine ( done: ) Initializing program

La compressione in questo caso, e' stata circa di 1:1000.

Usando un file gis' zippato con livello 9  come allegato dentro la email, gpg_lib  ha scelto il livello di compressione 1, e la dimensione dell'email e' scesa solo del 10% circa, per via della codifica base64 che produce overhead.

In pratica, se abilitate le librerie, userete la CPU per comprimere solo quando salvate MOLTO spazio sullo storage del cloud. A voi calcolare i prezzi a seconda del vostro provider.

Ma ancora: che diavolo e' quel dump sopra?

Chi mi ha chiesto come ottimizzare il programma mi ha fatto una bella domanda. Ha senso mettere il file temporaneo su un file in un disco SSD? Ha senso usare un ramdisk? Bella domanda, perche' senza usare un profiler non e' facile fare questo tipo di conti.

Cosi' nel file di configurazione potete settare un file di dump, il quale di scrivera' ogni passaggio di stato della SM, con il tempo in microsecondi. Se vedete che la fase "leggere dal file temporaneo" vi prende molto tempo, allora probabilmente vi conviene spostare (usando il file di configurazione) la directory su un SSD. Se invece vedete che e' la lettura della email da stdin a prendervi tempo, probabilmente il problema sta negli IPC della vostra macchina. Se vi prende molto eseguire la crittazione, provate a disabilitare la compressione, oppure andate a verificare la latenza verso il keyserver, oppure provate ad aggiungere (usando il file di configurazione) parametri che permettano di salvare la chiave nel local keyring quando la si legge dal keyserver.

Il dump puo' essere abilitato sia quando il programma fallisce che quando il programma riesce, in modalita' debug, se volete osservarne le performance: dategli in pasto una email (in formato testo, tipo .eml) sullo standard input  e vedete che succede nel vostro sistema.

Il file di configurazione vi offre la possibilita' di passare altri comandi che saranno aggiunti alla command line di gpg, ma ci sono alcune limitazioni. Non sono permesse redirezioni dell'output e le opzioni di cui si occupa gia' il programma non sono consentite, quindi anche -z non passa piu'. In generale adesso il programma accetta solo UNA opzione in input, che e' -r  KEY_ID o -r user@mail.add , ovvero qualsiasi cosa si possa usare per una query al keyserver o al keyring onde avere la chiave pubblica.

Stasera aggiungero' il file tar.gz , chi scarica usando il PPA e' avvisato.

PEr chi non sa dove e come:

https://launchpad.net/gpg-body/

Uriel