Dropbox debugging, day umpteen

  I've lost count of the number of days I've spent working on this issue. It's becoming clear as I rearchitect my web presence that building on Dropbox was probably not the best idea. There were elements of greatness, stuff to be excited about in theory, but in practice, maybe not so much.
  First. I think I'm pushing it in ways that no one else is. When I get to the bottom of what's causing the performance issues here, it's going to be something I'm doing that you're not doing.
  Second. I'm kind of sure I know what the difference is going to be...
  I have Apache configured on one of my servers such that its root directory is a top-level directory in the Dropbox hierarchy that all my servers, desktops, iPads, iPhones, Droids and laptops share. I think it's the connection with Apache that's driving everything crazy.
  I can't know because Dropbox is a black box that I can't see inside. There's no rule that says you can't give a folder to Apache to serve from. It's pretty neat when you do. It means that any node on the network can cause something to be published by writing a file to a folder. There was a time when this performed pretty well. Or so I seem to remember. It's like the Fog of War, keeping these servers running. The last week I've been desperately and slowly trying to lift the fog and get scientific about it. But the science is hindered by a lack of understanding of how Dropbox works.
  Luckily, I'm getting special service. The CTO of the company is in the loop. So maybe we can figure this out. Maybe there's something I can tell Apache not to do to keep Dropbox from thinking it's always got to be doing something that not only flatlines the computer it's running on, but sends so much noise to the other nodes that they happily consume all the cycles on the machines they're running on.
  That's my status report for near-mid-day on Sunday. Stay tuned for updates. :-)