Blog @ Digital Bazaar

Fibers are the Future: Scaling Web Services Past 100K Concurrent Requests (Part 2/2)

In a blog post last month, we outlined why a traditional Apache+PHP setup will inevitably fail the growing needs of medium to large AJAX-based websites. The article is continued this month by analyzing different methods of scaling web services past the concurrency barrier inherent in a basic Apache+PHP setup.

While speaking with the technical minds of several companies in our industry, there were several very good questions raised about assumptions we had made when building our system. The feedback from the first blog post about this topic revolved around the following two questions:

• Why would anybody need to scale to 100K (one hundred thousand) concurrent web service requests?
• Isn’t database layout and server bandwidth the primary scalability issue for web services?

We tend to forget that not everybody spends their time thinking about scaling to this level. Scalability requirements that are quite natural to us sometimes come off as exceedingly steep web service requirements to others. The questions above are ones that we have grappled with in the past. Here are the answers that we’ve found over the past several years through vigorous internal debate.

Important questions to ask when scaling past 100K connections…

1 Comment

1. Another common drawback of fiber-based systems is that you’re circumventing the OS and its understanding of your program’s parallelism. This means that if you happen to have a multicore or multiple CPUs, a traditional fiber system will not allow you to scale onto those other cpus.

   This is something a fiber-based system for modern architectures would have to take into consideration, such that there are multiple schedulers instead of a single one. (He says, feverishly trying to finish his own fiber system)

   Another thing to point out is that there’s definitely some pressure to move away from SQL and full-fledged databases towards something that can scale better. The proliferation of cloud datastores is one sign. Another is the idea that a p2p based datastore can actually be quite reliable and allow you to scale easily*.

   I say “move away”, but if it’s anything like other technology, they’ll pull to one side and meet in the middle somehow.

   * Chord – http://pdos.csail.mit.edu/chord/
   Similar idea, in video: http://skillsmatter.com/podcast/erlang/building-a-transactional-distributed-data-store-with-erlang

   Comment by Jonathan Turner — October 22, 2008 #

Sorry, the comment form is closed at this time.