@J_Kerwin
Compression is really only suggested for Archivers. The reason for this is that it takes time to decompress the needed meta/log information if you are using compression. Archivers should never be used as Investigation sources. Instead they should only be used as reporting sources due to the time it takes to decompress the underlying database files. This decompression can last longer than the Investigation UI's timeout window and provide an unsatisfactory experience. Some customers have successfully used Investigation against Archivers but this is not tested or supported due to the variability in performance.
If you do use compression on a concentrator and/or log decoder but they are getting close to their maximum throughput, the decompressing of these files could cause processing backups when returning Investigation results. These backups may take the form of delayed pulling of logs from event sources, missed UDP syslog messages, or delayed results in the concentrators. If you have virtual log collectors this can help buffer the log decoders if there is slowness, but this will only help so much and won't do much for concentrators with performance issues.
Based on all of this, it really comes down to your mileage may very based on the situation of your environment. We don't have statistics that I am aware of that shows the impact of compressed verses uncompressed data on our log decoders or concentrators. All I can tell you is that it is best to experiment cautiously to determine if your environment can work effectively with compression turned on. Just remember that even if it works now, this does not mean you won't run into issues in the future with performance if you continue to add event sources to your NetWitness environment.
I know this is probably not the exact answer you were hoping for, but I wanted to make sure you understood the difference between what is possible and what is appropriate for your NetWitness environment.
