Archives For SQLite

Per chi non lo dovesse ancora conoscere, il database places.sqlite è ben descritto (nonostante venga specificato che si tratta di linea introduttiva di massima) in un documento ospitato da MDN, il sito web dedicato agli sviluppatori interessati a capire (e magari mettere mano) al mondo dei programmi Mozilla. Ciò che tu probabilmente ignori (e non c’è niente di male, aggiungerei), è che quel database contiene pezzi fondamentali della tua navigazione quotidiana: dai Segnalibri alla Cronologia, passando per le favicon e gli accessi a ogni sito web (utile per realizzare poi le liste automatiche di siti web più visitati, per fare un esempio). Puoi quindi capire la sua importanza e il fatto che debba essere tutelato e curato.

Firefox: snellire la cronologia pulendola automaticamente

Un database tenuto pulito è più veloce, più reattivo in fase di apertura e consultazione della cronologia, più facile da gestire per Firefox. In alcuni casi (il mio ne è un esempio) si può decidere di non cancellare la cronologia e mantenerla così viva per consultazione futura, ma quando quella consultazione supera un certo numero di giorni di profondità, è possibile che questa non abbia più senso, occupando solo dello spazio su disco fisso e rallentando le prestazioni del browser:

È per questo motivo che ci si può appoggiare a un componente aggiuntivo in grado di svolgere un lavoro di pulizia in maniera automatica, così da andare a snellire sì la Cronologia, ma null’altro in base a quanto specificato dalla nostra configurazione del browser. Io utilizzo da anni un componente aggiuntivo realizzato dal collega di forum Marco “MaK” Bonardo, Expire History By Days, disponibile gratuitamente passando dal sempreverde AMO, aggiornato e perfettamente compatibile con l’era Quantum di Firefox:

Expire history by days
Expire history by days
Developer: Mak
Price: Free

Puoi impostare il numero di giorni di Cronologia da mantenere direttamente nelle opzioni del componente aggiuntivo (io ho scelto 150 giorni di profondità massima, oltre la quale l’addon può cancellare ogni traccia dal database), al resto ci penserà lui.

In alternativa, nel caso in cui tu volessi passare da un diverso componente aggiuntivo, potrei proporti History AutoDelete, altro componente aggiuntivo gratuito che trovi su AMO:

History AutoDelete
History AutoDelete
Developer: Kenny Do
Price: Free

Compatibile anch’esso con Firefox di nuova generazione, utilizza lo stesso principio del componente aggiuntivo di MaK, ma propone qualcosa in più rispetto al primo citato, permettendo di cancellare su richiesta la Cronologia del singolo dominio (un po’ come andare a richiamare il “Dimentica sito web” già integrato in Firefox e nella sua finestra di Cronologia), oltre che impostare un certo numero di giorni da mantenere (oltre i quali fare piazza pulita), tenere traccia delle cancellazioni operate e permettere comportamenti precisi per domini che è possibile specificare manualmente o tramite importazione di liste.

Tu sei solito fare pulizia della tua Cronologia? Fai parte magari del club che tutto pulisce in fase di chiusura browser o preferisci operare per singolo dominio? Parliamone nell’area commenti! Magari salta fuori qualche altro buon suggerimento :-)

Condividi l'articolo con i tuoi contatti:

La primavera è già passata da qualche tempo, ma il mio evidente ritardo nel percepirla ha fatto slittare in avanti dei lavori di pulizia che rimandavo da troppo tempo. Il mio profilo principale di Firefox (costantemente replicato e sotto backup) conteneva dati davvero troppo vecchi, facendo arrivare alcuni dei database SQLite dell’applicativo a occupazioni disco fuori (e di molto) dallo standard al quale si è abituati nelle nuove installazioni (o nei profili più puliti). Per questo motivo ho scelto di prendere scopa, paletta e smacchiatore per dare un po’ più di piglio energico al browser di casa Mozilla, il predefinito sulle mie macchine.

Firefox: ottimizzazione dei DB SQLite 6

Ti spiego in poche parole (e diversi dati) ciò che ho fatto. Ti mando subito a leggere qualche riga riguardo SQLite nel caso in cui non sapessi di cosa si sta parlando, male non può certamente fare. I file incriminati e importanti sono sostanzialmente due: places.sqlite e webappsstore.sqlite. Prima di partire, una giusta cultura di base: il primo file (database, in realtà) contiene tutta la cronologia di navigazione in base ai criteri da te impostati all’interno delle opzioni di Firefox, non contiene i Segnalibri contiene i Segnalibri nella tabella moz_bookmarks, che viene toccata durante la pulizia solo per rimuovere spazi lasciati vuoti dall’utilizzatore (qui la pagina di KB su mozillaZine). Il secondo file invece conserva i dati che generalmente si vanno a compilare nelle form dei siti web che visitiamo, si tratta di un database molto delicato che non andrebbe mai modificato manualmente e che puoi permetterti di perdere solo se non ti secca ricominciare a creare una cronistoria dei dati che dovrai inserire a mano (per esempio) durante la registrazione di un modulo, una nuova iscrizione a chissà quale forum o così via (qui la pagina KB su mozillaZine).

Sia chiaro: Firefox continuerà a funzionare sulla tua postazione anche se cancelli completamente i due file, poi però non lamentarti se vai a perdere la cronologia di navigazione o i dati precedentemente immessi nei moduli (e non solo), di sicuro ci guadagni in velocità :-)

Io ho voluto clonare il profilo e mettere alla prova un’estensione che promette di andare ad alleggerire questi due file a patto di trovare delle voci orfane, quindi eliminabili in via definitiva, ricostruendo il database e popolandolo solo con le voci effettivamente vive e vegete (vedi: vacuum SQLite). L’estensione è Places Maintenance e la puoi trovare ovviamente su AMO:

Places Maintenance
Places Maintenance
Developer: Mak
Price: Free

Perché proprio lei in un mare di altre estensioni dedicate alla manutenzione dei database SQLite di Firefox? Perché è sviluppata da un amico connazionale e profondo conoscitore di Firefox, Mak, Firefox Team Engineering Consultant.

A installazione terminata (non richiede riavvio, nda) ho lanciato immediatamente una scansione della situazione sul profilo clonato, questo il risultato:

Statistics
 Database size is 81920 KiB
 user_version is 32
 page_size is 32768
 cache_size is -2048
 journal_mode is wal
 synchronous is 1
 History can store a maximum of 104858 unique pages
 Table moz_places has 104024 records
 Table moz_historyvisits has 281408 records
 Table moz_inputhistory has 469 records
 Table moz_bookmarks has 641 records
 Table moz_keywords has 0 records
 Table sqlite_sequence has 1 records
 Table moz_favicons has 4080 records
 Table moz_annos has 2192 records
 Table moz_anno_attributes has 13 records
 Table moz_items_annos has 172 records
 Table sqlite_stat1 has 15 records
 Table moz_hosts has 6291 records
 Index sqlite_autoindex_moz_inputhistory_1
 Index sqlite_autoindex_moz_keywords_1
 Index sqlite_autoindex_moz_favicons_1
 Index sqlite_autoindex_moz_anno_attributes_1
 Index sqlite_autoindex_moz_hosts_1
 Index moz_places_faviconindex
 Index moz_places_hostindex
 Index moz_places_visitcount
 Index moz_places_frecencyindex
 Index moz_places_lastvisitdateindex
 Index moz_historyvisits_placedateindex
 Index moz_historyvisits_fromindex
 Index moz_historyvisits_dateindex
 Index moz_bookmarks_itemindex
 Index moz_bookmarks_parentindex
 Index moz_bookmarks_itemlastmodifiedindex
 Index moz_places_url_uniqueindex
 Index moz_places_guid_uniqueindex
 Index moz_bookmarks_guid_uniqueindex
 Index moz_annos_placeattributeindex
 Index moz_items_annos_itemattributeindex
 Index moz_keywords_placepostdata_uniqueindex

Occhio a:

  • Database size is 81920 KiB
  • History can store a maximum of 104858 unique pages
  • Table moz_places has 104024 records
  • Table moz_historyvisits has 281408 records

Ho volutamente evidenziato i valori più importanti a livello di onerosità su database, ciò che più occupava il file SQLite era chiaramente il contenuto della mia cronologia, praticamente quasi mai resettata. Il valore massimo delle pagine uniche memorizzate nella cronolgia è fisso a 104858 poiché dettato da una configurazione di about:config, per l’esattezza si tratta di places.history.expiration.transient_current_max_pages.

Firefox: ottimizzazione dei DB SQLite 2

Ho lanciato un’ottimizzazione senza toccare alcunché, provando a lasciare invariato il contenuto della navigazione passata e ho dato un’occhiata ai risultati:

Statistics
 Database size is 71680 KiB
 user_version is 32
 page_size is 32768
 cache_size is -2048
 journal_mode is wal
 synchronous is 1
 History can store a maximum of 104858 unique pages
 Table moz_places has 104026 records
 Table moz_historyvisits has 281412 records
 Table moz_inputhistory has 469 records
 Table moz_bookmarks has 641 records
 Table moz_keywords has 0 records
 Table sqlite_sequence has 1 records
 Table moz_favicons has 4080 records
 Table moz_annos has 2192 records
 Table moz_anno_attributes has 13 records
 Table moz_items_annos has 172 records
 Table sqlite_stat1 has 15 records
 Table moz_hosts has 6291 records
 Index sqlite_autoindex_moz_inputhistory_1
 Index sqlite_autoindex_moz_keywords_1
 Index sqlite_autoindex_moz_favicons_1
 Index sqlite_autoindex_moz_anno_attributes_1
 Index sqlite_autoindex_moz_hosts_1
 Index moz_places_faviconindex
 Index moz_places_hostindex
 Index moz_places_visitcount
 Index moz_places_frecencyindex
 Index moz_places_lastvisitdateindex
 Index moz_historyvisits_placedateindex
 Index moz_historyvisits_fromindex
 Index moz_historyvisits_dateindex
 Index moz_bookmarks_itemindex
 Index moz_bookmarks_parentindex
 Index moz_bookmarks_itemlastmodifiedindex
 Index moz_places_url_uniqueindex
 Index moz_places_guid_uniqueindex
 Index moz_bookmarks_guid_uniqueindex
 Index moz_annos_placeattributeindex
 Index moz_items_annos_itemattributeindex
 Index moz_keywords_placepostdata_uniqueindex
  • Database size is 71680 KiB
  • History can store a maximum of 104858 unique pages
  • Table moz_places has 104026 records
  • Table moz_historyvisits has 281412 records

Un risparmio sicuramente interessante, ma sceso appena di –circa– 10 MB, ancora poco in confronto a un file che superava gli 80MB. Ho quindi scelto di mantenere esclusivamente gli ultimi 6 mesi di cronolgia di navigazione del browser, ottenendo (tramite lo stesso procedimento) un risultato nettamente più significativo:

Orphans expiration
 + Database cleaned up
 > Coherence check
 + The database is coherent
 > Vacuum
 Initial database size is 71680 KiB
 + The database has been vacuumed
 Final database size is 30720 KiB
  • Initial database size is 71680 KiB
  • Final database size is 30720 KiB

Un risparmio di circa 50MB rispetto al file originale, un sacrificio più che accettabile considerando che in 6 mesi ho certamente visitato siti web ai quali sono solito passare a fare un saluto, perdendo chi probabilmente non utilizzo così frequentemente (o non utilizzo più, tanto per farla più drastica). Il nuovo report fatto girare subito dopo il vacuum parla chiaro:

Statistics
 Database size is 30720 KiB
 user_version is 32
 page_size is 32768
 cache_size is -2048
 journal_mode is wal
 synchronous is 1
 History can store a maximum of 104858 unique pages
 Table moz_places has 40051 records
 Table moz_historyvisits has 55735 records
 Table moz_inputhistory has 165 records
 Table moz_bookmarks has 641 records
 Table moz_keywords has 0 records
 Table sqlite_sequence has 1 records
 Table moz_favicons has 2036 records
 Table moz_annos has 819 records
 Table moz_anno_attributes has 12 records
 Table moz_items_annos has 172 records
 Table sqlite_stat1 has 15 records
 Table moz_hosts has 3313 records
 Index sqlite_autoindex_moz_inputhistory_1
 Index sqlite_autoindex_moz_keywords_1
 Index sqlite_autoindex_moz_favicons_1
 Index sqlite_autoindex_moz_anno_attributes_1
 Index sqlite_autoindex_moz_hosts_1
 Index moz_places_faviconindex
 Index moz_places_hostindex
 Index moz_places_visitcount
 Index moz_places_frecencyindex
 Index moz_places_lastvisitdateindex
 Index moz_historyvisits_placedateindex
 Index moz_historyvisits_fromindex
 Index moz_historyvisits_dateindex
 Index moz_bookmarks_itemindex
 Index moz_bookmarks_parentindex
 Index moz_bookmarks_itemlastmodifiedindex
 Index moz_places_url_uniqueindex
 Index moz_places_guid_uniqueindex
 Index moz_bookmarks_guid_uniqueindex
 Index moz_annos_placeattributeindex
 Index moz_items_annos_itemattributeindex
 Index moz_keywords_placepostdata_uniqueindex
  • Database size is 30720 KiB
  • History can store a maximum of 104858 unique pages
  • Table moz_places has 40051 records
  • Table moz_historyvisits has 55735 records

Partito con un places.sqlite da più di 80MB e un webappsstore.sqlite da circa 101MB, mi ritrovo con 30MB circa di database cronologico ma un webappstore.sqlite ancora particolarmente obeso.

Ho cercato altri casi simili e mi sono imbattuto su una segnalazione di BugZilla: bugzilla.mozilla.org/show_bug.cgi?id=857888. È partita da un problema relativo a Firefox sul mondo Mobile, ma pare soffrirne anche la versione PC, come confermato anche da una discussione su Reddit (r/firefox)

PSA: Large webappsstore.sqlite file in your profile will heavily affect the responsiveness of Firefox’s UI from firefox

La scelta drastica? Rinominare il database webappsstore.sqlite per non farlo più trovare a Firefox (ovviamente chiuso) il quale lo ha creato da zero una volta riaperto, ho provato così a perdere la cronologia dei moduli e delle applicazioni utilizzate fino a quel momento:

Firefox: ottimizzazione dei DB SQLite 1

Il risultato? Ho utilizzato il profilo sul quale ho effettuato manutenzione per una settimana, ritenendolo adatto a diventare il principale perché la “perdita” non giustificava (secondo me) i rallentamenti sporadici del browser. Oggi sono fermamente convinto di aver fatto la scelta migliore, anche se fino a quando ci saranno siti web contenenti schifezze in Flash e simili, si continuerà ad avere un’occupazione importante del plugin-container.exe che permette a plugin (come quello Adobe) di girare in background, nonostante il Click-2-Play.

Occhio sempre a ciò che fai e dove metti le mani, ma mai abbandonare il tuo fido strumento di navigazione, potrebbe risentirne pesantemente la tua pazienza! ;-)

Ultimo aggiornamento: 5/7/16 10:20
Corretto dettaglio sui Segnalibri in places.sqlite (https://twitter.com/Gioxx/status/750243831132585985)
Condividi l'articolo con i tuoi contatti:

Scopro e studio un post uscito qualche giorno su Geekissimo, incuriosito da un test fatto da un amico sul forum di Mozilla Italia. Mi dice di aver provato quello strano tool disponibile per il download, dovrebbe riuscire a velocizzare l’avvio di Firefox.

Collegamento ad un anonimo Dropbox, scarico e apro dapprima con 7-Zip ed in seguito con Notepad++ per capire di cosa si tratta. Tutto si riassume nell’eseguibile di SQLite ed in un file batch che lancia un’istruzione secca sfruttando l’eseguibile stesso:

@FOR %%G IN (*.sqlite) DO ( sqlite3 %%G "VACUUM" )

Il comando VACUUM è ufficialmente sfruttato da SQLite e permette di:

When an object (table, index, or trigger) is dropped from the database, it leaves behind empty space. This empty space will be reused the next time new information is added to the database. But in the meantime, the database file might be larger than strictly necessary. Also, frequent inserts, updates, and deletes can cause the information in the database to become fragmented – scrattered out all across the database file rather than clustered together in one place.

In parole molto povere: dato un database di valori che vengono costantemente aggiornati (nel caso di Firefox succede con tutti i dati: segnalibri, password, cookie e altro ancora) la cancellazione di un qualsiasi dato lascia uno spazio “scoperto” (privo di valore) ma pur sempre conservato all’interno del DB. Il tutto succede fino al successivo riempimento di quello spazio. Ciò vuol dire che ci si trova davanti ad una normale “frammentazione” (lo stesso succede con l’hard disk ed un regolare uso del sistema operativo). Impossibile porre paletti a questa costante crescita, soprattutto con il passare del tempo.

Per questo motivo sarà possibile lanciare il comando VACUUM per:

The VACUUM command cleans the main database by copying its contents to a temporary database file and reloading the original database file from the copy. This eliminates free pages, aligns table data to be contiguous, and otherwise cleans up the database file structure.

… copiare i valori in un DB temporaneo per poi spostarli (tutto in modo automatico) nel DB originale a fine pulizia, con conseguente guadagno di spazio occupato su disco.

# quanti DB SQLite possiedo?

E’ presto detto. In un profilo standard sarà possibile trovare (grosso modo) questi file:

C:Documents and SettingsGiovanniDati applicazioniMozillaFirefoxProfilesXXXX.default>dir *.sqlite
Il volume nell’unità C non ha etichetta.
Numero di serie del volume: XXXX-YYYY

Directory di C:Documents and SettingsGiovanniDati applicazioniMozillaFiref oxProfilesXXXX.default

10/07/2009  17.51             7.168 content-prefs.sqlite
15/07/2009  16.43           495.616 cookies.sqlite
15/07/2009  16.35             9.216 downloads.sqlite
15/07/2009  16.50           299.008 formhistory.sqlite
30/06/2009  18.17             2.048 permissions.sqlite
15/07/2009  16.50         9.252.864 places.sqlite
06/07/2009  19.22             2.048 search.sqlite
25/05/2009  08.18            11.264 signons.sqlite
26/05/2009  09.57             3.072 webappsstore.sqlite
9 File     10.082.304 byte
0 Directory  132.868.112.384 byte disponibili

C:Documents and SettingsGiovanniDati applicazioniMozillaFirefoxProfilesXXXX.default>

Parliamo di circa 9 MB che dopo l’ottimizzazione sono passati a quasi 8, trattandosi di puro testo (salvato nei DB) non è affatto male ;-)

# il tool

Si tratta di un banale codice (comunque merito all’averci pensato) realizzato da InfoSpyware.com, il suo nome è IniFox, è stato presentato nel post (in lingua originale, spagnolo):

infospyware.com/blog/acelera-el-inicio-de-firefox-con-inifox

ed è disponibile gratuitamente anche su GxWare.org.

# la procedura

Innanzi tutto è d’obbligo mettere il solito avviso, che non fa mai male …

ATTENZIONE: Prima di eseguire qualsiasi modifica ai vostri file e/o dispositivi siete pregati di effettuare un backup di questi. Solo così sarete capaci di tornare indietro riparando ad eventuali errori di distrazione. L’articolo e l’autore non possono essere ritenuti responsabili di alcun danno subito dalla vostra strumentazione. Buon lavoro.

A questo punto i passi da seguire sono molto semplici, l’importante è aver scaricato e scompattato l’archivio contenente IniFox. Detto ciò, ecco il passo-passo:

  • CHIUDERE MOZILLA FIREFOX
  • Inserire i due file (batch & exe) di IniFox all’interno della cartella del proprio profilo. Per individuarla basterà consultare questo articolo nel support ufficiale di Mozilla Firefox: support.mozilla.com/it/kb/Profili#Individuare_la_cartella_del_profilo
  • Sarebbe bene fare un backup dei file *.sqlite dopo aver creato una cartella apposita. Personalmente ho optato per due veloci comandi dal prompt di MS-DOS, questo è quanto:
C:Documents and SettingsGiovanniDati applicazioniMozillaFirefoxProfilesXXXX.default>mkdir backup_gioxx

C:Documents and SettingsGiovanniDati applicazioniMozillaFirefoxProfilesXXXX.default>copy *.sqlite backup_gioxx
content-prefs.sqlite
cookies.sqlite
downloads.sqlite
formhistory.sqlite
permissions.sqlite
places.sqlite
search.sqlite
signons.sqlite
webappsstore.sqlite
9 file copiati.

C:Documents and SettingsGiovanniDati applicazioniMozillaFirefoxProfilesXXXX.default>
  • A questo punto si potrà lanciare (doppio clic o sempre dal prompt di Ms-Dos) il file “IniFox.bat” e attendere la fine del processo.
  • Aprire ora Mozilla Firefox per notare (probabilmente) un minor tempo di caricamento dell’interfaccia principale.

Il processo può essere (ovviamente) ripetuto più volte nel tempo (magari lasciate passare una o due settimane tra un’ottimizzazione e l’altra) e –una volta tantonon si tratta di applicativo invasivo che potrebbe mettere in pericolo i vostri dati (come invece spesso accade, nonostante si cerchi sempre di tenervi informati! ;)).

Cheers :-)

Condividi l'articolo con i tuoi contatti: