I'm building a custom navigation for SP2013 that uses termstore to manage the menu items reasonably. This technet article covers basic termstore limitations, but it doesn't touch on the following problem:

How many items can I reasonably expect to query from the termstore?

Currently, as it's a tree-like navigation, I request items recursively, going breadth-first, asking all the items at level 1, then all the children for those items, then the grandchildren and so forth.

What I've noticed is, however, that past a certain point, I don't get a response.
For example, asking for 36 items succeeds, while asking for 44 fails.
Does it matter that I'm asking for a number of properties for each item (title, parent, terms, etc.)?
On a different site, asking for 60 items succeeds easily.

What could be the reason and how many items can I reasonably query at the same time (from termstore and in general)?

1 Answer 1


I have run into this before on a couple sites. The performance/response degradation was at vastly different points for each farm once we introduced high concurrency, but consistent within each farm. The number of terms we were dealing with in both cases was significantly more than 60... I was not able to find an authoritative answer for performance bounds, this is the closest I ever found:


In both cases we opted to manage a rudimentary cache based off System.Web.Caching which immediately solved the problem. Terms in the term store are unlikely to change very often so they are great candidates for aggressive caching.

Due to the relatively low number of terms you're working with, I would be suspicious of anything else that might be going on at the same time. Also, we would eventually see timeouts reported in the ULS logs when this happened. Are you seeing any reproducible errors?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.