Most effective cache_ bins to enable?

Adding ALL cache bins,to APC works very well - BUT it will take a lot of memory.
I have allocated 'all Drupal cache* to APC bins', but I have allowed APC 1024Mb's.
Fragmentation occurs when APC space is limited, and/or there a lot of deletes.
My settings.php for this:

      $conf += array(
        'cache_inc'        => './sites/all/modules/cache_backport/cache.inc',
        'cache_backends'   => array('./sites/all/modules/apc/drupal_apc_cache.inc',),
        'apc_show_debug'   => FALSE,
        'page_cache_without_database' => TRUE,
        'page_cache_invoke_hooks'     => FALSE,
        'page_cache_maximum_age'      => 3600,
        'cache_lifetime'              => 0,
        'session_inc'      => './sites/all/modules/cacherouter/session.inc',
            'cache_default_class'               => 'DrupalAPCCache',
            'cache_class_cache'                 => 'DrupalAPCCache',
            'cache_class_cache_block'           => 'DrupalAPCCache',
            'cache_class_cache_bootstrap'       => 'DrupalAPCCache',
            'cache_class_cache_content'         => 'DrupalAPCCache',
            'cache_class_cache_filter'          => 'DrupalAPCCache',
            'cache_class_cache_form'            => 'DrupalAPCCache',
            'cache_class_cache_menu'            => 'DrupalAPCCache',
            'cache_class_cache_page'            => 'DrupalAPCCache',
            'cache_class_cache_pathdst'         => 'DrupalAPCCache',
            'cache_class_cache_pathsrc'         => 'DrupalAPCCache',
            'cache_class_cache_session'         => 'DrupalAPCCache',
            'cache_class_cache_session_user'    => 'DrupalAPCCache',
            'cache_class_cache_update'          => 'DrupalAPCCache',
            'cache_class_cache_users'           => 'DrupalAPCCache',
            'cache_class_cache_views'           => 'DrupalAPCCache',
            'cache_class_cache_views_data'      => 'DrupalAPCCache',
      );

My fragmentation level holds at a average of 0.20%
Notes: I also use a modified session cache (sim to memcache-session.inc).
In general, you must double apc.shm_size in relation to APC's highest reported Memory;
that is take your allocated php.ini memory value and then double it for APC (apc.shm_size)!

Fragmentation Explained

Fragmentation is a measure of the non-available portion of apc.shm_size due to lack of contiguous memory large enough to accept new cache items. 100% fragmentation means the available memory is broken into hundreds of small pieces that are too small to accept new cache items. This occurs when cached items expire and new cached items fill their vacated memory slots; usually the new item is slightly smaller than the old item, and the leftover space may be too small for a new cache item.

Fragmentation can cause even a large amount of free memory to be unavailable for new cache items. That is why I say above you can avoid fragmentation by doubling the apc.shm_size in relation to the largest total memory usage you see. So you may want to start with 100MB, let the site run for a few hours during high traffic conditions, and then reduce shm_size to roughly double the highest amount of cache memory usage during that time.

If you can’t raise apc.shm_size due to lack of available memory, try lowering the TTL’s (values in seconds, 0 is no limit, 600=10minutes, etc.). This will still have a good effect on high-traffic sites with many concurrent end users; caching is not at all necessary for low-traffic sites. However, be aware that lower TTL’s can cause more fragmentation.

See this link for cache type performance compare :-> http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-compari...

Some interesting 'reports / bugs' from the PECL APC developer site:

[2009-12-16 11:46 UTC] rasmus@php.net

The TTL is used for opportunistic cache expiration. It is
not used when the cache hits %100 full. It is simply too
slow to walk through the entire cache looking for entries to
TTL out. When we hit 100% (which you should try hard to
avoid) we dump the entire cache because that can be done
quickly.

The user cache was not designed to hold a lot of short
expiry entries. The single lock design simply doesn't
support that. It is for very static blocks of data that
ideally doesn't change for weeks.

[2011-08-11 03:03 UTC] gopalv@php.net

I checked out this bug - this only chokes if apc_bin_* functions are used.

That pools all allocations for an entire cache-set, so the memory for expiring entries are not cleaned up (because it's a single allocation).

If you aren't using apc_bin_* functions, re-open the bug. I will be fixing the documentation about it, soon.

Most effective are the ones which do not change often so cache, cache_bootstrap, cache_tokens etc.