Ticket

1.9.2 Very Poor Performance with content type creating - huge wait times?

is it possible to bulk create/delete tens of content types on the fly in ORchard wihtout any performance problem? Did you have such an experience?

Please ask me if you need any more clarificcation

Re: 1.9.2 Very Poor Performance with content type creating - huge wait times?

You should use recipes for bulk creation or deletion of content types. I never noticed it to be that slow, but they do require a shell restart if I'm not mistaken, which might take more time than most requests. If you do see such performance issues however, you should probably file a bug.

Monday, April 25, 2016 8:31:10 PM bybleroy
  • bleroy
  • Lv. 08 Rookie
  • Total EXP: 527

Re: 1.9.2 Very Poor Performance with content type creating - huge wait times?

I did some testing and noticed that the more content types exist, the slower the ContentDefinitionManager becomes when creating new types. For reference, creating the first 100 content types took around 2 seconds. Creating another 100 took around 5 seconds. Creating the next 100 took around 17 seconds. Even after flushing an starting new requests. Looking at its implementation, it isn't that surprising. It seems that it wasn't designed for bulk creation.

One way to deal with this is to create a custom service that does support bulk creation of types in a highly performant manner. Or file a bug as Bertrand suggests.

Saturday, May 7, 2016 10:34:16 AM bysfmskywalker

Re: 1.9.2 Very Poor Performance with content type creating - huge wait times?

Thank you very much Bertrand and Sipke! I I appreciate your help.

Wednesday, May 11, 2016 10:29:27 AM bybyorchard

Re: 1.9.2 Very Poor Performance with content type creating - huge wait times?

I just opened a new issue in github with this title: "1.9.2 Very Poor Performance with content type creating - huge wait times? #6885"

Also my developer has been working on it and got at least some progress even tough we still got serious problems. here is his comment regarding to the issue:

" That was caused by the faulty cache implementation: content type cache is globally locked during content type creation and any queries against it cause a full refresh (we have 1000 content types right now, so all of them were reloaded twice for each app in the pack). " The problem is: 1) when End user tries the process often, cache problem appears.. if I start the proces 4-5 times in order, some time it takes 8 seonds to finish bu most of times it takes more than 2 minutes..

2) Due to the way we use content types, there will be many being created - like hundreds of thousands or even millions.. in this case how come many numbers of concurrent users can use the platform without orchard cache problem..?

As always I appreciate your time, Thanks in advance

Thursday, May 12, 2016 1:04:06 AM bybyorchard

Re: 1.9.2 Very Poor Performance with content type creating - huge wait times?

1000 content types sounds crazy. Why do you need that? Hundreds of thousands or millions sounds completely nuts. The way you use content types is probably very wrong. Can you share some more details so we can suggest a better design?

Thursday, May 12, 2016 7:19:18 AM bybleroy
  • bleroy
  • Lv. 08 Rookie
  • Total EXP: 527

Re: 1.9.2 Very Poor Performance with content type creating - huge wait times?

In our application use case, there is an app store which consists of packs and apps. Apps are content types, and packs are a bundle of apps which are being installed together. Users install apps or packs into their workspace to use them; such as Contacts app which is a content type with number of content fields. Then to add new data records for this app, user creates content items.

an app: content type -> app records (actual data entry): content item

we have already around 500 different apps in app store.. when each user installs them, new content types are being created on the fly per installation. Therefore, content type number will increase exponentitally..

Same in pack creation sample: "web Application Development pack" consists of more than 7-8 apps. Each app is a different content type. So when user starts installing, system creates related content types on the fly..

Now Our problem is in "often content type creation/update/deletion", Orchard is not designed for that. Please let me know if it is possible to overcome the fact that any content type creation/update/deletion causes cache invalidation which is killing performance in a multi-user environment.

Thursday, May 12, 2016 8:21:19 AM bybyorchard

Re: 1.9.2 Very Poor Performance with content type creating - huge wait times?

Thanks for the details, but that doesn't really explains why you think those things should be content types. Why not a single "App" or "Pack" content type? Why aren't those data records just managed with one of the many ways Orchard lets you build relationships? It sounds like if for modeling a population of cats by having a Cat type and many instances of cats, you'd have a Felix type, and a Mittens type, and so on, one per cat. What am I missing?

Thursday, May 12, 2016 11:38:09 PM bybleroy
  • bleroy
  • Lv. 08 Rookie
  • Total EXP: 527

Re: 1.9.2 Very Poor Performance with content type creating - huge wait times?

The problem is that:

1) Apps are not only totally different from each other with different field types in it, but also they are created by end users.

2) and even after user installed an app from app store, user can change every detail of that app which makes it become a new content type..

here is the life cycle for an app:

1) in app builder, an end user can create his own app. He decides to set every single details of the app and then put different field types in it ..

2) After app is done, user can publish it to app store to share this app with other users.

3) another uer can see and install this app from app store into his own workspace

4) after installing he can start to use it directly or he can change everything about the app - where system takes the user to app builder screen as in creating the app from the scratch...

5) this changed app can then be even published to the app store as a new app

I hope I can clarify little bit more... please ask me if you got any more question.

And I really would like to get your opnion on: "if it is possible to overcome the fact that any content type creation/update/deletion causes cache invalidation which is killing performance in a multi-user environment."

Friday, May 13, 2016 10:03:11 AM bybyorchard

Re: 1.9.2 Very Poor Performance with content type creating - huge wait times?

That does clarify, thanks. The conclusion I would draw from that is that a type system will never be a good fit. Instead, you need something schemaless. I would manage a part with a document in it, where you manage all these variant fields. Something similar to the layout feature, where elements are persisted into a document.

Another possibility would be to take advantage of a little known feature of the Orchard content type system, which is that parts and fields can be welded onto a content item at runtime. This is how content types are actualized from their description onto the content items in fact. The idea here would be to have a special part that has its own "content type definition" stored on the part rather than on an external, static list of types. The driver for that part would look at this local definition and would dynamically weld the parts and fields from it.

But the default type system was never designed to do what you're trying to make it do, and I strongly advise against it.

Friday, May 13, 2016 6:10:08 PM bybleroy
  • bleroy
  • Lv. 08 Rookie
  • Total EXP: 527

Post a reply

You need to be signed in to post a reply.

Sign In