Hi, I have recently played with the UDP protocol in memcached and I realized that multipacket set requests in UDP protocol is not implemented!! I also read this thread and it just makes me sure that it is not implemented at all. Actually, I was wondering about the reasons for this issue?! why it is not implemented?! Isn't it needed at all? Or this feature has lower priorities?
I'm considering sending 1M set requests in UDP and it is not possible for now! :) Thank you, Alireza On Saturday, March 17, 2018 at 10:48:05 PM UTC+3:30, Dormando wrote: > > Got it. > > Mind if we talk through this a bit? I have a feeling you'll do okay > without UDP. > > Are you looking at 1M sets + 1M gets/sec per memcached or for the whole > cluster? > > UDP sets can't be multi-packet; it's not implemented at all. Jumbo frames > may help (I forget if the MTU is discovered internally). It's relatively > hard to do multi-packet requests since you have to manage timeouts on the > server and no other code paths do this. > > Also, if you're using dalli there should hopefully be a method of stacking > requests down connections with async callbacks? I've not looked at the API > in a very long time. > > Binprot has "set quiet" and opaque's (message id's) for all queries. Which > means updates can be simply stacked down the pipe without blocking on > responses. Also lookups can be stacked down as the requests come in, while > still waiting for a previous response. > > Just pure quiet binprot sets (with significant batching) can easily do > 500k+ sets/sec with a single TCP connection. It might be as high as 1m, > I'll have to check again. With less batching you'd need a few more > connections/processors. > > Since the UDP code isn't using much batching wise nor REUSEPORT the > performance ceiling is presently much lower than the TCP protocol, > ironically. > > On Sat, 17 Mar 2018, Robert Gil wrote: > > > We haven't started tuning for UDP. That module was a PoC because all the > other memcache modules were _incomplete_ in terms of feature set. We use > > namespaces for different things like threats, assets, users, containers, > etc. The plan is to also use pools to scale the memory and allow for easier > > distributed update across all ingestion nodes. > > > > I plan to start testing using UDP and dalli, but if dalli doesn't do the > trick, we'll re-write with the java client lib. For the UDP lookups, a > single > > key should be fine in 1400 bytes for common lookups like IPs. We can > also consider jumboframes (9000) for increased payload. Multi packet sets > may be > > necessary, especially if we do lookups on commonly exploited URI > patterns with long URIs. > > > > With regard to testing, i'd like to PoC this with the goal of doing 1M > events/s with 1M lookups/s for enrichment. > > > > On Sat, Mar 17, 2018 at 2:58 PM, dormando <[email protected] > <javascript:>> wrote: > > Hey, > > > > That is exactly the use case I would expect out of UDP! Thanks for > > responding so quickly. > > > > In your example module I can't quickly figure out how UDP is > configured > > (it just seems to import dalli and use it?) > > > > Are you using multi-packet responses for UDP lookups? If you're > running > > sets via UDP they can't be more than 1400 bytes in size (more like > > 1300ish). That's generally been okay? > > > > On Sat, 17 Mar 2018, Robert Gil wrote: > > > > > I still have a use case for it. We're looking to make the > highest performing enrichment for log ingestion possible. > > > > > > > https://www.elastic.co/blog/elasticsearch-data-enrichment-with-logstash-a-few-security-examples > > > > > > > In the use case described above, we aim to enrich as close to > real time as possible for log ingestion. Small, light, lookups... non > > blocking updates for > > > threat and other security related feeds. > > > > > > We're not too concerned about misses since we need to back > enrich/compare against data that has already been ingested. > > > > > > Thoughts? > > > > > > Rob > > > > > > On Sat, Mar 17, 2018 at 2:22 PM, dormando <[email protected] > <javascript:>> wrote: > > > Not sure how active this list is anymore :P > > > > > > Are any of you still listening users of the UDP protocol? > If so, mind > > > reaching out to me (here or privately) to explain your use > case? > > > > > > I'm thinking around some long term options with it; one is > to turn it into > > > a compile flag, and another is to keep it (and update it > with SO_REUSEPORT > > > and *_mmsg under linux) but restrict responses to single > packet. It can > > > still be useful for fire-and-forget cases (ie; spraying > touch's or > > > fetching flag keys asynchronously), but there isn't much > use for it > > > otherwise these days. > > > > > > Thanks, > > > -Dormando > > > > > > -- > > > > > > --- > > > 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] <javascript:>. > > > 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] <javascript:>. > > > 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] <javascript:>. > > 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] <javascript:>. > > 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.
