How to determine actuator and process for PID, and how to intepret the output

Question

Imagine there is a web service (let's say Twitter) that handles tons of requests from around the world. I want to figure out how to let the web service pick a certain amount of (let's say 1 billion) requests within a full month, smoothly. By "smoothly" it means I prefer not to have a solution that picks the very first 1 billion requests of the month then becomes idle. The distribution of the picked requests should roughly match the distribution of real traffic. However, the traffic to Twitter is always fluctuating and hard to predict beforehand (e.g., in the case of Superbowl) so I would like to apply a PID controller as below:

Setpoint: number of requests I gonna pick for the next time interval

Input: number of requests I actually pick for the next time interval

Setpoint can be set as (1 billion monthly goal - how many have I picked so far in the month) / number of time intervals left. Input is obviously simply an observation value.

Here come the parts I am confused: what should be the choice of actuator and process, and how to interpret the PID formula output? According to these videos on PID controller (1, 2):

• In the case where you want to control a quadcopter s.t. it hovers on a certain height, propellers are the actuators and the drone is the process that is lifted by propellers. If the output is x, you set the RPM to x.
• In the case where you want to control a bot s.t. it stops in a spot 50m away, robot feet are the actuators and the robot is the process that is driven by its feet. If the output is x, you set its speed (m/s) to x.

With a similar thought, in the system I describe, I want to consider a simple filter that picks any incoming request by a rate r as the actuator, and the process is the web service itself. But there can be of course many other options to pick the actuator and the process function.

Am I correct that: PID itself does not care about the actuator and the process. It is nothing more than a formula that takes in a set of parameters and observation values, then give you the "output". It is your call to pick an (actuator, process) combination and interpret the output accordingly, either RPM / speed(m/s) / filter rate r.

Answer 1

I think you're way overthinking this.

If you want to evenly handle N events in a month, then you convert a month to whatever time granularity you like (T) and then handle (N/T) events per T.

For example, if you want to handle 300 events in a 30 day window, and you want it smoothed to the day, then you handle (300/30) = 10 events per day.

If you have a billion events you want to handle in a 30 day window, and you want it smoothed to the millisecond, then you convert a month to milliseconds:

$$ T = (30 \mbox{days} * 24\mbox{hr/day} * 3600\mbox{s/hr} * 1000\mbox{ms/s}) \\ T = 2,592,000,000 \\ $$

Then you handle (N/T) events per T, or (1,000,000,000 / 2,592,000,000) events per millisecond. This works out to 0.3858 events per millisecond.

You can invert that number (1/result) or (T/N) to get T's per event, or in this example milliseconds per event - (2,592,000,000 / 1,000,000,000) = 2.592 milliseconds per event.

So, to "smoothly" handle a billion events per month, set a timer for 2.592 milliseconds, then handle that event. You can add the sample delay to your next timer, such that if you actually wind up waiting 3 ms for the next message to come in, then you've waited "too long" by (3 - 2.592) = 0.408 ms, so you can adjust your next timer by the same to get "back on track" - the next timer becomes (2.592 - 0.408) ms = 2.184.

If perfectly sampled, you'd get two new samples at (2.592 + 2.592) = 5.184 ms, and with the delay-forwarding above you still get two new samples, even if the first one is delayed, in (3 + 2.184) = 5.184 ms.

Answer 2

Am I correct that: PID itself does not care about the actuator and the process.

Yes. But keep in mind that a PID controller works well for processes that have a certain kind of dynamics, namely that they have some constant or slowly moving offset which driven by some random process with a finite variance (or are driven by something that can be reasonably modeled as such).

You may find that your network processes don't fit that "finite variance" criteria. In particular, your Super Bowl example -- if you didn't predict it by knowing when the Super Bowl is showing -- would have a very long-tailed distribution.

To use your Super Bowl example, you'd start by over-collecting (because you didn't know the event was coming), then you'd lack space for the Super Bowl, then you'd under-collect for a while.

Given that events are, essentially, totally unknown, it may be better to modify the algorithm that you initially describe -- pick the first billion samples, but time-stamp them. Then, as more traffic comes in, discard existing samples so that the daily (or hourly) distribution of samples is driven to be a scaled version of the actual traffic, or whatever distribution you think is best.