To be honest I wasn't aware that I had to re enable the Database after every up2date
I guess it's just a matter or re- running :
1)cc set http sc_local_db [Your Choice] (without the []) for me its: mem
2) /var/mdw/scripts/httpproxy restart
The database size will remain the same after an up2date
****:/root # ls -lh /var/chroot-http/var/pattern/sfcontrol
total 359M
trust me. IF it gets properly enabled and it is working you won't have to time things..the leap in performance is that obvious...unless you are next door to a cffs server(which is highly unlikely). The process is not supported....while it works for most apparently either you aren't typing something right, your system can't handle it, or it just simply isn't going to work for you.
To be honest I wasn't aware that I had to re enable the Database after every up2date
I guess it's just a matter or re- running :
1)cc set http sc_local_db [Your Choice] (without the []) for me its: mem
2) /var/mdw/scripts/httpproxy restart
The database size will remain the same after an up2date
****:/root # ls -lh /var/chroot-http/var/pattern/sfcontrol
total 359M
Thanks
Wait.... is this true? I have to set it back to mem after every update? I've been having problems again and was wondering what might be the issue. Is there anyway to check the status of the variable?
If you recently did an up2date you have to reenable the mem or disk option otherwise you are on the cloudy servers again
I'm pretty sure that that isn't true - unless a developer actively disables the feature in a up2date, it should work in the same way like anything else you've configured on your ASG.
You can check the local filtering status with:
cc get http sc_local_db
My ASG still returns "disk" after updating to 8.103.
i've done that and it's been inaccurate. since it is not supported i'm sure they don't try to make it it is unaffected by proxy up2dates. i've always reset it after any up2date that touches the proxy and since many of them do i just re-enable for all up2dates.
