let's assume that we are building a new Wikimedia-style service where (1) updates to articles will happen far more often and (2) access will be required via various protocols, not just HTTP. In this new service the application server looks like it will be a bottleneck. From a software point of view our application will turn into too much of a pain to add nontraditional servers (e.g., for access via cell phones, where the cell phones are frequently broadcasting their <a rel="nofollow" target="_blank" href="http://en.wikipedia.org/wiki/GPS">GPS</a> locations). From a systems point of view the response time looks like it will too slow because the Wikimedia application server is a central bottleneck.<br><br><br>To solve this lets look at a different architecture called an "application server herd", where the multiple application servers communicate directly to each other as well as via the core database and caches. The interserver communications are designed for
rapidly-evolving data (e.g., GPS-based locations) whereas the database server will still be used for more stable data that is less-often accessed or that requires transactional semantics. For example, you might have four application servers A, B, C, D such that A talks with B and C, and B and C talk with D, so that if a user's cell phone posts updates about its location to any one of the application servers then the other servers will learn of the change after one or two interserver transmissions, without having to talk to the database.<br> how well Twisted is suited for this kind of application and how well will it really work in practice. In particular, how easy is it to write applications using Twisted, and how maintainable and reliable those applications will be?what might be the pros n cons of using twisted.<br> any comments?<br><br>cheers<br>Pam<p> 
<hr size=1>Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. <a href="http://us.rd.yahoo.com/evt=51732/*http://overview.mail.yahoo.com/">See how.</a>