3 ms·
Well, here's a quick simulation assuming request servicing follows a Poisson process. The Manipulate function takes a function and generates an interactive vers
by spitfire 13y ago
Well, here's a quick simulation assuming request servicing follows a Poisson process. The Manipulate function takes a function and generates an interactive version of that function. So in this case it has a graph (list plot) of the simulation, along with a slider to manipulate the number of new requests (arrivals).
If you wanted to be ambitious, you could simulate different servicing distributions, and times. But that might add a whole 2-3 lines of code to the solution.
http://imgur.com/66wczZu http://imgur.com/66wczZu
Manipulate[
ListLinePlot[
RandomFunction[QueueingProcess[arrivals, 60/8] , {0, 50}][
"Path"]], {arrivals, 1, 30}]
- tfb 13y agoSo how does generating a graph actually solve the problem in the real world? Or am I misunderstanding what the problem is? I was assuming the problem was with some real world application, most likely regarding the implementation of some complex networking algorithm for Heroku's system. But if it's just some abstract math problem, of course it would make sense to use something like Mathematica, MATLAB, etc.
- spitfire 13y agoThat was just to demonstrate the problem. You could solve it by using NSolve[expr, vars] and giving a limit for the response time you'd like. You'd get back the number of dyne's you'd need to meet those requirements. On heroku's side, you could model their network with a few lines of code and experiment with different types of queues to find things that work well and are affordable. As PG said in beating the averages, it's one o those things that's easy to dismiss when you're looking up the power curve.