It seems related to the umbracoCacheInstruction table, but I don't know what that's doing. The database is in Azure and we're working with multiple devs on the same db. So it probably thinks it's load balanced. But even if only 1 dev is working this happens.
Do you have tons of instructions in that table ? If you have multiple devs working on the same db, then you are in fact load balancing. If these devs are doing stuff - like saving/creating/updating/etc... then it will add instructions to the table... these instructions need to be processed on each server that didn't create them.
Instructions are cache refreshing instructions - these will update/clear/create caches including xml caches and examine indexes.
So i assume that is why you are seeing this occur... because you have multiple devs doing multiple admin things.
... I hope you are not doing this on live because that is not supported.
no you cannot just delete the rows, otherwise your instance will have to 'cold boot' which means it will rebuild all indexes and xml caches from the raw database.
your instances will keep themselves up to date, it will store a lastsynced.txt in App_Data/DistCache
If they are already up to date and it's taking a long time to sync, then maybe you have a super slow db connection ?
You can put your logging in Debug to see if it's doing something funky while it's doing its Syncing from database stuff. You can also see the instruction Id on your install that you are synced too.
If your dev's are modifying / removing / updating doc types, etc... that would mean that your caches would basically have be totally rebuilt in some cases. 2 seconds doesn't seem like that long for those types of operations.
Syncing from database... takes a long time
Hello,
I've got a website on Umbraco 7.3.4. Regularly a page refresh takes a few seconds. Every time that happens I see the following in the log:
It seems related to the umbracoCacheInstruction table, but I don't know what that's doing. The database is in Azure and we're working with multiple devs on the same db. So it probably thinks it's load balanced. But even if only 1 dev is working this happens.
Can we do something about this?
Jeroen
Do you have tons of instructions in that table ? If you have multiple devs working on the same db, then you are in fact load balancing. If these devs are doing stuff - like saving/creating/updating/etc... then it will add instructions to the table... these instructions need to be processed on each server that didn't create them.
Instructions are cache refreshing instructions - these will update/clear/create caches including xml caches and examine indexes.
So i assume that is why you are seeing this occur... because you have multiple devs doing multiple admin things.
... I hope you are not doing this on live because that is not supported.
Hi Shannon,
There currently are 116 rows in the table. And yes we have multiple devs do multiple admin things. This is only on our dev setup and not live.
Could I just delete the rows? Xml caches and examine indexes aren't that important on our dev setup. Could manully refresh those if I want.
Jeroen
no you cannot just delete the rows, otherwise your instance will have to 'cold boot' which means it will rebuild all indexes and xml caches from the raw database.
your instances will keep themselves up to date, it will store a lastsynced.txt in App_Data/DistCache
If they are already up to date and it's taking a long time to sync, then maybe you have a super slow db connection ?
Hmm well it is an Azure db. It should be pretty fast. Thanks for the update :-).
You can put your logging in Debug to see if it's doing something funky while it's doing its
Syncing from databasestuff. You can also see the instruction Id on your install that you are synced too.If your dev's are modifying / removing / updating doc types, etc... that would mean that your caches would basically have be totally rebuilt in some cases. 2 seconds doesn't seem like that long for those types of operations.
Depending on your SQL Azure plan, it can be shared thus throttled and cause "random" penalties.
is working on a reply...