Used Vorto on a few sitesw now and its a great package, however my current project is quite big and Vorto has been used comprehensibly throughout for most facets of the project.
While doing a SQL trace log i noticed that Umbraco does a DB call for what appears to be every field on a page using Vorto.
exec sp_executesql N'SELECT COUNT(*) FROM [umbracoLanguage] WHERE ([umbracoLanguage].[id] <> @0)',N'@0 int',@0=0
i have tested this on Umbraco sites that use Vorto (the same happens but to a lesser degree) and also verified on a site that doesn't use vorto and the DB calls arent made at all.
This basically amounts to 300+ DB calls per page load and is flooding the server and creating significant waiting times.
Is anyone else experiencing this?
Can anyone point me in the direction of making this a cached call or does Umbraco cache this information by default?
But you are using the management API so the assumption is that there will be database interaction - as there is with all of the management API services. Especially when doing something like .GetAllLanguages(), this makes sense I believe. The context here is that you are using the API to do what you could also do from the backoffice.
In general, unless you're creating a management type of site, you'll want to avoid using the management API for any front-end rendering - you probably already know this, but it does seems ot be a common mistake so for anyone else who come across this.
now you have said it out loud that makes perfect sense, none of this is my code, i have inherited the project from another developer whom is no longer at my company and to be honest, i am a bit of an Umbraco noob, so you can drop me in the common mistake pile :)
If i wanted to access those values on the front end, what would be the best way to get them? Currently i have it cached as the likelyhood a new language will get added is pretty slim and would invoilve work from us anyway.
Hundreds of DB calls
Hi there,
Used Vorto on a few sitesw now and its a great package, however my current project is quite big and Vorto has been used comprehensibly throughout for most facets of the project.
While doing a SQL trace log i noticed that Umbraco does a DB call for what appears to be every field on a page using Vorto.
exec sp_executesql N'SELECT COUNT(*) FROM [umbracoLanguage] WHERE ([umbracoLanguage].[id] <> @0)',N'@0 int',@0=0
i have tested this on Umbraco sites that use Vorto (the same happens but to a lesser degree) and also verified on a site that doesn't use vorto and the DB calls arent made at all.
This basically amounts to 300+ DB calls per page load and is flooding the server and creating significant waiting times.
Is anyone else experiencing this?
Can anyone point me in the direction of making this a cached call or does Umbraco cache this information by default?
thanks in advance,
Mike.
figured it out, for the record this was NOTHING to do with Vorto, we had some erroneous code that was calling the below in a loop.
i would have thought Umbraco should cache values like that though.
@Mike
But you are using the management API so the assumption is that there will be database interaction - as there is with all of the management API services. Especially when doing something like .GetAllLanguages(), this makes sense I believe. The context here is that you are using the API to do what you could also do from the backoffice.
In general, unless you're creating a management type of site, you'll want to avoid using the management API for any front-end rendering - you probably already know this, but it does seems ot be a common mistake so for anyone else who come across this.
Hey Paul, thanks for replying!
now you have said it out loud that makes perfect sense, none of this is my code, i have inherited the project from another developer whom is no longer at my company and to be honest, i am a bit of an Umbraco noob, so you can drop me in the common mistake pile :)
If i wanted to access those values on the front end, what would be the best way to get them? Currently i have it cached as the likelyhood a new language will get added is pretty slim and would invoilve work from us anyway.
is working on a reply...