Il problema principale con una cache di grandi dimensioni è il tempo di GC completo. Per darti un'idea potrebbe essere 1 secondo per GB (varia da un'applicazione all'altra) Se hai una cache da 20 GB e la tua applicazione si ferma per 20 secondi, ogni tanto è accettabile?
Come fan dei file diretti e di memoria mappati, tendo a pensare in termini di quando non dovrei entrambi estrarre i dati dall'heap e utilizzare semplicemente l'heap per semplicità. ;) I file mappati in memoria non hanno quasi alcun impatto sull'intera durata del GC indipendentemente dalle dimensioni.
Uno dei vantaggi dell'utilizzo di un file mappato in memoria è che può essere molto più grande della memoria fisica ed eseguire comunque ragionevolmente bene. Questo lascia il sistema operativo per determinare quali parti devono essere in memoria e quali devono essere scaricate sul disco.
BTW: Anche avere un SSD più veloce aiuta;) Anche le unità più grandi tendono ad essere più veloci. Controlla le IOP che possono eseguire.
In questo esempio, creo una memoria di file da 8 TB mappata su una macchina con 16 GB. http://vanillajava.blogspot.com/2011/12/using-memory-mapped-file-for-huge.html
Nota: offre prestazioni migliori nell'esempio di file da 80 GB, 8 TB probabilmente superano l'uccisione. ;)
fonte
2012-01-20 07:52:18
La risposta alla tua domanda dipende più dalle caratteristiche di utilizzo della cache che dalla dimensione della cache. Ad esempio, rapporto di lettura/scrittura, TTL, dimensione degli oggetti che stai memorizzando, il numero di oggetti che potresti memorizzare. Inoltre, la tua domanda sta ponendo una domanda piuttosto confusa. Cosa considereresti "troppo lungo?" o "Pronto per il prime time?" Devi sapere che tipo di SLA ti serve prima di poter realmente valutare qualsiasi soluzione di caching. Tempo di risposta massimo in ms e percentuale di hit SLA. – allingeek