Friday, February 27, 2015

Insights into performance & sizing Business Resource Planner (part I)

(Article guest authored together with Maggie Hu, Senior Middleware Solutions Architect at Red Hat in North America and Geoffrey de Smet, Senior Software Engineer at Red Hat in Europe)

Two of the biggest questions anyone has when looking at using or adding a new component into an existing solution architecture is that of performance and sizing.

The first question is always hard to correlate from a document produced by a product vendor in comparison to your own specific solution or problem space, which makes almost any look at performance measurements an exercise in "guesstimation." After all, the producer of the performance numbers is using a setup or implementation that tends to deviate just enough from your own to raise a bit of doubt in the direct application of the results.

The second question follows closely with the first, as it is often performance that leads to a sizing estimation. One can often improve the performance by increasing resources in the deployment infrastructure and base hardware improvements can go a long ways to improving your solutions performance without changing a single line of code.

This article will tackle both questions in a linear fashion, presenting an example solution scoping of the underlying hardware as a baseline with several use cases to try and give you the widest possible coverage of numbers to evaluate for your sizing needs.

Business Resource Planner is part
of both JBoss BPM Suite and
JBoss BRMS products.
It is possible for you to employ the same techniques on your own Business Resource Planner project solutions to gather even more accurate feedback as to your performance and sizing needs.

Introduction

Business Resource Planner is a lightweight, embeddable constraint satisfaction engine which optimizes resource and planning problems.

This component can be found as part of the Red Hat JBoss BRMS and Red Hat JBoss BPM Suite products. It is based on the upstream project, OptaPlanner, and is currently available as a technical preview. In the follow release of these products it will be given fully supported status, so we thought it was perfect timing to introduce you to some performance and sizing information.

An overview and further details of the product can be found on Red Hat’s Customer Portal - Business Resource Planner Guide.

This article will set the stage by outlining the three example use cases to be used for performance and sizing runs and explain our setup to evaluate as a baseline.

In follow on articles in this series we will show you how we set all this up and then detail some of the terminology involved in these types of solutions. It will entail using the Business Resource Planner component along with its benchmark tooling to present each case results.

Case examples

The following three examples have been chosen from the set of documented examples so that you have a good explanation around each one. You can explore these and quite a few more on the Customer Portal.

In each example below we will detail what the problem is, the domain size and how it is modeled along with the data sets used.


1. Cloud balancing

Suppose your company owns a number of cloud computers and needs to run a number of processes on those computers. The problem to be solved is how to assign each process to a computer under the given constraints to minimize the total maintenance cost.

The data sets to be run in our benchmark will be:
  • 100 computers with 300 processors
  • 400 computers with 1200 processors
A simple to understand problem with just one entity, one variable and data sets that scale up nicely to show both performance and sizing.

2. Curriculum course scheduling

Need to schedule each lecture into a time slot and into a room. The following constraints apply to this use case.


Hard
A hard constraint can not be broken or the solution found is not feasible.

  • Teacher conflict: A teacher must not have 2 lectures in the same period.
  • Curriculum conflict: A curriculum must not have 2 lectures in the same period.
  • Room occupancy: 2 lectures must not be in the same room in the same period.
  • Unavailable period (specified per dataset): A specific lecture must not be assigned to a specific period.

Soft
Soft constraints can be broken but have a penalty in a solution, making them undesirable but sometimes unavoidable.

  • Room capacity: A room's capacity should not be less than the number of students in its lecture.
  • Minimum working days: Lectures of the same course should be spread into a minimum number of days.
  • Curriculum compactness: Lectures belonging to the same curriculum should be adjacent to each other (so in consecutive periods).
  • Room stability: Lectures of the same course should be assigned the same room.

A more complex problems space with a single entity and two variables, the data sets run in this benchmark are found within the example project:

  • comp01.ctt
  • comp02.ctt

3. Nurse rostering

An advanced example case where we are solving a roster where for each shift, we assign a nurse from the staff to work that shift. The following constraints apply to this use case.

There are three types of nurses and eight nurses to be scheduled:
  • Maternity nurses
    • Ann, Beth, Cory
  • Emergency nurses
    • Dan, Elin, Greg
  • Basic nurses
    • Hue, Ilse
Hard
A hard constraint can not be broken or the solution found is not feasible.
  • Shifts: all required shifts must be assigned.
  • Amount: only one shift per day per nurse.
Soft
Soft constraints can be broken but have a penalty in a solution, making them undesirable but sometimes unavoidable.
  • Ann: maximum consecutive working days is 5
  • Beth: minimum consecutive free days is 2
  • Carla: has a days-off wish for Sundays
  • All: after night shift sequence a nurse gets 2 days-off
  • and a few more... 
This is another complex solution space with a single entity and single variable, but has variable data set types with time limits being assigned for finding a solution set (sprint as in seconds, medium as in minutes and long as in hours). We will be using the first two types as found within the example project:
  • sprint_01.xml
  • medium01.xml

The bench

The hardware and software used to run this performance and sizing benchmark exercise are listed for your reference.
  • Processor: Intel Core i7
    • Speed: 2.3 GHz
    • Number: 1
    • Cores: 4
    • L2 Cache (per Core): 256 KB
    • L3 Cache: 6 MB
  • Memory: 16 GB
  • OS: osX 10.10.2
  • Java (JDK): 1.7.0_71

In the following articles in this series we will walk through the setup and start running the above use cases and present our results.