@@ -79,6 +79,8 @@ const report = simulator.simulate([{
7979 meanServiceTime: 15 , // minutes
8080 arrivalRate: 0.9 , // jobs/min = 54 jobs/h
8181}]);
82+
83+ // Use report.toHtml() to get a formatted version of the report with charts etc.
8284```
8385
8486Notice that, in this example, we get a job almost every minute, but it takes 15
@@ -122,7 +124,7 @@ const report = simulator.simulate([{
122124As the simulation report shows, both departments have to wait about the same
123125amount of time (approximately 21.5 min), on average, for their jobs to finish.
124126This is because the default scheduling policy for a job queue is first-in,
125- first-out (FIFO), so every job, regardless of their share identifier, has to
127+ first-out (FIFO), so every job, regardless of their share identifier, has to
126128wait for the same number of jobs in the queue, on average.
127129
128130![ ] ( ./docs/img/fifo-finance-distribution.png )
@@ -152,14 +154,12 @@ const queue: batch.JobQueue = new batch.JobQueue(this, 'myJobQueue', {
152154});
153155```
154156
155- The resulting distributions are about 21 minutes for Finance and 17 minutes
156- for Research:
157+ The resulting distributions are about 21 minutes for Finance and 17 minutes for
158+ Research:
157159
158160![ ] ( ./docs/img/fairshare-finance-distribution.png )
159161![ ] ( ./docs/img/fairshare-research-distribution.png )
160162
161- [ // ] : # ( TODO: compute reservation )
162-
163163## Retry strategies
164164
165165Let's go back to the basic example, and add a retry strategy, in which jobs that
@@ -202,10 +202,50 @@ minutes, in this case:
202202> simulation, generated jobs that are considered to fail will be "retried"
203203> if their job definition has at least one retry strategy with action ` RETRY ` .
204204
205- [ // ] : # ( TODO: "Future work" section )
205+ ## Using other distributions
206+
207+ Although the Markov process is the most commonly used to model queueing systems,
208+ your particular use case may be better modeled by some process. For example, in
209+ many applications, batch jobs are triggered periodically by some scheduler
210+ like [ cron] . The service time may still be exponentially distributed, but the
211+ inter-arrival time is now deterministic. To model these situations, use the
212+ lower-level API provided by the _ general_ process:
213+
214+ ``` ts
215+ const simulator = BatchSimulator .general (stack );
216+ ```
217+
218+ and specify the probability distributions directly:
219+
220+ ``` ts
221+ const report = simulator .simulate ([{
222+ jobDefinition: smallJob ,
223+ interArrivalTimeDistribution: Distribution .deterministic (5 ),
224+ serviceTimeDistribution: Distribution .exponential (1 / 30 ),
225+ }]);
226+ ```
227+
228+ If you need to use some more probability distribution that is not available in
229+ the ` Distribution ` class, you can bring your own, by implementing the
230+ ` IDistribution ` interface.
231+
232+ ## Unsupported features (yet)
233+
234+ Some of the AWS Batch features are not being simulated by this library:
235+
236+ - ** Queue priority** : If you have multiple queues sharing a compute environment,
237+ they will be treated with the same priority. The order in which jobs will be
238+ picked for execution depends only on their position in, and the scheduling
239+ policies of, their respective queues.
240+ - ** Spot instances** : The ` spot: true ` configuration in compute environments is
241+ completely ignored.
242+ - ** Share decay** : Even though compute reservation is taken into account for
243+ simulation, the share decay, if defined, is also ignored.
206244
207245[ AWS Batch ] : https://aws.amazon.com/batch/
208246
209247[ CDK ] : https://aws.amazon.com/cdk/
210248
211- [ mmc ] : https://www.wikiwand.com/en/M/M/c_queue
249+ [ mmc ] : https://www.wikiwand.com/en/M/M/c_queue
250+
251+ [ cron ] : https://en.wikipedia.org/wiki/Cron
0 commit comments