Should I have separate application pools for Service Applications?

Question

So I've looked high and low for a best-practice, and a practical practice to this: Should I separate each of my service applications in a SharePoint 2010 installation into different application pools?

In my particular instance, we'll be starting off with only a 2 server installation (1 SQL server, all SP services running on a second server), and will only be deploying Excel, PerformancePoint, User Profiles, Search, BDC, and maybe Visio. However, additional service apps and additional servers (and possibly farms for geography) may be added later as our deployment & usage of SharePoint expands.

I feel that having separate AppPools & AppPools accounts would be overkill, even if it follows least privileged principals. Maybe separate pools for each Application Proxy Group?

What are your guys thoughts on the topic?

(NB. I will be separating each of my web applications into their own application pool.)

Answer 1

The generally held view is that Service Applications can happily co-exist in a single Application Pool for a small server farm like you have suggested. As you scale out your farm you should carefully consider the app pool architecture.

If you try to put all your service applications into seperate application pools as well as all your web applications and consider the other app pools that are configured by the install then you will need som beefed up RAM on that box which is definitely overkill.

Scale approriately is the key.

Any 'Best Practice' for SharePoint 2010 should be taken with a large pinch of the white stuff for at least the next 6 months (if you know what I mean.)

Answer 2

Well my thought would be to categorize the service applications into some logical groups and allocating an application pool per group. Further Assigning each group with a seperate account. For instance you can logically decide your User Profile, SSS, STS to use the same application pool while the Visio, Excel service can have a different one.