Hi MaryJo, sorry for the delay in responding. It’s been busy around here 
> We have about 7 cache areas set up for the different types of things we are caching on the site, which allows us to more easily configure the times and max items, etc.
Note, that there are a number of cache configurations that ONLY apply to the “cachebox” cache providers because it has its own stores that implement those settings (concurrent, JDBC, disk, etc) The Couchbase provider, for instance doesn’t have a max items configuration. You can set it, but it will be ignored. That’s because Couchbase server has no concept of max items.
All the possible config values that the Couchbase provider can use are here in the docs:
http://wiki.coldbox.org/wiki/CacheBox-Couchbase.cfm#Properties
> see how they are performing, hits vs. misses, evictions, etc.
Along the same lines, the Couchbase provider does not report misses or evictions because the underlying Couchbase server has no concept of them. Just something to keep in mind.
> when we tried to add a second set for our staging server.
I would set up a Couchbase cluster for each environment.
There is a max of 10 buckets, with 5 or less recommended
Yeah, there’s a lot of async processes that run for each bucket. Note, if you’re not using any views or XDCR that is reduced so you can probably get away with more. I don’t think the 10 is a hard limit (unless they changed that), if your buckets see very little use on your dev server you can try it and watch the CPU usage.
> They recommend using a bucket similar to a database, which should mean using the same bucket for all our items.
Well, maybe not an entire database, but one bucket for each functional area of related data. Here’s the thing though-- that advice applies to using Couchbase as a NoSQL document store and doesn’t really apply to caching. You’ll find that Couchbase courts the NoSQL crowd a lot more than the caching crowd so much of their advice is tailored to that usage scenario. If you’re not querying against a bucket, but just getting individual keys by ID, there’s not much reason not to just use one giant bucket with a key naming strategy to create “regions”. That’s how Memcahed works.
> But you’re supposed to set a “type” and index on that to improve performance and doesn’t look like cachebox does that?
Again, that’s talking about using Couchbase as NoSQL document store. Look at their beer sample bucket to see what they mean. They store beers and breweries in the same bucket and use a “type” property to tell them apart. That only matters because they are running queries against their views to select stuff out. None of that really applies to a cache.
Now I’ll note, CacheBox does wrap your data in a small JSON document just so we can store some extra meta data related to your payload, but it’s a transparent thing.
> And I know our client is not going to be happy with all the cache items showing up in one big giant report in the admin tool.
Well, I’ll be honest with you-- most caches don’t have an admin tool that shows you everything for one basic reason-- no one cares. I mean, people stick millions of items in caches and there’s just no value in bothering to look at them individually. In fact, if you get past several thousand items I wouldn’t recommend looking at the CacheBox monitor It will work, but there’s no pagination so it will be slow as crap. In fact, other mega-popular caching engines like Memcached have no way to even get a list of items! Generally, enterprise cache reporting is done at a macro level, not a per-item level. So basically, I wouldn’t get too married to a fun little report screen that shows the items even though it is cool.
So, that being said-- if your client feels they get good business value out of manually perusing large numbers of cached items, I would recommend building a custom paginated interface that just uses the underlying services. Though honestly, at that point, you really might as well just give them read-only access to the Couchbase admin where that work is already done for you.
http://docs.couchbase.com/admin/admin/UI/ui-settings-account-mgmt.html
> So I either have to combine a few caches to get it down to 5 per server setup, or consider installing couchbase on the staging server directly.
So, like I said before, I would totally have a separate stage server-- and Couchbase recommends being on dedicated hardware too-- sticking on your ColdFusion server could make it really fight for RAM and CPUs-- especially if you have a DB on that server too. And I would also recommend just one bucket if you can. There’s really no functional difference between 1 bucket for 7-- the main difference is reporting.
So, while I’ve been typing this E-mail I’ve formulated an idea-- it would be possible to have the Couchbase CacheBox provider FAKE cache regions to allow you to have a bunch of caches that pretend their separate but they really all just dump in one bucket. We would basically add a config for ‘cacheRegion’ and add that to the small JSON wrapper around each piece of data and prepend the item keys with the region name. The bucket-level reporting of hits, etc might still be global, but it would let you do some reporting on just the subset of keys that are in that “region”.
So, if that sounds useful-- here’s the skinny. We put out the Couchbase provider as our first Couchbase project-- before we even wrote the official SDK. Now even our SDK is going out of date because Couchbase rewrote their entire Java SDK from scratch 
So that said, Luis is unlikely to spend too much time enhancing the CacheBox provider right now just since it generates zero revenue for us. The two options that come to mind would be for you to give it a try and submit a pull request. The other would be if your company wanted to sponsor a project to update the Couchbase CacheBox provider.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
That might change when we have this couchbase server up and can safely cache a lot more but we’ll see!