Ho un'applicazione che legge un file binario di grandi dimensioni (1 GB in media) e si comprime in un archivio bzip2. All'inizio ho iniziato a comprimere questi file in modo sincrono, poiché non volevo impedire le prestazioni su un computer client. A volte tuttavia, questi file arrivano a raffica e mi piacerebbe gestire questi file il più rapidamente possibile. Quindi ho riscritto il metodo per utilizzare una chiamata asincrona future
. Sono memorizzati in un vettore fino al completamento e quindi vengono distrutti.
Durante il mio stress test, ho notato che avrei inevitabilmente avuto un problema con l'utilizzo della CPU se, diciamo, 5 file entrassero in una volta su una macchina a 4 core. La macchina client sarebbe praticamente inutilizzabile fino al completamento di tutte le operazioni.
Quindi, questo mi porta alla domanda di design. Sono inesperto con i futures e cerco di determinare le migliori pratiche per mitigare l'utilizzo elevato della CPU. Questo è il design che ho in mente ma prima di passare attraverso il problema di battere il punto e virgola, c'è una caratteristica più nativa del futuro di cui non sono a conoscenza?
- Determina quante CPU sono disponibili per la macchina host
- Dividere il numero di CPU della metà per evitare più del 50% di utilizzo della CPU dall'applicazione
- Utilizza un ciclo su un thread separato per gestire gli oggetti futuri memorizzati in
vector
. - Il loop rileva quando un oggetto non è più in ambito e avvia il prossimo
vector
future
oggetto di compressione
Questo sarebbe il modo migliore per andare?
Grazie!