3 ms·

133ms latency (in the best case) is insanely bad for a database connection! Even just adding 100ms latency to Google's page load time had a clear measurably ef

• freehunter 11y ago
  I think the idea is not that slower speed would impact the Internet, but the Internet is built specifically to handle that kind of impact. Slowing it down would suck, but would not kill it. People managed just fine on dial-up, and the difference between 100ms delay and dial-up is enormous. The only thing it would impact is JS-heavy web apps that rely on pulling megs of content down very quickly. Stuff that looks and feels nice but is hardly necessary.
• tlarkworthy 11y ago
  No it isn't, average page load is much higher. It's a huge struggle to get below 300ms. Adding 100ms on its own is not insanely bad, but the head of line blocking would probably be terrible and that's what would annoy you most. EDIT: to those downvoting try cold loading google.com, I get > 200ms within San Francisco. 100ms is not "insanely" bad, and maybe a good price to pay for regulated data privacy
  • bobfunk 11y ago
    But it's 100ms each way for every database request while rendering the page! There's not a lot of apps out there that can do with 1 request to their database during an average page load.
    • tlarkworthy 11y ago
      I think we would adapt. GraphQL and http/2 are steps in the right direction but I expect we would move faster with a strong incentive :)
    • deleted 11y ago
      [deleted]
    • Retric 11y ago
      If you actually had that limitation you could redesign the overwhelming majority of apps to only need 1 DB request/response. EX: Stored procedure or map reduce