[Paper Review] Browser-based distributed evolutionary computation: performance and scaling behavior

J. J. Merelo, Antonio Mora-García+3 more|ArXiv.org|Jan 18, 2007

Peer-to-Peer Network Technologies13 references4 citations

TL;DR

This paper proposes DCoR (Distributed Computation on Rails), a browser-based framework using Ruby on Rails and AJAX to enable ad-hoc distributed evolutionary computation via web browsers. It demonstrates that while performance scales moderately with client count due to server-side bottlenecks—especially single-threaded request handling—optimizations like disabling debugging and reducing logging yield ~20% average improvement, highlighting the need for architectural changes to eliminate server bottlenecks.

ABSTRACT

The challenge of ad-hoc computing is to find the way of taking advantage of spare cycles in an efficient way that takes into account all capabilities of the devices and interconnections available to them. In this paper we explore distributed evolutionary computation based on the Ruby on Rails framework, which overlays a Model-View-Controller on evolutionary computation. It allows anybody with a web browser (that is, mostly everybody connected to the Internet) to participate in an evolutionary computation experiment. Using a straightforward farming model, we consider different factors, such as the size of the population used. We are mostly interested in how they impact on performance, but also the scaling behavior when a non-trivial number of computers is applied to the problem. Experiments show the impact of different packet sizes on performance, as well as a quite limited scaling behavior, due to the characteristics of the server. Several solutions for that problem are proposed.

Motivation & Objective

• To explore the feasibility of using web browsers as participants in distributed evolutionary computation without requiring special software.
• To evaluate the performance and scaling behavior of a browser-based evolutionary computation system using a web framework.
• To identify performance bottlenecks in the server architecture when handling multiple client requests.
• To propose architectural improvements to overcome server-side limitations and improve scalability.

Proposed method

• The system uses Ruby on Rails to implement a Model-View-Controller (MVC) architecture, enabling server-side logic and client-side JavaScript execution.
• AJAX with XmlHttpRequest enables asynchronous communication between clients (browsers) and the server, allowing non-blocking computation and real-time updates.
• Evolutionary computation is distributed via a farming model where clients evaluate chromosomes and send results back to the server.
• The server logs performance metrics such as evaluation rate (evaluations per second), which are used to analyze performance and scaling.
• Experiments vary packet size, population size, and network conditions (local, Fast Ethernet, WiFi), with clients joining sequentially.
• Performance is measured in a boxplot format across multiple runs, comparing development and production modes with and without debugging.

Experimental results

Research questions

• RQ1 Can web browsers be effectively used as computational nodes in distributed evolutionary computation without requiring application installation?
• RQ2 How does the performance of a browser-based evolutionary computation system scale with increasing numbers of clients?
• RQ3 What are the primary performance bottlenecks in the current server architecture when handling multiple browser clients?
• RQ4 How do server-side configurations—such as debugging mode and logging—impact overall system performance?
• RQ5 What architectural changes can significantly improve scalability and reduce server-side bottlenecks?

Key findings

• Scaling performance improves significantly with the first few clients but plateaus beyond four or five nodes due to server-side limitations.
• The server’s single-threaded request/response loop restricts concurrent processing, causing performance bottlenecks despite multi-threaded request handling.
• Disabling debugging and reducing log file I/O improves average performance by approximately 20%, indicating that logging is a major source of contention.
• Interlocking due to sequential logging causes thread contention, further degrading average performance despite improvements in best-case scenarios.
• The current architecture limits scalability, and architectural changes—such as using a cluster with a reverse proxy or shifting more computation to clients—are necessary to achieve meaningful scaling.
• Best-case performance continues to improve with more clients, but average performance gains slow to a halt, indicating diminishing returns due to system constraints.