Subarna Chatterjee
email: subarna.chatterjee@inria.fr

Christine Morin
email: christine.morin@inria.fr

Experimental Study on the Performance and Resource Utilization of Data Streaming Frameworks

Keywords: Stream processing, Apache Flink, Apache Spark, Twitter Heron, Internet of Things

With the advent of the Internet of Things (IoT), data stream processing have gained increased attention due to the ever-increasing need to process heterogeneous and voluminous data streams. This work addresses the problem of selecting a correct stream processing framework for a given application to be executed within a specific physical infrastructure. For this purpose, we focus on a thorough comparative analysis of three data stream processing platforms -Apache Flink, Apache Storm, and Twitter Heron (the enhanced version of Apache Storm), that are chosen based on their potential to process both streams and batches in real-time. The goal of the work is to enlighten the cloud-clients and the cloud-providers with the knowledge of the choice of the resource-efficient and requirement-adaptive streaming platform for a given application so that they can plan during allocation or assignment of Virtual Machines for application execution. For the comparative performance analysis of the chosen platforms, we have experimented using 8-node clusters on Grid5000 experimentation testbed and have selected a wide variety of applications ranging from a conventional benchmark to sensor-based IoT application and statistical batch processing application. In addition to the various performance metrics related to the elasticity and resource usage of the platforms, this work presents a comparative study of the "green-ness" of the streaming platforms by analyzing their power consumption -one of the first attempts of its kind. The obtained results are thoroughly analyzed to illustrate the functional behavior of these platforms under different computing scenarios.

I. INTRODUCTION

The inception of the Internet of Things (IoT) has witnessed massive data explosion due to the exponential growth of devices and the innumerable applications running within them [START_REF] Mozaffari | Mobile unmanned aerial vehicles (uavs) for energy-efficient internet of things communications[END_REF], [START_REF] Dong | Memsbased smart gas metering for internet of things[END_REF]. Therefore, data-intensive systems are gaining increasing importance today. Data stream processing comprises the heart of such systems which is why several stream processing frameworks co-exist today [START_REF] Gorawski | A Survey of Data Stream Processing Tools[END_REF], [START_REF] Ranjan | Streaming big data processing in datacenter clouds[END_REF]. Every stream processing framework is different in terms of the set of applications that it can serve, the unit (batch, or micro-batch, or streams) and nature (bounded or persistent) of dataset that it can handle, the type of processing it offers (at-least-once or at-most-once or exactly-once), the hardware requirements, and the scalability potential. Thus, it is extremely important to choose the correct streaming platform that would serve a specific application in a given available cluster. It is extremely difficult to choose "the" streaming framework that would suit the needs of an application and as well would have resource requirements within the limits that the underlying physical infrastructure can possibly offer. Despite the existence of several work that present a comparative study of data stream processing frameworks, such type of analysis regarding "how to efficiently choose a streaming platform for an application" is still to be discovered. Therefore, deriving such knowledge towards selection of application-and infrastructure-based streaming frameworks induces research interest and attention.

In this work, we focus on thoroughly comparing and analyzing the performance and resource utilization of three streaming platforms and eventually make an inference about the various applications that are suitable to be launched within each of these platforms and the various aspects of the physical infrastructure that each can support. Based on the potential to process both streams and batches in real-time and the popularity of usage, in this work, we have chosen Apache Flink [START_REF] Carbone | Apache flink: Stream and batch processing in a single engine[END_REF], Apache Storm [START_REF] Toshniwal | Storm@twitter[END_REF], and Twitter Heron [START_REF] Kulkarni | Twitter heron: Stream processing at scale[END_REF] as the stream processing frameworks to be studied.

A. Motivation

As mentioned earlier, several prior works exist on comparative study and analysis of streaming platforms. However, there are some observed limitations of each of these works which are discussed as follows: (i) Recent release of Heron: The open-source version of Twitter Heron was released in 2016. Therefore, the existing literature on comparative studies of streaming frameworks does not include any analysis of the performance of Heron. Heron was introduced as an enhanced version of Apache Storm and so it is extremely important to analyze and compare its performance with the other streaming frameworks. (ii) Analysis of energy-efficiency: Existing works illustrate the comparison of the streaming frameworks in terms of the data throughput, the utilization of the communication network, the processing latency, and the fault-tolerance. However, a study and analysis on the energy consumption of the platforms is still to be found. The energy efficiency of a streaming platform is extremely important owing to the global responsibility towards the eco-friendly use of computers and thereby reducing the environmental impact of the IT operations. (iii) Choice of framework for different scenarios: A streaming platform cannot be categorized as "good" or "bad" as every platform is differently designed to process specific stream types. Each platform is unique about the nature of data sets, the variable message processing semantics, and the differential hardware expectations. Therefore, it is extremely difficult, yet crucial, to judicially select the streaming platform that not only suits the application requirements but also abides by the resource offerings of the physical infrastructure of the host organization (or an end-user). This might be of particular interest for cloud end-users while choosing Virtual Machines (VMs) in an infrastructure cloud for Infrastructureas-a-Service (IaaS) or for cloud providers while allocating VMs to end-users in a Platform-as-a-Service (PaaS) cloud. An insight of the rationale behind the choice of a streaming platform is not yet discussed in prior existing works and is therefore one of the major focus of this work.

B. Contributions

The contributions of the work are multi-fold and are discussed as follows: (i) Heron is included: The proposed work is one of the first attempts towards a Heron-inclusive comparative study and analysis of the popular streaming frameworks. In this work, we have selected Apache Flink, Apache Storm, and Twitter Heron as the frameworks for comparison. The rationale behind this choice is that, in addition to being open-source and the popularity of their usage, all these platforms have the ability to process true streams in real-time. (ii) Metrics studied: This work compares Flink, Storm, and Heron with respect to a multitude of parameters. The work focuses to analyze the performance of the frameworks in terms of the volume and throughput of data streams that each framework can possibly handle. The impact of each framework on the operating system is analyzed by experimenting and studying the resource utilization of the platforms in terms of CPU utilization, memory consumption. The energy consumption of the platforms is also studied to understand the suitability of the platforms towards green computing. Last, but not the least, the fault-tolerance of the frameworks is also studied and analyzed. (iii) Applications tested: In this work, we have selected a wide variety of real-life representative applications ranging from the conventional benchmark (word count application) to sensorbased IoT application (air quality monitoring application) to statistical batch processing (flight delay analysis application). Metric are thoroughly analyzed for each application and the variation of the metric is thoroughly studied and inferred. (iv) Insights on choice of framework: One of the primary contributions of this work is to enlighten the readers with the insights and rules for selecting a particular framework for a particular streaming application to be run within a given infrastructure. Every metric for a particular application is analyzed from the perspective of resource utilization and quality of service thereby inferring the suitability of the platform under variable computing scenarios. These lessons can be very helpful in cloud computing scenarios while allocating or deploying VMs in PaaS or IaaS cloud, respectively.

II. RELATED WORK

Many stream processing frameworks are discussed in the literature [START_REF] Stonebraker | The 8 requirements of real-time stream processing[END_REF]- [START_REF] Lopez | A performance comparison of open-source stream processing platforms[END_REF]. Nabi et al. [START_REF] Nabi | Of Streams and Storms[END_REF] performed a direct comparison of IBM InfoSphere with Storm, whereas, Samosir et al. [START_REF] Samosir | An evaluation of data stream processing systems for data driven applications[END_REF] focused on the comparison among Storm, Spark, Samza, and Hadoop ecosystems. Another work [START_REF] Perera | Reproducible experiments for comparing apache flink and apache spark on public clouds[END_REF] on comparative experimentation between Flink and Spark proposed benchmarks for the platforms and validated the performance of the frameworks on the proposed benchmarks. But, since Spark is essentially a batch-processing platform, the effective comparative analysis among real-streaming platforms was still absent. Over time, both Flink and Storm gained popularity as real-streaming frameworks and consequently had a wide spectrum of usage within organizations and end-users [14], [START_REF] Michael | Open Source Stream Processing: Flink vs Spark vs Storm vs Kafka[END_REF]. Based on the popularity of usage, in this work, we have chosen both Flink and Storm along with the latest platform Heron [START_REF] Kulkarni | Twitter heron: Stream processing at scale[END_REF] for analysis.

Of late, some works specifically compared Flink and Storm. For example, Chintapalli et al. [START_REF] Chintapalli | Benchmarking streaming computation engines: Storm, flink and spark streaming[END_REF] developed a streaming benchmark for Storm, Flink and Spark and provided a performance comparison of the engines. However, the work mainly focused on the processing latency of the tuples but did not consider other parameters related to the performance. Lopez et al. [START_REF] Lopez | A performance comparison of open-source stream processing platforms[END_REF] also analyzed the architecture of Storm, Flink and Spark. The authors performed a study on the throughput and fault-tolerance of the platforms, however, the work did not study the scalability of operators of each platforms and how that hugely affects the throughput of the incoming streams. The work also did not analyze the rseource consumption of the platform in terms of CPU or memory. In 2016, the open-source version of Twitter Heron was released as an enhanced version of Storm. Kulkarni et al. [START_REF] Kulkarni | Twitter heron: Stream processing at scale[END_REF] proposed the new architecture of Heron and compared Storm and Heron in terms of throughput, end-to-end latency, and CPU utilization. However, analyses on the memory consumption, power consumption, and faulttolerance were absent. Also, considering the recentness of Heron, it is imperative to study and compare it thoroughly with the existing, widely-used streaming processing frameworks. Therefore, in this work, we compare Flink, Storm and Heron for a wide range of parameters starting from the scalability of the operators, to tuple statistics, and throughput, to resource utilization, energy-efficiency, and fault-tolerance.

Additionally, we also aim to provide insights on the usability of the frameworks for specific application requirements and examine their suitability across different physical computing infrastructure -which is one of the first attempts of its kind towards this direction. This will precisely enlighten IaaS cloudend users to wisely choose the correct streaming platform in order to run a particular application within a given set of VMs or assist the cloud-providers to rationally allocate VMs equipped with a particular stream processing framework to PaaS cloud-users for running a specific streaming application.

III. ANALYZED PLATFORMS

In this Section, we present a brief background and architecture of the chosen platforms under comparison.

A. Apache Flink

Apache Flink is a very popular stream processing framework that comprises of a data source, a set of transformations, Figure 1: Topology/DAG representation of the applications used and a data sink [START_REF] Carbone | Apache flink: Stream and batch processing in a single engine[END_REF]. The master-slave architecture of Flink comprises of a Job Manager (JM) that controls the job, schedules tasks, and coordinates with the slave nodes which are also called Task Managers (TMs). A TM comprises of TM slots each of which can run a pipeline of tasks. A TM can possess as many TM slots as the number of CPU cores of the machine. Thus, the parallelism of a Flink cluster can maximally be equal to the total number of TM slots of all the TMs.

In this work, we have set up a Flink 1.2.1 cluster and every physical node was configured to use 24 TM slots and the default parallelism was set to its maximum. The number of network buffers of each TM is set to the product of the square of the number of CPU cores and four times the number of TMs * and the heap memory of a TM is set to 10 GB. The Flink data sources are configured as Kafka 0.10.2 consumers and the Kafka producers are designed to generate data streams from synthetic sources or files mounted in Hadoop Distributed File System (HDFS), depending on the application.

B. Apache Storm

A Storm topology is a DAG in which the vertices comprise of spouts and bolts. Spouts are data sources that generate data streams and bolts are the intermediate and terminal vertices that perform specific computation as per the topology [START_REF] Toshniwal | Storm@twitter[END_REF]. The vertices of a topology are essentially run as tasks with threads called the executors which are, in turn, scheduled within multiple JVM processes called workers. In a clustered deployment of Storm, the master node called nimbus, performs jobs related to scheduling, monitoring, and management. The slave nodes are called supervisors and they execute tasks.

In our work, we have setup a Storm 0.10.2 cluster in which a single node serves as the nimbus with services of zookeeper 3.4.11 running below it. The other nodes are the Storm supervisors that execute worker processes. We have spawned multiple executor threads (30, 27, and 42 per worker * https://flink.apache.org/faq.html process for WC, AQM, and FDA, respectively) within worker processes and have set only one task per thread to reduce multi-level scheduling of tasks, threads, and processes.

C. Twitter Heron

A Heron topology is similar to a Storm topology as it also has spouts and bolts. However, the components inside nodes are different from Storm [START_REF] Kulkarni | Twitter heron: Stream processing at scale[END_REF]. In a clustered deployment of Heron, the master node, called the Topology Master, runs a container which contains processes that manage the entire topology and allow consistent data processing within slave nodes. The slave nodes of the cluster run several containers comprising of processes called Heron Instances (HIs) which are essentially the spouts and bolts of the topology. Heron is dependent on a scheduler to schedule these containers and a distributed file system where the topology package is to be uploaded for use by the cluster.

In our work, we have setup a Heron 0.14.5 cluster with a single Topology Master. The framework is configured with an Aurora scheduler 0.12.0 executing on top of Mesos with zookeeper services running below it. We configured HDFS 2.7.4 over the scheduler and setup Heron at the topmost layer. Every Heron container is configured to use 26 GB of RAM, 4 GB of disk, and 6 CPU cores.

IV. DATA SETS AND APPLICATIONS USED

In this section, we present the different data sets and applications that we have used for the purpose of experimentation.

A. Word Count Application (WC)

This is the conventional benchmark of streaming platforms for counting the frequency of words from a stream of sentences. Here, we have used a synthetic data set of infinite number of sentences with an arrival rate of 1000 words per second per source thread. The topology or the Directed Acyclic Graph (DAG) representation of WC comprises of three nodes, as shown in Figure 1, where the spout releases sentences followed by the next node that splits them into words and finally counting the frequency of the words.

B. Air Quality Monitoring Application (AQM)

The AQM application is for monitoring air quality based on selectively chosen criteria air pollutants suggested by the air quality standards and report of the United States Environmental Protection Agency (EPA) [18]. The criteria air pollutants are selected as carbon monoxide (CO), nitrogen dioxide (NO2), ozone (O3), and particulate matter (PM10). The acceptable threshold of these pollutants are set as per the meteorological measurements obtained from EPA. The DAG representation of the application is indicated in Figure 1. As the sensor data streams are generated, the individual pollutants are separated from the heterogeneous streams and are assessed with the overall air quality.

The application receives sensor based data of CO, NO2, O3, and PM10 and determines the level of hazard for both the individual parameters and the overall air quality. The sensor data is obtained from The Urban Observatory, a real deployment by the Newcastle University for obtaining longterm sensor feeds † . We have collected data for a span of 1 hour with a log rate at one per millisecond from environmental sensors measuring CO, NO2, O3, and PM10. The data is replicated to keep up the topology for 3 hours.

C. Flight Delay Analysis Application (FDA)

The FDA application deals with the raw data on airline on-time statistics and delay causes released by the U.S. Department of Transportation's (DOT) Bureau of Transportation Statistics (BTS). The data set comprises of data from 1987 to 2008 ‡ . However, in this work, we have used the data set of only year 2008 comprising of information for more than 7 million flights throughout the year.

The FDA application ranks all the 1492 flight carriers in terms of the yearly and daily delays incurred due to seven † http://uoweb1.ncl.ac.uk/explore/ ‡ http://stat-computing.org/dataexpo/2009/the-data.html different causes -arrival, departure, carrier delay, weather causes, National Aviation System (NAS) delay, security reasons, and late aircraft delay. The topology of the application is depicted in Figure 1. As the flight data streams are generated, the streams are filtered based on the different carriers and subsequently dealt with in two different pipelines. In the first, the carriers are ranked as per the different delays that have occurred and in the second pipeline, the carriers are ranked as per the different causes of daily delays.

V. PERFORMANCE EVALUATION

In this section, we describe the details of the experimentation and analyze the results obtained. We have performed the experiments in an 8-node cluster on Grid5000 [START_REF] Bolze | Grid5000: A large scale and highly reconfigurable experimental grid testbed[END_REF] and have configured every topology to stay alive for 3 hours. The details of the resources used are highlighted in Table I. The details of the methodology used for the collection of the metrics is described in the subsequent subsection.

A. Methodology

The definitions of operator parallelism, emitted tuples/records, and processed tuples/records are included in Definitions 1, 2, and 3, respectively. The metrics of operator parallelism and the tuple statistics are collected from the REpresentational State Transfer (REST) API of the respective frameworks as per the definitions through a json file which is subsequently parsed and plotted. The operator parallelism for spout/source is plotted as the summation of the parallelism of all the spouts/sources in the topology and the same is applied for bolt/intermediate operators. The tuple/record throughput is computed as the rate of processed tuples/records every minute and is also obtained from the REST API of the frameworks.

The measurements for the power consumption of the frameworks are provided by the Kwapi tool [20] of Grid5000 testbed. The power values obtained over time are converted Having described the experimental setup and the methodology, we now study the metrics individually and analyze their variation across the three different applications. § For analyses of the metrics for cluster, master, and slave perspectives, the same methodology as that of energy consumption is used.

B. Stream Processing

In this subsection, we focus on three different metrics of the stream processing frameworks -operator parallelism, tuple statistics, and tuple throughput. Definition 1. Operator parallelism is defined as the number of source/spout threads and the intermediate/bolt threads that can be scaled up within a given experimental setup and can be efficiently supported and maintained by the frameworks without incurring overheads due to thread/task scheduling, migration, garbage collection, and excessive memory consumption ¶ .

The comparative study of operator parallelism supported by the chosen frameworks is depicted in Figure 2. In every subfigure, we highlight the parallelism achieved by the spouts, ¶ For each framework, every application topology is separately tuned by taking into account the incurred overhead thereby allowing the parallelism of operators to be at its maximum.

the bolts, and in total. In this regard, we observe that, while both Storm and Heron have variable parallelism for spouts and bolts and the total reflects the summation of the parallelism of spouts and bolts, Flink has non-variant parallelism throughout. The primary reason is that, Flink supports as many TM slots as the number of CPU cores. Hence, for a masterslave configuration of a 8-node cluster for WC application, there is a total of 168 slots exhausting the 24 CPU cores of each of the 7 slave nodes. Each slot contains a thread that can schedule multiple tasks within it. Thus, for the entire runtime of an application comprising of a series of parallel and sequential Flink operations, there is always a maximum of 168 threads with several tasks corresponding to different operations scheduled. For both of the AQM and FDA application, Flink managed to support less than its capacity of threads, as shown in Figures 2(b) and 2(c). Unlike WC which is essentially a pipelining application allowing the flow of streams without significant processing, both AQM and FDA have significant data processing and analytics. Pulling up all the 168 threads create increased lag in processing the records thereby leading to backpressure. The difference in the parallelism of Flink operators in AQM and FDA is due to the variation of the arrival rate of the streams. AQM being a sensor-based application, the arrival rate of the sensor streams is non-uniform over time, and hence the parallelism is set keeping in mind the mean arrival rate of the sensor streams (1 record per sensor per 3 ms) which is low due to the periodic sleep cycle of sensors. On the contrary, being an application for statistical analysis, FDA receives large batches of flight data after a window time of 1 ms (100000 records per source per 10 ms).

Unlike Flink, there is no hardware-controlled upper-bound of the number of operator instances for both Storm and Heron and each framework can schedule as many as the topology can handle without backpressure. For both Storm and Heron, the number of bolts is always tuned equal to at least the number of spouts for efficient processing. Since WC has less data analytics, it is possible to afford a high spout parallelism owning to the subsequent flow of streams across the bolts with very less processing. However, increasing the number of spouts to more than 200 was observed to slow down Storm due to backpressure rising from a large number of tuples that could not be handled. Further, the bolts also cannot be hugely increased because the operators in Storm are essentially not threads but tasks that needed to be scheduled within threads within Storm worker processes. Hence, the multi-level scheduling controls the parallelism of operators as well in a framework. On the other hand, in Heron, operator parallelism is the number of HIs supported. As mentioned before, HIs being separate Java processes that work for an application, the overhead due to multi-level scheduling is absent. Thus, Heron supports larger parallelism of operators, which is however reduced in Figures 2(b) and (c) with the increase in the complexity of application level data processing in AQM and FDA. Both Storm and Heron exhibits larger parallelism of operators in FDA because of the same reason as that of Flink. Definition 2. The number of emitted tuples/records is the number of tuples/records emitted both by the spouts/sources and the bolts/intermediate operators.

Definition 3. The number of processed tuples/records is the sum of the tuples/records emitted from the spouts/sources and the bolts/intermediate operators and executed by the final operators.

The tuple/record statistics are extremely related to the operator parallelism but are not totally controlled by it. In Figure 3(a), for WC, we observe that Flink emits and processes more records than Storm, whereas, in AQM (Figure 3(b)), Flink emits less but processes more than Storm. This implies that although Storm emits more tuples, it fails to process them at the same rate and eventually, Flink outperforms Storm in FDA application (Figure 3(c)). Heron, on the other hand, has always outperformed Storm and Flink because of its alreadyhigh operator parallelism. In FDA, we can again observe that Flink emits more than Heron but ends up processing less records. Heron tends to handle emitted tuples at a rate slower than Flink, but eventually guarantees a greater magnitude of processed tuples. In case of stream processing, if tuples are emitted too fast than they can be handled, they start buffering up in input and processing queues and in most of the cases, when the queue is exhausted, the tuples are dropped.

We discuss about tuple throughput in Figure 4. Although, an indication of the throughput per minute directly follows from Figure 3, the throughput patterns in WC exhibit a stable nature compared to AQM and FDA, where we observe more fluctuations of the throughput over time. The primary reason here again is that WC simply involves flow of streams whereas, for the other two applications, the stream processing and analytics make the difference in the throughput. The variation of time spent differently towards fetching streams from the input queue and processing them for the output directly have an impact on the fluctuation of the throughput.

Lessons learnt: From the point of view of the stream throughput, clearly, Heron outstands both Flink and Storm for all the application types. Therefore, Heron is able to process and manage larger volume of streams for varied applications. However, as observed in Figure 4, especially for FDA application, Flink offers approximately 80% of Heron's throughput with an operator parallelism of almost 16% of that of Heron. Thus, the throughput per unit operator is considerably higher in Flink than Heron. Now, if each slave node of the cluster comprised of more than 24 TM slots, i.e., more than 24 CPU cores per node, Flink could have achieved the same throughput in a cluster of size less than 8. However, with this cluster setup, the scalability of the number of cores per slave node do not affect Heron's throughput as every Heron container is configured with 6 CPU cores and a maximum of 6 such containers were launched. In case of Heron, the RAM is of supreme importance and is the most significant resource for processing streams. Therefore, for an application that requires a high throughput but is supported by a small cluster with a high number of CPU cores, Flink (c) FDA Figure 6: Time series analysis of power consumption can be a better choice of a stream processing platform, than Heron. Storm, on the other hand, can be a good choice of framework for an application with a very low rate of stream emission and a low expectation of throughput. As Storm can be very easily deployed and launched across clusters, it can serve low-throughput applications really well at low costs of maintenance, which will be further discussed in subsection VF.

C. Energy Efficiency

In this subsection, we discuss about the energy consumption of the platforms. In Figure 5, the analyses have been separately provided for the cluster, the master node, and the slaves for all the applications and the values are provided by Kwapi tool [20] of Grid5000 testbed. Here, we can observe a general trend that the power consumption of the frameworks do not significantly vary across applications. From a cluster point of view, generally Storm consumes the maximum power in the cluster with the exception in AQM application (Figure 5(a)) in which the power consumption of Heron exceeds by approximately 7% to that of Storm. On the contrary, the power consumption of the master is the least in Storm, which directly implies that the nimbus offloads a significant amount of work to be done by the slaves. Flink is by par the most energyefficient framework among the three. For both the master and the slaves, Storm is generally observed to be the least energy efficient followed by Heron.

We performed an analysis of the time-variation of power consumption of the frameworks across all the applications, as highlighted in Figure 6. The methodology followed for obtaining the results is explained in subsection VA. In all the applications, we observe that the plot for the power consumption of the Storm master (the nimbus) has periodic peaks because the zookeeper in the nimbus periodically receives heartbeats from all the slaves to check if they are alive. Additionally, it periodically checkpoints the state of each of the slaves and the processes running within it for issues concerning fault-tolerance and recovery. On the other hand, both Flink and Heron also performs periodic checkpointing, but we observe them to be more frequent and hence the peaks are small. For Storm, the interval between successive checkpointing is more and hence the peaks are higher owing to the larger volume of information to be checkpointed. Generally, the power consumption of a slave is significantly different from that of the master for all the platforms across all applications.

An interesting observation here is the periodic occurrence of crests ad troughs for a Storm slave node, particularly for AQM and FDA application (Figures 6(b) and(c)). The crests reach around 210 Watt and each crest is of an average duration ranging from 3 to 15 minutes for AQM and FDA application, respectively. This is primarily because of periodic garbage collection cycles of Storm for computationally intensive applications. FDA being a statistical batch processing application with high rate of streams, the cycles are more frequent in FDA whereas, in AQM the cycles are asynchronous because the sensor data arrival rate is not very high. When a slave has a certain threshold of unwanted objects and processes, it schedules the operation for garbage collection.

Lessons learnt: Overall, Flink is the most energy-efficient stream processing framework, compared to Storm and Heron. Therefore, it is well-justified to be the appropri- ate framework for green computing IoT applications. Also, for computationally-intensive applications with data-intensive streams, the heavy power consumption can be significantly reduced by the usage of Flink.

D. CPU Utilization

We now focus on the CPU utilization of the frameworks, as shown in Figure 7. In case of Flink, the CPU utilization is the least because of the constraint on the upper-bound of the number of the TM slots to be equal to the CPU cores of the slave nodes. Therefore, a single thread corresponding to a TM slot is scheduled and there is no scope of time-sharing of CPU cores. Therefore, the CPU utilization of a core is totally controlled by the single thread that is executed within it. This affects the overall CPU utilization across the cluster (Figure 7(a)) and across all applications. In case of Storm, we can observe a gradual increase of CPU utilization of the cluster with WC being the least as it has less data analytics (Figure 7(a)) and topped by FDA with heavy batch processing workload. For Heron, we observe that WC has the least CPU utilization, but for both AQM and FDA, the CPU utilization of the cluster is not too high and also does not significantly vary with the increase in workload for FDA application. For all the applications, we observe that the CPU utilization of the master node for all the frameworks is almost negligible and not more than 2% (Figure 7(b)). The CPU utilization of the slaves (Figure 7(c)) is very low and consistent for Flink because of the afore-mentioned reason of the limitation in the number of TM slots. For Storm, the CPU utilization is really high because of the repeated garbage collection, which is also explained through Figure 6(c). Although Heron shows a gradual increase in CPU utilization, the difference in the increase is negligible. It is imperative to mention here that, one cannot anyhow scale up the operators or the workload to increase the CPU utilization because it would directly affect the memory consumption of the cluster as well, which we discuss subsequently.

Lessons learnt: For computationally-intensive applications, especially applications demanding statistical inferences, Flink is a rational choice as the CPU utilization is really low. For light-weight applications or IoT applications, both Flink and Storm perform well with CPU utilization not more than 10%.

E. Memory Utilization

We first focus on the amount of memory cached by these frameworks across the different applications. From the point of views of the cluster, master and slaves, it can be clearly observed that Heron caches memory much more than Storm and Flink. This is the primary reason why Heron does not suffer badly from backpressure. Of course, a wrongly-designed topology would anyway lead to backpressure even in Heron, but, it has better mechanisms to handle it. Generally, the incoming tuples that cannot be handled immediately are constantly buffered and pulled from the cache memory to prevent tuple loss and guarantee accuracy of information. Although, we can see that the memory cached in the master node does not heavily differ across the platforms, but the memory cached within the slave nodes differ widely thereby affecting the amount of memory cached across the cluster.

In WC application, the memory cached within a cluster (Figure 8(a)) for Storm and Flink do not vary significantly. However, it is still greater in Flink as earlier it was observed (Figure 3(a)) that Flink processed larger records of WC application compared to Storm. In AQM, although Storm emitted more tuples, but processed less due to backpressure which is also reflected by the reduced usage of cached memory by Storm, compared to Flink. This difference of memory cached is even higher for FDA application (Figure 8(a)) because Storm had significantly higher throughput of processed tuples, as shown in Figure 4(c). However, with the increase in the complexity of data processing across the three applications, we observe every framework to use larger amount of cached memory. The memory cached for the master and the slave node (Figures 8(b) and(c)) are very close for all the platforms, however, the value is larger for the slave node because of the execution of the core computing of the topology within slaves.

Having discussed about the cache memory utilization by the frameworks, we now focus on the overall memory used by these frameworks across different applications. We clearly observe again in Figure 9, that the memory consumption is the highest in Heron, compared to Flink and Storm. The main reason behind this is that, Heron is extremely resourcehungry compared to the other two platforms. Heron possesses a hierarchical architecture comprising of zookeeper at the bottom layer, followed by the resource manager, resource scheduler, distributed file system, and lastly, the stream processor. Consequently, it demands a very high threshold of the minimum resources required to launch any application thereby consuming more memory thank Flink and Storm. The memory consumption of Flink is higher than Storm because Flink contains an internal aggressive optimization mechanism for faster processing of records [START_REF] Fernandez | Comparing Hadoop, MapReduce, Spark, Flink, and Storm[END_REF].

For both WC and AQM applications, as indicated in Figure 9(c), respectively, we observe that the difference in the memory used by the slaves for all the platforms is not very high. However, the memory used in FDA application is highest for all the frameworks because FDA being an application for statistical analysis, it involves very frequent garbage collection. Thus, the memory consumption for FDA application increases.

Lessons learnt: The trends of the plots of both memory cached and overall memory used, in Figures 8 and9, indicate that Heron is a memory-hungry framework. The memory cached in Storm and Flink do not vary heavily, however, the results still indicate that Storm can be a wise choice of stream processing engine for clusters with low memory specifications. For non-batch processing applications, the memory consumption of Flink do not differ significantly and hence, in order to schedule a statistical application within a Flink cluster, it is important to check the memory offerings of the cluster. This also holds true for Heron, however, we observe that the memory consumption of the Topology Master is less than the average memory consumption of a slave node. Therefore, in a Heron-cluster comprising of nodes with heterogeneous resource capacity, the node with the minimum available memory may be selected as the Topology Master.

F. Fault Tolerance

As mentioned earlier in the methodology, the metric of fault-tolerance of a platform for a particular application is considered as the recovery time or the time interval after a slave node is killed till the time the respective responsibilities of the node are successfully delegated to another slave node. Definition 4. For a slave node which is running t TM slots in a Flink-cluster, or w worker processes in a Storm-cluster, or c containers in a Heron-cluster, the recovery time is respectively defined and computed as the interval of time after the node is shut down till the time a new set of t threads are scheduled in the newly created TM slots or w new worker processes are spawned and launched in some other slave node(s), or c new Heron containers are created and scheduled in some other slave node(s).

The recovery time of the platforms is studied across the applications by forcefully killing 1, 2, and 3 slave nodes at a time, as shown in Figure 10. First of all, it is important to mention that, Flink does not support a sudden or abrupt shutdown of a slave node (or a TM) during an application uptime. The application simply terminates after throwing an error mentioning the sudden death of a TM. Hence, the recovery time of Flink, in terms of the death of a slave node, is indicated along the -1 value along the negative y axis of Figure 10. Now, comparing the fault-tolerance of Storm and Heron, we observe that the time taken to restore the normal operations of the topology does not vary significantly across applications for both Storm and Heron. Overall, Storm is highly fault- Lessons learnt: Abrupt termination of a TM in Flink leads to termination of the topology as well. This suggests that Flink may not be a wise choice for applications demanding high resiliency. Clearly, Storm serves better than Heron in terms of recovering quickly from the event of sudden termination of a slave node. But, nimbus is one of the major limitations of Storm as it is considered to be the single point of failure [START_REF] Kulkarni | Twitter heron: Stream processing at scale[END_REF], which is resolved in Heron. However Heron, takes a higher latency to recover from node failures.

VI. CONCLUSION

In this work, we focus on a thorough comparative study and analyses Flink, Storm, and Heron. Earlier research works have compared streaming platforms from different perspectives, however, none of the works holistically covered all the parameters ranging from tuple statistics to resource consumption to fault-tolerance. This work focuses to present a wide range of comparative analyses for all the three stream processing platforms and investigates the energy-efficiency of the frameworks as well. The performance evaluation of this work includes a wide range of applications experimented on the platforms. Further, the work contributes by throwing insights to cloud end-users or providers about the choice of a framework for a given application within a specific physical infrastructure setting.

Figure 2 :Figure 3 :Figure 4 :

 234 Figure 2: Comparative analysis of parallelism of operators

Figure 5 :

 5 Figure 5: Comparative analysis of energy consumption

Figure 7 :

 7 Figure 7: Comparative analysis of CPU utilization

Figure 8 :Figure 9 :

 89 Figure 8: Comparative analysis of memory cached

Figure 10 :

 10 Figure 10: Comparative analysis of fault tolerance

Table I :

 I Setup of experimentation

	Parameters		Values
		Flink	Storm	Heron
	Image used	Debian Jessie-x64-base-2017030114	Debian Jessie-x64-base-2017030114	Debian Jessie-x64-base-2017030114
		2 CPUs Intel Xeon E5-	2 CPUs Intel Xeon E5-	2 CPUs Intel Xeon E5-
	Resources per node	2630, 6 cores/CPU, 32GB RAM, 557GB HDD,	2630, 6 cores/CPU, 32GB RAM, 557GB HDD,	2630, 6 cores/CPU, 32GB RAM, 557GB HDD,
		10Gbps ethernet	10Gbps ethernet	10Gbps ethernet
	Cluster size	8	8	8
	Cluster name	taurus	taurus	taurus
	Version	1.2.1	0.10.2	0.14.5
	Topology uptime	3 hours	3 hours	3 hours
	Operator parallelism Maximally allowed	Maximally allowed	Maximally allowed
	No. of workers /con-tainers	-	12	6


R Smith

Lepers

Ph. D C Hausswirth

J Brisswalter

J M Vallier

D Smith

R Lepers

Evolution of electromyographic signal, running economy, and perceived exertion during different prolonged exercises

Keywords: Triathlon, prolonged run, oxygen uptake, muscle fatigue, myoelectric power spectrum

Evolution of electromyographic signal, running economy, and perceived exertion during different prolonged exercises

Christophe Hausswirth, Jeanick Brisswalter, Jean-Marc Vallier, D.

Introduction

While the popularity of triathlon events has increased over the past five years, limited information is available concerning the physiological responses of the triathlete occurring during the run section that follows swimming and cycling sections [START_REF] Guézennec | Increase in energy cost of running at the end of a triathlon[END_REF][START_REF] Hausswirth | Variability in energy cost of running at the end of a triathlon and a marathon[END_REF][START_REF] Kreider | Effects of cycling on running performance in triathletes[END_REF]. Typically during a triathlon, involving consecutive trials in swimming, cycling, and running, the musculature of the upper and lower body is utilized for the three different events. In regard to the influence of cycling on the running performance, the first data recorded by Boone and Kreider [41 have demonstrated that the energy cost of running (Ec) was higher when it was carried out after a warm-up on the ergocycle than when it was performed after a warm-up on the treadmill. In addition to this result Kreider et al. [START_REF] Kreider | Effects of cycling on running performance in triathletes[END_REF] showed that at the end of a simulated triathlon conducted in a laboratory both oxygen uptake and heart rate values were greater during a 10 km triathlon run than during a control run. More recently this result was confirmed by Guézennec et al. [141 during an overground simulated triathlon: these authors have shown a decrease of running efficiency during the run section of the triathlon compared with an isolated run performed at the same pace.

Analysis of surface electromyographic (SEMG) activity has been used increasingly in order to study muscle fatigue [START_REF] Luca | Myoelectrical manifestations of localized muscular fatigue in humans[END_REF]. It has been found that an increase in EMG amplitude with time has been associated with prolonged submaximal muscle contractions [START_REF] Arendt-Nielsen | Muscle fibre conduction velocity, mean power frequency, mean EMG voltage and force during submaximal fatiguing contractions of human quadriceps[END_REF]. Although the mechanisms of these alterations are debatable, changes in the myoelectric signais have been shown to provide information relating to events which occur inside the muscle [START_REF] Luca | Myoelectrical manifestations of localized muscular fatigue in humans[END_REF]. Relationships have been found recently between running economy and temporal EMG characteristics of leg muscles [START_REF] Heise | Relationships between running economy and temporal EMG characteristics of bi-articular leg muscles[END_REF], however no data is available concerning running economy and the modifications of integrated EMG records obtained at the end of prolonged exercise of running.

While several studies have reported an increase in the energy cost of running at the end of a triathlon compared to a control run performed at the same speed [START_REF] Guézennec | Increase in energy cost of running at the end of a triathlon[END_REF][START_REF] Hausswirth | Variability in energy cost of running at the end of a triathlon and a marathon[END_REF], few studies have attempted to compare the evolution of the Ec obtained during the triathlon run and the Ec recorded at the end of a marathon run performed at the same velocity [START_REF] Hausswirth | Variability in energy cost of running at the end of a triathlon and a marathon[END_REF][START_REF] Hausswirth | Relationships between energy cost of running and running mechanics occurring at the end of a triathlon and a marathon[END_REF]. The foregoing studies confirmed the decrease in running efficiency previously shown during the run section of a triathlon and demonstrated that this decrease was less than that observed during the final phase of a marathon. However, the relationships between EMG signal and the appearance of muscle fatigue due to different types of prolonged exercise have not been yet documented.

The aims of the present study were therefore to:

1. verify the decrease in running economy previously observed during both a triathlon and a prolonged run, 2. compare the evolution of the integrated electromyographic flow obtained during a run section of a triathlon and at the end of a prolonged run performed at the same running speed, 3. to determine EMG changes recorded during isometric contractions at the end of each prolonged exercise (triathlon, prolonged run) and correlate these changes with the fatigue level.

Methods

Subjects

The subjects who participated in this study were seven well-motivated male triathletes. They were comprehensively informed of the requirements and procedures of the experiment. The subjects were selected on the basis of their performance time over the 'Olympic' distance triathlon (range 1 h 57 -2 h 27). A briefing session was conducted in order to familiarize subjects with the cycling circuit and treadmill which were to be used during the investigation. The subjects completed a light training program during the recovery period of each testing session. During the entire experimental procedure the subjects were to not perform any exhausting exercise in the 48 hours preceding each test. The anthropometric data and physiological characteristics of the subjects are reported in Table 1. These data are similar to those reported in previous studies [START_REF] Kreider | Effects of cycling on running performance in triathletes[END_REF][START_REF] O'toole | The ultraendurance triathlete: a physiological profile[END_REF].

Maximal oxygen uptake (VO 2 max) and oxygen uptake measurements 1) Subjects initially performed a running VO 2 max test on a motorized treadmill fixed at 0% gradient (2500 ST, GYMROL, Andrezieux-Boutheon, France). The test began with a warm-up at 12 km x h -1 for 9 min, and the running speed was then increased by 1 km x h -1 every 2 min until volitional exhaustion. Oxygen uptake was recorded continuously with a metabolic cart measurement (type CPX, Medical Graphics, Saint-Paul, Minnesota, USA). The criteria used for the determination of VO 2 max were: a plateau in VO 2 despite an increase in running speed, a Respiratory Exchange Ratio (RER) above 1.1, and a heart rate (HR) over 90% of the predicted maximal HR [START_REF] Astrand | A nomogram for calculation of aerobic capacity (physical fitness) from pulse rate during submaximal work[END_REF]. The Maximal Aerobic Speed (MAS) was the highest speed completed for 2 minutes.

2) Oxygen uptake (V0 2 ) was recorded using the CPX analyser. VO 2 values collected during the treadmill sessions were recorded as previously reported [START_REF] Hausswirth | Variability in energy cost of running at the end of a triathlon and a marathon[END_REF], i.e. during the second to fifth minute of running (2 -5, period 1), during the fifteenth to twenty-second min (15 -22, period 2), and the thirtyfifth to fourty-second min (35 -42, period 3) in order to give the runners a maximum of respiratory comfort and let them drink during the treadmill run (Fig. 1). The calculation of the energy cost of running (Ec) is usually performed using the formula given by Di Prampero [START_REF] Prampero | The energy cost of human locomotion on land and in water[END_REF]:

The 0.083 (in ml x kg -1 x s -1 ) is VO 2 value corresponding to the y-intercept of the V0 2 -speed relationship established in young male adults [START_REF] Jl | Anaerobic capacity determined by maximal accumulated 0 2 deficit[END_REF].

Head rate was monitored using a cardiofrequency meter (BHL-6000, Bauman-Haldi SA, Fleurier, Switzerland).

Protocol and experimental procedures

The experimental trials (the first, second, and third testing sessions) were randomized for each subject in order to avoid problems due to a Jack of motivation or motor skills learning. Moreover, to secure a complete recovery, the delay between each test was about one week for each triathlete. The protocol is presented in Fig. 1: it was the same previously applied by Hausswirth et al. [START_REF] Hausswirth | Relationships between energy cost of running and running mechanics occurring at the end of a triathlon and a marathon[END_REF]. Each triathlete carried out the proposed trials as if it was a real competition in spite of the absence of a direct competitor. All triathletes performed an isolated run (IR) test of 45 minutes at 75 % of the Maximal Aerobic Speed (MAS) recorded during the VO 2 max test. The second testing session was the simulation of a triathlon of 2 h 5 min duration. It consisted of 30 min swimming, 60 min cycling on a flat traffic-free road, and 45 min treadmill running (0% gradient) at 75 % of MAS. For the cycling trial the triathletes had to maintain the pedalling frequency obtained after 10 min of cycling (± 2 rpm) and were allowed to change gear when they liked. The two transition times between the 3 events of the triathlon were slightly greater compared to those usually recorded in competition. The change over time between swimming-cycling was about 3 min and 2 min for the cycling-running transition, including the time needed to place the three EMG electrodes and change shoes. The third testing session was termed 'Prolonged run' consisting of the achievement of a 2 h 15 min exercise bout of running. The subjects ran first for 1 h 30 min on a flat track: they had to run at 80 -85% of their maximum heart rate value during this period. The outdoor-laboratory transition was about 2 min, including the time needed to place the three EMG electrodes. During the last 45 min of the Prolonged Run (PR) performed on the treadmill (0% gradient), speed was identical to that performed during the Triathlon Run (TR) and the Isolated Run (IR). A photocell arrangement was mounted at the far end of the treadmill. Thus the time between photocell pulses was combined with measured treadmill belt length assuming the adjustment of the instantaneous running speed.

Outside air temperatures ranged from 18 to 27 °C while the laboratory temperature ranged between 23 -25 °C. The weather conditions were similar (no wind) during both triathlon and marathon. During all run sections on the treadmill two fans were placed in front of the runners. Each triathlete ingested one liter of water at their disgression during each testing session. The mean swimming distance was 1580 ± 407 m (3.1 km x h -1 ), cycling distance 36.2 ± 2.2 km (36.2 km x h -1 ), and running distance 10.8 ± 1.5 km (13.8 km x h -1 ).

Muscle tests

Isometric contractions

Right isometric knee extensions were performed using an isometric ergometer (type: J. Schnell, Selephon, Germany). Before each testing session the subjects were asked to perform maximal isometric contraction of short duration (2 -3 sec) of the knee extensors muscles. The maximal force at a knee angle of 80° was measured, and the best performance after four trials was selected as maximal voluntary contraction at 80 ° (MVC 80 ). Approximately 2 -3 min separated each of the four trials. After a 10 min warm-up on the treadmill at 60% of their MAS, subjects maintained an isometric contraction of the knee extensor muscles at 35% MVC 80 for 4 sec. The required force of contraction was displayed by an oscilloscope placed in front of the subject. We have taken into consideration only the 3 last sec of the contraction for the analysis of EMG data; the first second was considered as the time to reach the reference line of 35 % MVC 80 showed on the oscilloscope and was therefore not analyzed. The mean value of the 3 sec analyzed was called non-fatigued (NFO) value. Also recorded was a 4 sec isometric contraction during the treadmill run of each event (Triathlon Run, TR; Prolonged Run, MR; Isolated Run, IR); the isometric ergometer was placed next to the treadmill. The times of measurement were precisely at the fifth min (TR1, PR1 and IR1 ), the 22 min (TR2, PR2, and 1R2), and the 45 min (TR3, PR3, and IR3) of running.

During all isometric contractions subjects were in a sitting position, securely strapped into the muscletest chair. The seated posture met the following specifications: hip angle 10 °, knee angle 80°. Before and after each trial subjects had to indicate the perceived exertion value according to the Borg's scale DP 20 [START_REF] Borg | Perceived exertion as an indicator of somatic stress[END_REF]; all values were recorded immediately after the 4 sec of knee extension.

Dynamic contractions

During the treadmill run the EMG activity was recorded during the second to fifth min of running (2 -5), during the seventeenth to twentieth min (17 -20), and the thirty-ninth to forty-second min (39 -42).

During both isometric (i.e. knee extension) and dynamic contractions (i.e. treadmill run) the EMG activity of the vastus lateralis muscle was recorded by means of bipolar, silver/silver chloride, surface electrodes (interelectrode distance = 20 mm; area of electrode 50 mm 2 ) positioned over the belly of the muscle contracted. The skin was prepared by surface abrasion, cleaned with 33 % ether, 33 % aceton, 33 % alcohol. The impedance was checked, and only values below 5 kΏ were accepted. The two electrodes were fixed lengthwise over the motor point (approximately 20 cm above the knee). To be sure that electrodes were precisely at the same place for each testing session, we marked the electrode location on the skin with an indelible marker. The electrodes were secured with surgical tape and cloth wrap, and electrode wires were also secured to an elastic belt worn by subjects to minimize disruption during the movement. The electrode housing contained a solid state preamplifier (signal amplified 35 times), and the preamplified signal was subsequently amplified (gain setting of 10 which includes preamplification). After amplification (x 600) the signal was recorded on a SONY tape recorder type KMT (SONY Corporation, GmbH Kraus-Messtechnik, Otterfing, Germany, banwidth from 6 to 1500 Hz) and stored on a digital audio tape. The sampling rate was 12 kHz per channel with 12 bit data resolution. Off-line EMG recorded samples were digitized using a 1 kHz sampling rate and stored on a computer disk: the EMG was then processed.

EMG analysis

For the isometric contractions the power spectrum density function of each recording was calculated by fast Fourier transformation. The analyser computed a mean spectrum by calculating the root mean square (RMS) values obtained from consecutive time windows of 0.5 s duration. The resulting spectrum was defined by 512 points in amplitude and phase. The final result of this signal analysis was a number of EMG variables including RMS and the frequency of the mean power frequency (MPF). lt was calculated according to the equation given by Kwatny et al. [START_REF] Kwatny | An application of signal processing techniques to the study of myoelectric signais[END_REF]. A comparison was done systematically between the isometric EMG data recorded before and during each running test (3 periods of time). For the dynamic contractions integrated EMG values (iEMG) were calculated during the final 2 min of each 3 min recording segment (Dynaview 1.0, G. Dietrich, Paris, 1995). In order to analyze a same session during the three runs, 10 consecutive running bursts during the foot contact phase were integrated at 1 min and 2 min (period 1), 19 min and 20 min (period 2), 41 min and 42 min (period 3). We normalized all iEMG values expressed with regard to the burst duration (iEMG/burst duration) obtained in a non-fatigue state: these values were considered as the measurement of muscle activity. These values were named 'iEMG flow, QiEMG'.

Statistical analysis

The global statistical analysis of all studied parameters in relation to the various moments and types of exercise identified (Triathlon Run [TR], Marathon Run [PR], Isolated Run [IR]) was performed by means of a two-way analysis of variance, ANOVA (2 x 3). The comparison of variables between the experimental conditions was conducted with Student's t-test for paired samples. All values are expressed as mean standard deviation (SD). For all statistical tests the level of significance was set at P < 0.05.

Results

Oxygen uptake and energy cost of running

The variance analysis demonstrated a global effect of the exercise (P < 0.05) on V0 2 values. In comparison with the TR and IR the PR showed a greater VO 2 throughout the trial. For Ti (2 -5), T2 (15 -22), and T3 (35 -42) the VO 2 values obtained during the triathlon were higher than those measured during IR (P < 0.05). The initial values for TR1, PR1, and IR1 were 50.6 ml x min -1 x kg -1 , 52.2 ml x min -1 x kg -1 , and 46.3 ml x min -1 x kg -1 , respectively. At the beginning of the running trial, VO 2 was higher during PR than during both TR and IR (+ 3 %, P < 0.05 and + 11 %, P < 0.01, respectively). At the end of the running trial VO 2 was higher during PR than during both TR and IR (+ 3 %, P < 0.05 and + 10 %, P < 0.01, respectively). Table 2 shows the changes in the energy cost of running (Ec) in relation to the 45 min running under PR, TR, and IR conditions. TR and PR led to a greater Ec throughout the running test in comparison with IR values (P < 0.01). Also Ec at each analysis time was higher during PR than during TR (P < 0.05). We did not find any statistical difference change in Ec along each tested run.

Head -rate values

As indicated in Table 2, the mean heart rate (HR) for PR1, PR2, and PR3 was significantly greater (P < 0.05) than for TR1, TR2, and TR3, respectively. Also HR values recorded during both PR and TR were higher than those recorded during IR (P < 0.01). The mean heart rate obtained during PR was significantly greater than that recorded during TR (+ 4%, P < 0.05) and IR (+ 13 %, P < 0.01). Mean HR recorded during TR was significantly greater than IR value (+ 10%, P < 0.01).

Analysis of EMG

Dynamic contractions

Fig. 2 shows the variations of the integrated EMG signal expressed with regard to burst duration (IEMG flow) during 2 min of running (triathlon run TR, prolonged PR and isolated run IR). Mean values (7 subjects) recorded during PR2 (18-20') and PR3 (40-42') were significantly greater compared with the mean PR1 value (P < 0.05 and P < 0.01, respectively).

Isometric contractions

As indicated in Fig. 3 a, signal amplitude (RMS) was significantly greater during all the PR (P < 0.01) in comparison with the reference value. Moreover, RMS values obtained during TR were significantly greater (P < 0.05) than the reference value recorded before the trial. Results of MPF values for PR indicated a significant decrease for PR1, PR2, and PR3 (P < 0.05, P < 0.05, and P < 0.01, respectively) compared with the reference value recorded before the start of the trial (Fig. 3b). Moreover, results of MPF values for TR indicate a significant decrease compared with the initial value (P < 0.05) while MPF values recorded in IR1 show a significant increase (P < 0.05) compared with the initial value. Fig. 4 represents the alterations of the power spectrum of the EMG signal recorded on the vastus lateralis muscle for one triathlete. This triathlete was representative of the population tested during an isometric contraction of 4 sec knee extension. Spectrums shown in this figure indicate the different frequencies obtained before and after the prolonged run which induced the most significant difference as shown in Fig. 3b.

Rating of perceived exertion

All ratings of perceived exertion values (RPE) are reported in Table 3. RPE values for TR obtained during the last isometric contraction, immediately after TR3, were significantly higher in comparison with IR values and the initial value obtained before the triathlon trial (P < 0.01). RPE values after TR3 were significantly lower versus RPE values obtained after MR3 (P < 0.05). Also RPE values after PR3 were significantly higher compared to RPE values after 1R3 and the initial RPE values recorded before the prolonged run (P < 0.01). RPE values after 1R3 were significantly higher than RPE values obtained before the trial.

Discussion

The first observation of the present study was the increase in the integrated electromyographic flow (QiEMG) over the course of a prolonged run (PR) lasting 2 h 15 min. In addition the results confirm that both a 2 h 15 min PR and triathlon event (TR) result in a significant increase in the energy cost of running (Ec) during the final phase of each event compared to an isolated run (IR: 26 m10 2 x min -1 x km -1 , P < 0.01 and 7 m10 2 x min -1 x km -1 , P < 0.05, respectively; see Table 2). Moreover, there was also a higher Cr during the run portion of an "Olympic Triathlon" compared with an isolated run (P< 0.05). It is noteworthy that the energy cost of the TR, PR, and IR remained constant throughout each trial (Table 2), and these values are in close agreement with those obtained in studies involving prolonged running [START_REF] Sproule | Running economy deteriorates following 60 min of exercise at 80% VO 2 max[END_REF][START_REF] Xu | Effect of prolonged exercise at 65 and 80% VO 2 max on running economy[END_REF] or an overground triathlon [START_REF] Guézennec | Increase in energy cost of running at the end of a triathlon[END_REF][START_REF] Hausswirth | Variability in energy cost of running at the end of a triathlon and a marathon[END_REF]. Consequently both single-and threediscipline prolonged endurance exercise result in a decreased running economy compared to an isolated run at the same speed. The results of our experiment confirm also the decrease in running economy that occurred during a prolonged run (i.e. 2 h 15 min) in comparison with an isolated run (i.e. 45 min) for a similar running speed.

However, one interesting finding of this experiment is that the magnitude of changes in EMG variables under non-fatiguing (IR) and fatiguing trials (PR, TR) tended to be different. Williams et al. [START_REF] Williams | Biomechanics in distance running[END_REF] suggested that runners did not clearly modify their running mechanics with fatigue but instead hypothesized that modifications of the patterns of motor unit recruitment could be at the beginning of a fatigue state during running. For all subjects in our study a number of EMG variables were significantly altered by the prolonged exercise.

The QiEMG of the vastus lateralis (VL) muscle was significantly higher after the 1 h 50 min (PR2 ) and 2 h 10 min (PR3) portions of the prolonged run than at the 1 h 30 min mark (PR1, P < 0.05; Fig. 2 and P < 0.01, Fig. 2, respectively). There was no observed change in QiEMG during the length of the TR or IR. Interestingly the shift in QiEMG during the latter stages of the PR was not associated with a significant increase in the energy cost of running. Accordingly the triathletes who were not as well trained as the specialist runner experienced greater changes in their neuromuscular coordination at the end of endurance running exercise in comparison with the specialist runner. This neuromuscular alteration has been recently shown for a triathlete population after an Olympic triathlon and a marathon [START_REF] Lepers | Altérations des performances neuromusculaires après un exercice physique prolongé: analyse comparée du triathlon et du marathon[END_REF]. This study emphasized that the rise of the center of gravity of the counter-movement-jump (CMJ) was significantly lower after the marathon (-12 cm) than after the triathlon (-2.5 cm). Kinetic analysis of the CMJ showed changes during the flexion phase where the quadriceps act in part eccentrically. More eccentric contractions and mechanical constraints during the marathon (or prolonged run) may explain both the greater alteration to jump performance after the marathon [START_REF] Lepers | Altérations des performances neuromusculaires après un exercice physique prolongé: analyse comparée du triathlon et du marathon[END_REF] and the elevated QiEMG values obtained on the VL in the prolonged run of the present study. Some common factors may be expected to support this specific type of exercise. In addition structural damage has been observed after a marathon [START_REF] Gunderson | Membrane permeability changes as a fatigue factor in marathon runners[END_REF][START_REF] Wahrol | Skeletal muscle in-jury and repair in marathon runners after competition[END_REF] and in exercices in which eccentric actions dominate [10], suggesting an impairment of the muscle fibre function. A muscular functioning failure may be expected after a 2 h 15 min run; an increased activation of the motor units (MU) of the VL may further be speculated to result from an increased reliance on the fast-twitch muscle fibres at the end of the run and/or an increase of MU discharge since the start of the prolonged run. The integrated EMG increase and the MPF of the power spectrum density function decrease were previously demonstrated for brachioradialis muscle and biceps brachii activity [START_REF] Gamet | The fatigability of two muscles in human isometric voluntary submaximal contraction: an EMG study. Assessment of muscular fatigue by means of surface EMG[END_REF]. The results of this study suggested that in the present study a specific role of compensatory activation of other vastus lateralis agonist muscle such as the rectus femoris muscle could be observed. Moreover, the repetitive stretching loads of a prolonged run induce ultra-structural damage which might be associated with an hyperpermeability of the muscular cell [START_REF] Magazanik | Enzyme blood levels and water balance during a marathon race[END_REF] and with reduced ability of the muscular tissue to contract [START_REF] Gunderson | Membrane permeability changes as a fatigue factor in marathon runners[END_REF]. In this framework the more elevated QiEMG recorded at the end of PR vs. TR could be partly representative of the contractile properties modifications. This is partly due to the repeated eccentric loading demonstrated to result in an increased level of neural activation of the muscle at a given low level tension [19].

Analysis of surface EMG activity has been used increasingly to study muscle fatigue [START_REF] Luca | Myoelectrical manifestations of localized muscular fatigue in humans[END_REF]. It has been found that during a fatiguing submaximal contraction the power spectrum of the surface EMG (MPF) shows a linear shift to lower frequencies [START_REF] Arendt-Nielsen | Muscle fibre conduction velocity, mean power frequency, mean EMG voltage and force during submaximal fatiguing contractions of human quadriceps[END_REF]. Moreover, an increase in EMG amplitude (RMS) with time has been associated with prolonged submaximal muscle contraction [1]. To provide systematic information of muscle activation, a standard isometric contraction of knee extensors muscles (i.e. VL) was performed on three different occasions (start, middle, end of testing sessions) during PR, TR, and IR. These standard isometric tests were carried out at 35% of maximal voluntary contraction (MVC), supposing this level of contraction to be high enough to be sensitive to prior run exertion and low enough to be sustained for 4 sec without generating an extra fatigue level and not occluding muscle blood flow. It was then assumed that all recorded EMG data at this force level during a static contraction could be an indicator of the fatigue state generated by the various dynamic exercises of this study (triathlon, prolonged run, isolated run). The increase of QiEMG during the final phase of PR (dynamic contraction) is associated with a significant elevated value of EMG amplitude (isometric contraction, Fig. 3a) and a significant shift of MPF towards lower frequencies (isometric contraction, Fig. 3b) in comparison with the reference value (e.g. in Fig. 4). It is well documented that the power density spectrum of an EMG signal is compressed toward lower frequencies as a sustained contraction progresses [START_REF] Kadefors | Dynamic spectrum analysis of myo-potentials with special reference to muscle fatigue[END_REF]26].

According to the present study the shift of MPF towards lower frequencies and the increase in EMG amplitude were more marked during PR than TR. Although we have not proposed a time-limit for a submaximal static contraction as in many studies [START_REF] Luca | Myoelectrical manifestations of localized muscular fatigue in humans[END_REF][START_REF] Kadefors | Dynamic spectrum analysis of myo-potentials with special reference to muscle fatigue[END_REF]26], we suggest that isometric EMG data may indirectly reflect the variation in the muscle generated during all dynamic exercises. The isometric test therefore reveals some additional complementary information regarding the neuromuscular state during the final phase of the different runs. Nicol et al. [START_REF] Nicol | Fatigue effects of marathon running on neuromuscular performance: changes in force, integrated electromyographic activity and endurance capacity[END_REF] have previously shown that pre-marathon iEMG activity values were elevated by 34% following the competitive marathon run. In accordance with this we have found respective increases in EMG amplitude across the PR and TR of 22 and 12% (Fig. 3 a). These results were linked to the mean value obtained on the scale of perceived effort [START_REF] Borg | Perceived exertion as an indicator of somatic stress[END_REF] (Table 3): 14.6 and 11.2 points for post-prolonged run and post-triathlon, respectively. Both the increase in EMG amplitude and decrease in MPF values during PR were associated with the most elevated rating of perceived exertion (RPE) as has been confirmed in an earlier study using a subjective approach to a fatigue state [START_REF] Setruk | Perception subjective de la fatigue musculaire: utilisation de l'échelle de Borg[END_REF]. Although we assumed that the additional EMG testing of an isometric contraction (of short duration and at 35% MVC) during the runs was not enough to increase muscle fatigue level significantly, we hypothesized that only the cellular alterations which appear at the end of PR and TR might have influenced the present increase of RPE obtained in post-marathon and post-triathlon.

In conclusion, the results of the present investigation confirm the increase of the energy cost of running during the final phase of a prolonged run and a treadmill based triathlon run. One particularly important feature was that a 2 h 15 min prolonged run induced greater neuromuscular alterations, identified by an increase in the integrated EMG flow of the vastus lateralis muscle, than a triathlon lasting the same amount of time but combining 3 disciplines (viz. swimming, cycling, and running). Thus, by combining three different activities into a continuous event, the triathlon appears to induce less muscle alteration as illustrated by the stability in iEMG flow recorded during the run portion. The observed change in running economy could not be related to an isolated EMG factor such as the muscle activation of the vastus lateralis. In addition it is suggested that the rating of perceived exertion recorded during isometric contractions is a good indice to approach the level of fatigue during different modalities of prolonged exercices.

  different from IR group, a (P < 0.05), b (P< 0.01). Significantly different from PR group, c (P< 0.05), d (P < 0.01). TR1: start of triathlon run (2-5 min, period 1); TR2: middle of triathlon run (15-22 min, period 2); TR3: end of triathlon run (35-42 min, period 3) PR1: start of prolonged run (2-5 min, period 1); PR2: middle of prolonged run (15-22 min, period 2); PR3: end of prolonged run (35-42 min, period 3) IR1: start of isolated run (2-5 min, period 1); IR2: middle of isolated run (15-22 min, period 2); IR3: end of isolated run(35-42 min, period 3)

Fig. 1

 1 Fig. 1 Experimental protocol.

Fig. 2

 2 Fig.2 Changes in integrated EMG signal expressed with regard to burst duration (QiEMG flow) during 2 min of running (triathlon run, prolonged run and isolated run).

Fig. 3a

 3a Fig.3aChanges in signal amplitude (RMS) obtained for 3 seconds of isometric contraction of knee extension; all values are means (± SD) and recorded during the triathlon run, the prolonged run, and the isolated run. For each trial values were compared with the reference value (i.e. before exercise, 100%).

Fig. 3b

 3b Fig.3bChanges in mean power frequency (MPF) obtained for 3 seconds of isometric contraction of knee extension; all values are means (± SD) and recorded during the triathlon run, the prolonged run, and the isolated run. For each trial values were compared with the reference value (i.e. before exercise, 100%).

Fig. 4

 4 Fig. 4 Modifications of the power spectrum of the EMG signal recorded for the population tested (mean values, 7 subjects) during an isometric contraction of 3 sec of knee extension. Spectra shown on the above represent the different frequencies obtained before (left) and alter the prolonged run (right).

Table 1

 1 Physical and physiological characteristics of the subjects. Values are means ± SD. VO 2 max, maximal oxygen uptake; MAS, maximal aerobic speed

	Age (yrs)	Body mass (kg)	Height (cm)	VO2max (ml x min -1 x kg -1 )	MAS (km x h -1 )	Average training distance per
						week (km)
	31±5	72.2±2.4	175.1 ± 3.1	66.8±5	18.4±1.5	6.2 swim
						155 bike
						65 run

Table 2

 2 Changes in the energy colt of running (Cr) and heart rate (HR) obtained during the Triathlon Run (TR), the Marathon Run (PR), and the Isolated Run (IR) (i.e. 45 min of the final run for each testing session). Values are means (± SD)

		Triathlon run		Prolonged run		Isolated run		ANOVA
		TR1	TR2	TR3	PR1	PR2	PR3	IR1	IR2	IR3	Exercise
											Time
	Energy Cost of	219.6± 12.6 b, c	220.1± 14.6 b, c	220.9± 16.7 b	226.6± 17.3 b	227.4± 18.2 b	228.3± 14.6 b	200.9± 11.5	204.8± 13.5	204.4± 15.3	P < 0.05 NS
	running,
	Ec (ml x min -1 x kg -1 )
	Heart rate,	163± 16.5 b, c	168+ 17.6 b, c
	HR
	(beats x min -1 )

Table 3

 3 Changes in effort perceived values obtained after isometric contraction for knee extension sustained during 4 sec at 35% MVC 80 . Values were recorded before and after each trial according to the Borg's scale DP20[START_REF] Borg | Perceived exertion as an indicator of somatic stress[END_REF] Significantly different from IR group, *(P <0.05, ** (P <0.01). Significantly different from PR group, $ (P< 0.05), $$ (P< 0.01). Significantly different from reference values (before), £ (P< 0.01).

	Groups	Effort perceived Before	Effort perceived After
	Triathlon run (TR)	Mean 6.2	SD ±0.2	Mean 11.2 **,$,£	SD ±1.1
	Prolonged run (PR)	6.5	±0.1	14.6 **,£	±1.4
	Isolated run (IR)	6.4	±0.2	7.1 $$,£	±0.9
	ANOVA
	Exercise	NS		P<0.05
	Time			NS
	Interaction			P<0.05

Acknowledgements

The authors gratefully acknowledge Matt Spencer (Western Australia Institut of Sport) and Darren Smith (Sport Scientist, Queensland Triathlon) for their active support during the corrections of this manuscript.