First of all, umbraco has some really good ideas and some nice features but its really lacking when it comes to quality.
Ive just used umbraco for just a few projects, mostly maintaining some old ones. Probably spent a few weeks total with umbraco and there is some stuff that really makes my backhair curl.
First of all, when upgrading to a newer version and the setup fails its usually silent, upgrading is one of the most important part of a cms, make sure it never just fails like that.
It seems like there is a new version released ever couple of days with critical bugs and some are really basic, how can we trust version xxx.5 if xxx.4 was completely broken? There need to be a lot more testing perhaps release a new version every 4 weeks but with one week just fixing bugs?
Umbraco 5 was a sad buisiness...you are building a CMS and the C stands for content so make sure it can handle it. You should develop umbraco to work with 10.000 pages and it should still be fast.
Today i was going to make a list of images. I prefer razor and i tried writing out 15 links to some media by using var media = Model.MediaById(@x) and then @media.umbracoFile and @media.Name. Those 15 links added 1 second load time to the page.. thats insane!
So i figured ok perhaps umbraco 4.7 was super slow so its time to upgrade this site to 4.11.4. The upgrade seems to work but to see any pages i need to republish the tree, one root node at a time. After increasing the timeout to a minute i could publish the smaller parts with 50 or so pages...insanely slow again. Now im trying to increase the timeout to several days so I just might be able to republish the 3500 pages big site over night. This is just mindblowing!
Umbraco performance is horible, all the sites i've seen are slow and no, using xpath and parsing xml is not a valid option!
Yeah I know that instead of complaining I should help since it's "open source" but I'm a site developer not a CMS developer.
Please do not add any more features until you get decent performance and stability.
I'm sorry but I tend to agree. I LOVE working with Umbraco, but every version seems to bring new problems with it. The memory footprint of the applications are increasing like hell, when you have a website with a lot of media items, the site slows down to a crawl (and the memory footprint is HUGE) ...
We get new features all the time (and that's good for a CMS), but we'd like to see Umbraco's stability and performance increase first.
Welcome to the forums. I have to say that all your points are valid and solid observations. Umbraco still has some work to do on performance, you can always improve on performance.
I've been working with Umbraco for over 4 years now and there are still some quirks in there from even way back then. When ever I find one the best thing I can do with it is log it as an issue (http://issues.umbraco.com). There the team know about it and can deal with it, if you don't log it they won't know about it. As a site developer I'd encourage you to do the same so that the CMS developers can do their end of the bargain. It takes just a few minute to log an issue and at least when you do there is the chance of some good coming out of it and maybe a fix or improvement in one of those too frequent releases you mention. Talking of which they should settle down now as discussed on their blog http://umbraco.com/follow-us/blog-archive/2013/2/6/v6-is-here,-what's-next.aspx Plus when you release a website do you ever get it right first time everytime? Ever forgot to upload something, delete something, email the boss? Umbraco are no different except when they forget something they have to bump up the minor/patch number each time, but they ARE working on keeping that to a minimum as discussed in the blog post above.
The razor issue you had is an interesting one. It could be a simple issue with the way you are writing your code and would warrant a separate question here on our so we might be able to optimise it for you. The razor engine is simply a wrapper over the top of the XML cache, its written for speed of development not speed of execution (although it can be damn fast) and it is possible for it to become a "leaky abstraction" (http://www.joelonsoftware.com/articles/LeakyAbstractions.html) if used in some ways. Maybe someone can shed some light on your code to see if there is a more performant way of achieving what you want while still sticking with Razor. If you don't ask you won't know.
Every year I've worked with Umbraco is has grown in strength, features, userbase, performance and reliability in one way or another. The last 6 months since CodeGarden (when V5 was killed) have been amazing for stability, performance and getting a decent release cycle/system in place. All good things. The Umbraco guys are working as hard as they can to deliver a great product and I'm sure a crack of the whip like this will actually encourage them on to do more, things can always get better, we all have the same goals.
We all have frustrations at times in all our lines of work, the trick is trying to channel the energy from those frustrations to where they can do good and hopefully make those frustrations go away for yourself and ideally others. Log your issues, post questions about code thats sluggish and help others if they too are having issues. In return I (and 100's like me on here) will do the same ;)
My memory is a bit foggy but i am pretty certain that earlier versions of umbraco did not cache the media items anywhere (examine these days? please correct me if i am wrong). So that meant that every time you wanted a grab a media item you were hitting the database. And 10 items in a loop would mean 10 database queries, at least.
The performance impact of that annoyed me too like hell, so Ive had a small cache-thingy for getting media items on pretty much all sites ive done the past year or so. Eventually I shoved it into my LinqToUmbraco project, but this is probably not an issue anymore.
I am yet to download a completely broken version of umbraco, I like the steady flow of small updates. Continuous delivery is great, no need to wait for bug fixes and patches.
The installer and updating I agree with you about, it's just not good enough, but I am certain it will become better pretty soon.
After the upgrade and some unknown things happening (probably just enough cache rebuilding) it seems to be quite fast again (that 1.6 second to render a simple page went to 60ms which is quite okey). I guess 4.7 was very immature when it came to the media library.
When umbraco works it is quite nice to develop for, the way macros and razor works together with dynamics makes it nice and quick to write a site.
I really do like that the site can upgrade itself although it would be nice if it was a bit more verbose when it crashes, and since the developers knows stuff like if you upgrade from version x to version y you need to do A and B it should either just do that as well or at least give out a warning text. 90% of all the errors seems to be related to an old dll that must be removed from the bin folder and the only way to discover it is to google for half an hour.
And absolutetly, it does seem like v6 is going the right direction and hopefully most of the troubles ive had are a thing of the past.
I've been using Umbraco for a while now too and there are some fairly grand pit falls in developing with it, but only in the same sense that there are with any software. I love the fact that if a bug is found, a fix is made and included in a new release so quickly. After v5, the work that was done to re-address the roadmap and general direction must've been quite mammoth, and I love the dedication that shows. Check out v6 for the Umbraco team's dedication to performance improvement.
With regards to the Model.MediaById() peformance issue, Umbraco will first look in your Examine indexes for the relevant Media, but if it can't find it then it will revert to using the old-school umbraco.library.GetMedia() which will make a hit on the database. In the same call, it will also try an re-index the Media item so that future calls are quicker. If you have your Examine indexes disabled (by default they won't be) or if for some reason you haven't got the index folders in place, then 15 calls will be fairly slow, and this might be compounded by any other traffic you have hitting the database.
I would run SQL Profiler against the site and see what activity it is trying to do whilst your page loads.
Finally, personally I would stick with Umbraco. I have made some slow sites but I have also made some lightning quick ones too. The slow ones I am dying to revisit to see where *I* went wrong.
Tommy, please post your code to print those images and render that page, here we've built 6--7 sites on Umbraco in the past year and have had issues yes, but generally, it's blazing fast, client is completely happy with working in the back office (this is tough normally) and as developpers we've managed not to have to skew the CMS too much to do what we want so again, complete satisfaction.
We use Sitecore as a commercial alternative to Umbraco for bigger projects and they go hand in hand together from my point of view. Maybe the quality and polish you are looking for can be found in commercial CMS, but get your $ ready.
@foreach (var mediaId in Convert.ToString(@Model.list).Split(',')) { var media = Model.MediaById(@mediaId ); <a href="@media.umbracoFile" >@media.Name </a> }
But as i said when upgrading from 4.7 to 4.11 it became quite fast without any code change so it was probably just hitting the database a lot and since our SQL is on another server in the developer environment database ping time really added up.
Now I hit another slow spot though in another part of the code
var member = umbraco.cms.businesslogic.member.Member.GetCurrentMember(); <img src="@Model.MediaById(member.logo).umbracoFile" />
That first line seems to take about 100ms in my scenario and well it was for a profile logo that was supposed to be on every page so of course 100 ms isn't acceptable (manually caching it would be an option but it would still be quite bad to have 100ms hit on the first load). The "shortest" xml path I found was 5 times as big when counting codelines...
var memberId = Convert.ToInt32(currentUser.ProviderUserKey); var memberIterator = library.GetMember(memberId); var memberXml = System.Xml.Linq.XDocument.Parse(memberIterator.Current.OuterXml).Root; var logoXML = memberXml.XPathSelectElement("./data[@alias=\"logo\"]"); var logo = logoXML!=null ? logoXML.Value :""; <img class="logo" src="@Model.MediaById(logo).umbracoFile" />
As far as I understand the member part has been fixed in v6 so when i upgrade next time it might work ok. Still, basic functions like that shouldn't be that slow and still be released into the wild.
Lacking quality control
First of all, umbraco has some really good ideas and some nice features but its really lacking when it comes to quality.
Ive just used umbraco for just a few projects, mostly maintaining some old ones. Probably spent a few weeks total with umbraco and there is some stuff that really makes my backhair curl.
First of all, when upgrading to a newer version and the setup fails its usually silent, upgrading is one of the most important part of a cms, make sure it never just fails like that.
It seems like there is a new version released ever couple of days with critical bugs and some are really basic, how can we trust version xxx.5 if xxx.4 was completely broken? There need to be a lot more testing perhaps release a new version every 4 weeks but with one week just fixing bugs?
Umbraco 5 was a sad buisiness...you are building a CMS and the C stands for content so make sure it can handle it. You should develop umbraco to work with 10.000 pages and it should still be fast.
Today i was going to make a list of images. I prefer razor and i tried writing out 15 links to some media by using var media = Model.MediaById(@x) and then @media.umbracoFile and @media.Name. Those 15 links added 1 second load time to the page.. thats insane!
So i figured ok perhaps umbraco 4.7 was super slow so its time to upgrade this site to 4.11.4. The upgrade seems to work but to see any pages i need to republish the tree, one root node at a time. After increasing the timeout to a minute i could publish the smaller parts with 50 or so pages...insanely slow again. Now im trying to increase the timeout to several days so I just might be able to republish the 3500 pages big site over night. This is just mindblowing!
Umbraco performance is horible, all the sites i've seen are slow and no, using xpath and parsing xml is not a valid option!
Yeah I know that instead of complaining I should help since it's "open source" but I'm a site developer not a CMS developer.
Please do not add any more features until you get decent performance and stability.
I'm sorry but I tend to agree. I LOVE working with Umbraco, but every version seems to bring new problems with it. The memory footprint of the applications are increasing like hell, when you have a website with a lot of media items, the site slows down to a crawl (and the memory footprint is HUGE) ...
We get new features all the time (and that's good for a CMS), but we'd like to see Umbraco's stability and performance increase first.
Hi Tommy,
Welcome to the forums. I have to say that all your points are valid and solid observations. Umbraco still has some work to do on performance, you can always improve on performance.
I've been working with Umbraco for over 4 years now and there are still some quirks in there from even way back then. When ever I find one the best thing I can do with it is log it as an issue (http://issues.umbraco.com). There the team know about it and can deal with it, if you don't log it they won't know about it. As a site developer I'd encourage you to do the same so that the CMS developers can do their end of the bargain. It takes just a few minute to log an issue and at least when you do there is the chance of some good coming out of it and maybe a fix or improvement in one of those too frequent releases you mention. Talking of which they should settle down now as discussed on their blog http://umbraco.com/follow-us/blog-archive/2013/2/6/v6-is-here,-what's-next.aspx Plus when you release a website do you ever get it right first time everytime? Ever forgot to upload something, delete something, email the boss? Umbraco are no different except when they forget something they have to bump up the minor/patch number each time, but they ARE working on keeping that to a minimum as discussed in the blog post above.
The razor issue you had is an interesting one. It could be a simple issue with the way you are writing your code and would warrant a separate question here on our so we might be able to optimise it for you. The razor engine is simply a wrapper over the top of the XML cache, its written for speed of development not speed of execution (although it can be damn fast) and it is possible for it to become a "leaky abstraction" (http://www.joelonsoftware.com/articles/LeakyAbstractions.html) if used in some ways. Maybe someone can shed some light on your code to see if there is a more performant way of achieving what you want while still sticking with Razor. If you don't ask you won't know.
Every year I've worked with Umbraco is has grown in strength, features, userbase, performance and reliability in one way or another. The last 6 months since CodeGarden (when V5 was killed) have been amazing for stability, performance and getting a decent release cycle/system in place. All good things. The Umbraco guys are working as hard as they can to deliver a great product and I'm sure a crack of the whip like this will actually encourage them on to do more, things can always get better, we all have the same goals.
We all have frustrations at times in all our lines of work, the trick is trying to channel the energy from those frustrations to where they can do good and hopefully make those frustrations go away for yourself and ideally others. Log your issues, post questions about code thats sluggish and help others if they too are having issues. In return I (and 100's like me on here) will do the same ;)
Cheers
Pete
My memory is a bit foggy but i am pretty certain that earlier versions of umbraco did not cache the media items anywhere (examine these days? please correct me if i am wrong). So that meant that every time you wanted a grab a media item you were hitting the database. And 10 items in a loop would mean 10 database queries, at least.
The performance impact of that annoyed me too like hell, so Ive had a small cache-thingy for getting media items on pretty much all sites ive done the past year or so. Eventually I shoved it into my LinqToUmbraco project, but this is probably not an issue anymore.
I am yet to download a completely broken version of umbraco, I like the steady flow of small updates. Continuous delivery is great, no need to wait for bug fixes and patches.
The installer and updating I agree with you about, it's just not good enough, but I am certain it will become better pretty soon.
After the upgrade and some unknown things happening (probably just enough cache rebuilding) it seems to be quite fast again (that 1.6 second to render a simple page went to 60ms which is quite okey). I guess 4.7 was very immature when it came to the media library.
When umbraco works it is quite nice to develop for, the way macros and razor works together with dynamics makes it nice and quick to write a site.
I really do like that the site can upgrade itself although it would be nice if it was a bit more verbose when it crashes, and since the developers knows stuff like if you upgrade from version x to version y you need to do A and B it should either just do that as well or at least give out a warning text. 90% of all the errors seems to be related to an old dll that must be removed from the bin folder and the only way to discover it is to google for half an hour.
And absolutetly, it does seem like v6 is going the right direction and hopefully most of the troubles ive had are a thing of the past.
I've been using Umbraco for a while now too and there are some fairly grand pit falls in developing with it, but only in the same sense that there are with any software. I love the fact that if a bug is found, a fix is made and included in a new release so quickly. After v5, the work that was done to re-address the roadmap and general direction must've been quite mammoth, and I love the dedication that shows. Check out v6 for the Umbraco team's dedication to performance improvement.
With regards to the Model.MediaById() peformance issue, Umbraco will first look in your Examine indexes for the relevant Media, but if it can't find it then it will revert to using the old-school umbraco.library.GetMedia() which will make a hit on the database. In the same call, it will also try an re-index the Media item so that future calls are quicker. If you have your Examine indexes disabled (by default they won't be) or if for some reason you haven't got the index folders in place, then 15 calls will be fairly slow, and this might be compounded by any other traffic you have hitting the database.
I would run SQL Profiler against the site and see what activity it is trying to do whilst your page loads.
Finally, personally I would stick with Umbraco. I have made some slow sites but I have also made some lightning quick ones too. The slow ones I am dying to revisit to see where *I* went wrong.
Tommy, please post your code to print those images and render that page, here we've built 6--7 sites on Umbraco in the past year and have had issues yes, but generally, it's blazing fast, client is completely happy with working in the back office (this is tough normally) and as developpers we've managed not to have to skew the CMS too much to do what we want so again, complete satisfaction.
We use Sitecore as a commercial alternative to Umbraco for bigger projects and they go hand in hand together from my point of view. Maybe the quality and polish you are looking for can be found in commercial CMS, but get your $ ready.
The Code that was slow was this
@foreach (var mediaId in Convert.ToString(@Model.list).Split(',')){
var media = Model.MediaById(@mediaId );
<a href="@media.umbracoFile" >@media.Name </a>
}
But as i said when upgrading from 4.7 to 4.11 it became quite fast without any code change so it was probably just hitting the database a lot and since our SQL is on another server in the developer environment database ping time really added up.
Now I hit another slow spot though in another part of the code
That first line seems to take about 100ms in my scenario and well it was for a profile logo that was supposed to be on every page so of course 100 ms isn't acceptable (manually caching it would be an option but it would still be quite bad to have 100ms hit on the first load). The "shortest" xml path I found was 5 times as big when counting codelines...
As far as I understand the member part has been fixed in v6 so when i upgrade next time it might work ok. Still, basic functions like that shouldn't be that slow and still be released into the wild.
Model.MediaById in 4.7 used the Media object which is very slow. Since 4.7.2 I think it uses Examine which is much faster.
For the member it might be good to look at this topic: http://our.umbraco.org/forum/developers/extending-umbraco/27626-Accessing-Member-Information?p=0#comment103415
Jeroen
Thanks for all the support but I was mainly writting the post to compain and not to get help :)
Umbraco sure has the friendliest forums though!
is working on a reply...