Main Page

From BiCEP

Jump to: navigation, search
(What's New)
 
Line 1: Line 1:
-
<big>'''Project BiCEP'''</big>
+
== Description ==
 +
BiCEP, a project from the Systems and Software Engineering Group at the University of Coimbra, has the goal to study and improve performance and produce benchmarks for [http://www.complexevents.com:Complex Event Processing] systems (CEP). The project, partially funded by an [http://cordis.europa.eu/mariecurie-actions/irg/home.html FP6 Marie Curie International Reintegration Grant], started in September 2007. Since then, we have developed benchmarking tools, carried out a number of performance evaluations on real CEP engines, and studied several use-cases of the technology. Currently, we are working towards the definition of novel application benchmarks that allow assessing the overall performance and scalability of event processing platforms.
-
BiCEP is a project started in the Systems and Software Engineering Group at the University of Coimbra. The goal of the project is to produce benchmarks for [http://www.complexevents.com:Complex Event Processing] systems (CEP).
+
The ''BiCEP benchmark suite'' shall comprise a number of smaller, domain-specific benchmarks, each with its own workload, dataset and metrics. Our goal is that each benchmark will allow evaluating one or more aspects of event processing systems (e.g. latency, scalability with respect to number of queries and rules, storage efficiency, etc.).
-
----
+
<!--
 +
In the papers below we present benchmarking experiments that evaluate engines CEP along several metrics. Some of these are obvious, others not quite: throughput, maximum latency, latency degradation ratio, post-peak latency variation ratio, memory consumption, instruction count, clocks-per-instruction, cache miss rates and more. We studied many different basic and not so basic operations such as selection, projections, aggregations, joins, windows, and patterns detection and the impact of types and sizes of windows, query sharing, variations to peaks, the effects of garbage collection options, and internal data structures and tuple representations.
-
<big>'''New stuff'''</big><BR>
+
To perform all this, we built FINCoS, a testing framework (available below) that lets users generate and/or load test data, start and play benchmarking experiments, visualize and capture metrics, and run multiple engines at the same time.
-
[http://debs09.isis.vanderbilt.edu/tutorials1.php Tutorial accepted at DEBS'2009]
+
-
----
 
-
The goal of project BiCEP is to study the performance and develop benchmarks for Complex Event Processing systems. CEP metrics should include the following metrics (some obvious, others not quite):
 
* '''Sustainable throughput''': the steady-state number of events per unit of time that a (warmed-up) CEP engine can process while performing query processing. Even within the same system, sustainable throughput can vary widely depending on the amount of work to be done during query processing.
* '''Sustainable throughput''': the steady-state number of events per unit of time that a (warmed-up) CEP engine can process while performing query processing. Even within the same system, sustainable throughput can vary widely depending on the amount of work to be done during query processing.
* '''Response time''': the time since the last event of some event pattern is fed into the system until the system notifies the event pattern detection.
* '''Response time''': the time since the last event of some event pattern is fed into the system until the system notifies the event pattern detection.
-
* '''Scalability''': Unlike other benchmarks that considerer scalability only as a variation of the benchmark with more data and more users, in BiCEP we would like scalability to be a first-class metric. That is, while it is useful to compare systems at different scale levels, it is also very interesting to assess how well a given system scales. For example, CEP engines can use some of the new techniques (e.g., [http://aws.amazon.com/ec2 Amazon Elastic Compute Cloud]) that allow a system to grab hardware resources on demand makes. We are planning scalability experiments along three directions: i) scale-up: increase the system and increase the load, ii) speed-up: increase the system and maintain the load, and iii) load-up: maintain system but increase the load.
 
* '''Adaptivity''': Typically, systems are benchmarked after they are “warmed-up” and in a steady state. However, while it seems that there will be periods where CEP systems are in steady states, it also appears likely that, due to the very unpredictable nature of the real-world events being processed by CEP engines, there will be frequent disruptive moments, when the system should adapt its query processing to be more efficient.
* '''Adaptivity''': Typically, systems are benchmarked after they are “warmed-up” and in a steady state. However, while it seems that there will be periods where CEP systems are in steady states, it also appears likely that, due to the very unpredictable nature of the real-world events being processed by CEP engines, there will be frequent disruptive moments, when the system should adapt its query processing to be more efficient.
 +
* '''Scalability''': Unlike other benchmarks that considerer scalability only as a variation of the benchmark with more data and more users, in BiCEP we would like scalability to be a first-class metric. That is, while it is useful to compare systems at different scale levels, it is also very interesting to assess how well a given system scales. For example, CEP engines can use some of the new techniques (e.g., [http://aws.amazon.com/ec2 Amazon Elastic Compute Cloud]) that allow a system to grab hardware resources on demand makes. We are planning scalability experiments along three directions: i) scale-up: increase the system and increase the load, ii) speed-up: increase the system and maintain the load, and iii) load-up: maintain system but increase the load.
* '''Computation Sharing''': Many CEP applications process tens, hundreds, millions of similar queries concurrently. For example, a CEP engine in a financial trading company may be processing thousands of rules for each stock ticket: many customers may be monitoring the same stock but each customer may have slightly different buy or sell values. If the CEP engine can devise query processing techniques such that different queries are able to share computation, then the scalability potential of the system is greatly improved.  
* '''Computation Sharing''': Many CEP applications process tens, hundreds, millions of similar queries concurrently. For example, a CEP engine in a financial trading company may be processing thousands of rules for each stock ticket: many customers may be monitoring the same stock but each customer may have slightly different buy or sell values. If the CEP engine can devise query processing techniques such that different queries are able to share computation, then the scalability potential of the system is greatly improved.  
-
* '''Similarity search and precision and recall''': As far as we know, no CEP engine uses any kind of similarity search: the patterns being searched are always precisely specified by a query language. Thus, we expect no false positives and no false negatives. However, if CEP users demand more and more complex patterns, we expect CEP engines to start using similarity search. If similarity search is used, then CEP engines may occasionally produce incorrect results by way of false positives and false negatives. We also expect false positives and false negatives if CEP engines use past events to forecast real-world future events.  
+
* '''Similarity search and precision and recall''': As far as we know, no CEP engine uses any kind of similarity search: the patterns being searched are always precisely specified by a query language. Thus, we expect no false positives and no false negatives. However, if CEP users demand more and more complex patterns, we expect CEP engines to start using similarity search. If similarity search is used, then CEP engines may occasionally produce incorrect results by way of false positives and false negatives. We also expect false positives and false negatives if CEP engines use past events to forecast real-world future events.
 +
-->
 +
 
 +
== What's New ==
 +
* '''15-Oct-2013''': “''Pairs''” benchmark updated. A new version of the benchmark specification has been released ([http://bicep.dei.uc.pt/images/8/8f/Pairs_Benchmark_%28rev._1.0%29.pdf view]).
 +
 
 +
* '''17-Apr-2013''': FINCoS certified by the Standard Performance Evaluation Corporation (SPEC). The FINCoS framework has undergone a thorough review process, having been accepted to integrate SPEC Research Group’s repository of quantitative evaluation and analysis tools  ([http://research.spec.org/tools.html More info]).
 +
 
 +
* '''20-Mar-2013''': A new version of the FINCoS Framework (2.4.2) has been released ([http://fincos.googlecode.com/files/FINCoS%202.4.2.zip Download]).
 +
 
 +
* '''06-Fev-2013''': New Publication: the paper titled “''Towards a Standard Event Processing Benchmark''” has been accepted to be presented in the Vision/Work in Progress track of 4th ACM/SPEC International Conference on Performance Engineering (ICPE 2013), to be held in Prague, from April 21 to 24. ([http://bicep.dei.uc.pt/index.php/Publications View full list of publications.])
 +
 
 +
* '''21-Jan-2013''': Benchmark “''Pairs''” released. The first of the BiCEP domain-specific benchmarks is now available. The benchmark description and its specification can be found [http://bicep.dei.uc.pt/index.php/Benchmarks here].
 +
 
 +
* '''09-Jan-2013''': New Publication: the paper titled “''Overcoming Memory Limitations in High-Throughput Event-Based Applications''” has been accepted to be presented in the Industry track of 4th ACM/SPEC International Conference on Performance Engineering (ICPE 2013), to be held in Prague, from April 21 to 24. ([http://bicep.dei.uc.pt/index.php/Publications View full list of publications.])
 +
* '''10-Dec-2012''': A new version of the FINCoS Framework (2.4.1) is now available. This release fixes problems on RMI communication when running under Java 7 and brings several other minor improvements.([http://fincos.googlecode.com/files/FINCoS%202.4.1.zip Download])
-
The project started in September 2007 and is funded by an [http://cordis.europa.eu/mariecurie-actions/irg/home.html FP6 Marie Curie International Reintegration Grant].
+
* '''07-Out-2012''': A new version of the FINCoS Framework (2.4) has been released. This version adds support for improved load generation through user-provided data files, and brings a number of other minor enhancements and fixes.
-
----
+
== ==
-
<big>'''Publications'''</big><BR>
+
-
#Rafael Marmelo, Pedro Bizarro, and Paulo Marques. 9ticks – The Web as a Stream ([[DAIT2009_9ticks.pdf | pdf]]). In the First International Workshop on Database Architectures for the Internet of Things (DAIT 2009). Extended version ([[IETE_9ticks.pdf | pdf]]) also published on the 2009 September/October issue of IETE Technical Review journal. (paper and details coming soon)
+
-
#Diogo Guerra, Ute Gawlick, and Pedro Bizarro. An Integrated Data Management Approach to Manage Health Care Sensor Data ([[DEBS2009.pdf | pdf]]). In the Proc. of the Intl. Conf. DEBS 2009. (DEMO)
+
-
#Marcelo R. N. Mendes, Pedro Bizarro, and Paulo Marques. A framework for performance evaluation of complex event processing systems ([[DEBS2008.pdf | pdf]]). In the Proc. of the Intl. Conf. DEBS 2008: 313-316. (DEMO)
+
-
#Pedro Bizarro, BiCEP - Benchmarking Complex Event Processing Systems ([http://drops.dagstuhl.de/opus/volltexte/2007/1143/pdf/07191.BizarroPedro.ExtAbstract.1143.pdf pdf]). in [http://www.dagstuhl.de Dagshtul] Event Processing Seminar, 2007.
+

Current revision as of 16:36, 18 December 2013

Personal tools