quote:

---

> Hi,
>
> We are in the process of evaluating the CMS server 2002. I see from a
> previous post that there is a practical limit of 200 posts per channel.
>
> Is this something that is easily overcome by tuning caching? The problem

---

quote:

---

> that we will have 1-5 new small news update postings per day. Since these
> are items we will want to keep forever in 80-90% of the time, we will
> quickly fill a channel (the news items are all of the same nature so
> different channels based on topic won't work).
>
> I can imagine two ways to overcome this:
>
> 1) If you can expire news items after a certain time but still keep them

---

quote:

---

> the repository so that you can search for them and then display them. But

---

quote:

---

> guess this is a far reach since we can't index unpublished postings. What

---

quote:

---

> yoiu think?
>
> 2) Create archive channels as we go. Automatically move postings into
> archive channels after 30 days or so. This will keep the posting alive for
> indexing, but external links to the postings will break (I understand that
> internal links will be updated when a posting is moved - please let me

---

quote:

---

> if I am wrong). Is this a feasible solution? Is it possible to create a
> regular task that moves postings of a certain age into an archive channel,
> and create new channels when necessary?
>
>
> Thanks,
>
> Morten
>
>

---

quote:

---

> I am evaluating content management soloutions for my company, a fairly

---

quote:

---

> We are planning a major makeover on our website, and are looking to

---

quote:

---

>
> I wonder if there are some limitations on the number of postings in a

---

quote:

---

> Our site has about 1400 channels containing up to 20.000 postings per

---

quote:

---

>
> How would CMS2002 behave with such volume of postings per channel.
>
> Nils Otto

---

quote:

---

> Hi Nils Otto,
>
> I have had the same concerns, and below is the answer I got from Stefan.
> Apparently there is a significant drop in performance when you exceed only
> 200 items (postings or subchannels) per channel.
>
> We are designing a workaround where we are using hidden sub (and sub-sub)
> channels that are automatically created and arranged in the workflow so

---

quote:

---

> all content in the heavy traffic/update channels are automatically put in

---

quote:

---

> sub-sub channel that has content per week, which is in a subchannel per
> month. That way we can prevent performance drops for the main channel for
> 200 months, and by then hopefully Microsoft will have a better performing
> server... ;-)
>
> Here is Stefan's reply:
>
> ===========================
>
> Hi Morten,
>
> the details of the practical limitations are discussed in the following
> whitepaper:
>

---

quote:

---

>
> 1) will not work. It does not matter if the items are expired or not. The
> limitation is based on the fact that the item is in the channel the status
> does not matter
>
> 2) this would be feasible but you would still have to ensure that not more
> than 200-300 items are in a channel.
>
> I would suggest to use a different approach and create a multilevel
> structure:
>
> /Channel
> /topic
> /subc1
> /subc2
> /subc3
>
> whenever a subchannel fills up, you could create a new one beside the

---

quote:

---

> If you implement a clever navigation control you could easily hide the

---

quote:

---

> that the items are not directly stored in topic but in a subchannel below.
> This method successfully solves your problem. Please also ensure that not
> more then 200 sub channels are created. The limitation also affectes
> channels.
> Potentially you would have to create a structure like the following:
>
> /Channel
> /topic
> /subc1
> /subsubc1
> /subsubc2
> /subsubc3
> /subc2
> /subsubc1
> /subsubc2
> /subsubc3
>
> Cheers,
> Stefan.
>
> --
> This posting is provided "AS IS" with no warranties, and confers no

---

quote:

---

>
>
> "Morten Petterøe" <morten@imano.no_nospam> wrote in message
> news:uXaX8fn4DHA.1636@TK2MSFTNGP12.phx.gbl...
> is
these[QUOTE][color=darkred]
> in
But[QUOTE][color=darkred]
> I
What[QUOTE][color=darkred]
> do
for[QUOTE][color=darkred]
that[QUOTE][color=darkred]
> know
channel,[QUOTE][color=darkred]
>
>
> "Nils Otto" <anonymous@discussions.microsoft.com> skrev i melding
> news:3AD15E24-29E8-48A4-8057-2EF397908766@microsoft.com...
> large media-company.
> MSCMS2002.
> channel.
> channel today. This numbers will increase.
>
>

---

quote:

---

> Hi all,
>
> Here is some more insight about the problem:
>
> There are a few problems, all of which are quite disabling.
> First, URL transformations will be slowed down tremendously. Instead of
> iterating over 50 - 400 items to find the one you need, CMS will iterate
> over 5000-10000. Each of these items gets added to the cache, which means
> that the cache will generally become less effective (if you have a 20000
> item cache, and you have 10000 postings in a channel (each one consisting

---

quote:

---

> both an item for the posting, and an item for the content), you will blow
> out your cache each time you hit any page in that channel).
>
> As well, any time you access any item in that collection by any method

---

quote:

---

> than GetNodeByGUID, CMS will load the entire collection into memory in

---

quote:

---

> to sort it, security trim it, etc. This means that again, you blow out

---

quote:

---

> cache, and you also tend to consume a lot of memory for this session (CMS
> wraps each of these objects in a user API object, etc.) It also takes

---

quote:

---

> to load, sort, etc.
>
> Finally, the majority of the UIs are not implemented with this usage in
> mind. E.g. they do not support paging of data, etc.
>
> Bottom line:
> Higher memory consumption
> More database activity
> Lower cache hit ratio
> slower runtime performance
> possibly unusable UI pieces due to the amount of data that would need to

---

quote:

---

> displayed (such as picking a posting to hyperlink to in the hyperlink

---

quote:

---

> box)
>
> Cheers,
> Stefan.
>
>
>
> --
> This posting is provided "AS IS" with no warranties, and confers no

---

quote:

---

>
>
> "Morten Petterøe" <morten@imano.no_nospam> wrote in message
> news:ebepxfj5DHA.3548@TK2MSFTNGP11.phx.gbl...
only[QUOTE][color=darkred]
sub-sub)[QUOTE][color=darkred]
> that
in[QUOTE][color=darkred]
> a
for[QUOTE][color=darkred]
performing[QUOTE][color=darkred]
>

---

quote:

---

The[QUOTE][color=darkred]
status[QUOTE][color=darkred]
more[QUOTE][color=darkred]
> other.
> fact
below.[QUOTE][color=darkred]
not[QUOTE][color=darkred]
> rights.
channel.[QUOTE][color=darkred]
problem[QUOTE][color=darkred]
> these
them[QUOTE][color=darkred]
> But
> What
> for
> that
a[QUOTE][color=darkred]
> channel,
>
>

---

quote:

---

> Thanks Stefan,
>
> Knowing what to look for to increase performance is always a good thing. A
> couple of things here are very clarifying, especially that CMS loads the
> entire collection to memory on all other search methods than a single GUID
> retrieval. A bit inefficient, isn't it? A simple reordering of execution
> sequence here would help a lot, by for example perform the search first so
> that you only have a small subset to sort, security trim etc... Just my

---

quote:

---

> bits...
>
>
> Morten
>
>
>
> "Stefan [MSFT]" <stefang@online.microsoft.com> wrote in message
> news:e$1fpvl5DHA.2344@TK2MSFTNGP09.phx.gbl...
means[QUOTE][color=darkred]
consisting[QUOTE][color=darkred]
> of
blow[QUOTE][color=darkred]
> other
> order
> the
(CMS[QUOTE][color=darkred]
> time
> be
> dialog
> rights.
Stefan.[QUOTE][color=darkred]
> only
> sub-sub)
so[QUOTE][color=darkred]
> in
per[QUOTE][color=darkred]
> for
> performing
following[QUOTE][color=darkred]
>

---

quote:

---

> The
> status
> more
> below.
> not
a[QUOTE][color=darkred]
> channel.
> problem
will[QUOTE][color=darkred]
> them
them.[QUOTE][color=darkred]
into[QUOTE][color=darkred]
alive[QUOTE][color=darkred]
understand[QUOTE][color=darkred]
me[QUOTE][color=darkred]
create[QUOTE][color=darkred]
> a
fairly[QUOTE][color=darkred]
a[QUOTE][color=darkred]
per[QUOTE][color=darkred]
>
>

---