I suspect the biggest 'problem' with upping the maximum object size isn't performance, per se, but memory efficiency (performance-wise, I think you'll peg your network interface long before you break memcached). If you use (e.g.) a slab size of 128MB, you're probably going to 'lose' 10MB+ for every item you store in the upper slab classes, unless the objects you're storing happen to line up just perfectly with your slab sizes.
You can potentially decrease the waste with careful tuning of your chunk growth factor (-f option), but that will cut down on the number of items you can have in any given slab class... basically as you become more memory efficient, your expected time-until-eviction for any given object will probably decrease. I suspect the only time pushing your limits way up would be workable would be if your items all tend to have one of a small number of sizes (rather than being more evenly distributed through a large size range), so that they all end up in a fairly small number of slab classes, and you can tune for those sizes specifically. (Unless, of course, you're talking about wanting to bump the max value to like... 1.1MB, which shouldn't be any more of an issue than the default 1MB... but I'm assuming that's not what you're doing.) -j On Wed, Sep 10, 2014 at 12:43 PM, Ryan McElroy <[email protected]> wrote: > The real issue, in my opinion, is that if you have values anywhere close > to 1MB in size, what you probably actually have are values that are > *unlimited* in size and therefore expanding the size you can store in > memcached is just a stopgap measure and doesn't solve the underlying > problem. > > Most of the best practices for memcached (eg using it as a demand-filled, > look aside cache and using deletes for consistency) work best when data is > chunked into small units that you fetch several if rather than a large set > of data that you only use parts of. > > Your mileage may vary, so do what makes sense for your use case, but > without info about specific things you're trying to accomplish, this is the > best generic advice I have to give people wondering about the size > limitations. > > I am personally unaware of performance implications. > > ~Ryan (mobile) > > On Sep 10, 2014, at 8:52 AM, Olivier Martin <[email protected]> wrote: > > Hi all > > I am trying to find feedbacks on using memcached with entry size superior > to 1Mo, the default value. > Since 1.4.2., it is possible to change this setting by configuration but > i can't find any feedback on the performance and throughput. > I have seen a couple posts prior to 2010 who said that is not a good idea > to increase this value and to prefer chucking the value in several > memcached entries. > Do someone have some relevant information, benchmark, graphics on this use > case? Is keeping the default value still a best practice? > > Thanks for your feedback > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
