Design, Prototype Implementation, and Comparison of Scalable Web-Push Architectures on Amazon Web Services Using the Actor Model

Abstract

Push technology has become an essential part of many web applications that require near real-time notification. The Hypertext Transfer Protocol (HTTP) is widely used for exchanging information between clients and servers. The growth of the Internet of Things (IoT) and the expansion/penetration of Internet access to new areas have resulted in the ever-rapidly increasing number of Internet users. Consequently, scalability has become one of the key requirements of modern web applications. One of the challenging problems of scalability is scaling out web-push applications since they are constrained by unshareable resources and their stateful nature. Amazon Web Services (AWS) is the leading cloud service provider that offers a variety of services. Web-push applications can leverage the services that AWS provides. Developers can build their entire service stack on Amazon Elastic Compute Cloud (EC2) if other services cannot fulfill their business requirements. To enable the scalability feature, a centralized message mediator is needed to orchestrate and coordinate messages across the web-push nodes. The publish-subscribe pattern should be implemented from upstream to downstream in order to optimize the flow of data. This paper examines the technologies that could be used as building blocks to create scalable web-push applications, and proposes three architectures using three different messaging services, i.e., Amazon Simple Notification Service (SNS), Redis Pub/Sub, and Apache ActiveMQ. A couple of push and pull models as well as an adaptive push/pull model are introduced and experimentally compared in this paper. The actor model, on account of its being a robust model, is used for handling concurrency and for coordinating the flow of messages between a messaging server and a web client. We created a chat room application to evaluate the architectures with different criteria and conditions, and the push technology used our experimentation was WebSocket. From our experiment, we found that Amazon SNS performed relatively poorly compare to the other two due to the overhead of web services calls. The architectures using Redis Pub/Sub and ActiveMQ performed equally well even though the ActiveMQ server took more time to process messages. We acknowledge that there are a large number of factors involved in and potentially affecting the performance, and that the response time is merely one of the properties that ought to be considered in making a design decision.