jvaleski

4 ms·

1. 1.▲
   by jvaleski 16y ago

   check your facts by reaching out to Twitter directly. I'm Jud Valeski, CEO of Gnip (jud@gnip.com). So we're all running on factual data, apparently a problem these days,... Twitter's value added resellers (e.g. Gnip and DataSift) must... -
2. 2.▲
   by jvaleski 16y ago

   the solution I used leveraged non-blocking I/O in a roundabout way. 150 separate procs (quick and dirty) per instance. no threads. I let the OS manage the I/O in that regard. My thinking was that if I had "a lot" of procs trying I/O... I'd
3. 3.▲
   by jvaleski 16y ago

   I can confirm billions of files/keys. I went the quick/dirty route to parallelize the DELETEs and just let the OS manage the async I/O for me at the proc level. Each instance spun up 150 Ruby procs that issued the DELETEs (tight, serial, wh
4. 4.▲
   by jvaleski 18y ago

   classic problem. xmpp was designed for this, but we've found it non-trivial (not rocket science either, but non-trivial) to setup/use. ejabberd is solid once it's up and running, but it's a black box once it's going (with exception of some