Replies: 1 comment
-
|
There's not much to say/do here: the more arrivals you simulate, the more events are generated, and more time is require to complete the simulation. The simulation time grows linearly with the number of events that happen. Best practices? Keep the number of events (i.e. complexity of the trajectories) at the minimum required for your purposes. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I find for queues with small parameters (e.g. initial queue size, service rate, arrival rate), the results of the simulations take much shorter to run and the results seem more logical (e.g. smaller queue sizes for more servers vs fewer servers). I would have thought that the size of the parameters should not affect the time required to run the simulation? However, when looking at the time/results of the simulation involving queues with larger parameters, such issues still persist.
For example, here is a MMK queue with large parameters : library(simmer)
Even though the length of each simulation and the total number of simulations is relatively small, this simulation is still taking a long time to run.
For such situations (i.e. large queue parameters), are there any best practices for Simmer? Could someone please comment on my code for this situation?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions