How do we schedueling control probe ?

Dear Expert
We are developing A Probe Management system using MikrotiK router board(RB751u) firmware 5.xx. It consists of CentOS 6.2 +Apache+MySQL and RRDtools. We focus on measurement functions (Bandwidth test, traffic generator test in tool menu). We use PHP api in our testing according your recommendations API_PHP_Pear2 / Net_RouterOS. Due to so many probes (100 Units) in our first step, we need to divide zone testing as shown in figure diagram in order to preventing broadcast storm when traffic come back to a server. In each zone we establish a center probe (A probe) for originate traffic to the other probes. A server will have schedule test every traffic zone for whole day periodically assuming 5- 15 min per probe. The bandwidth measurement and traffic generator will keep into database and will display in line graph or other.
Background: When the time is at the schedule setting, center probe (A) in zone 1 will execute bandwidth test api to B and C in asynchronous style according duration setting. At the same time, Zone 2 and Zone 3 will do the same way according to schedule setting: We may consider Contrab scheduler in CentOS.

Question

  1. When testing in Zone A has not finished, the rest zone (2,3) can execute command to probe in their zone according to schedule setting. We may call it that is background processing?
  2. We are not sure whether if we do simultaneously 100 probes , what ‘ happen in term of bottleneck or packet storm to system. Thus if we want to test each zone separately, Zone 1 will finish before zone 2 will start and zone 2 will finish before zone 3 will start..
    How do we know the execute commands in center probe or even the rest probe are proceeded? In other word, we will ensure the finish process of zone 1 before execute command in zone 2, or zone 3.
    3.If the process or bandwidth command in each probe is executed and not finish , How do we prevent the other user or server call it again. We need to put the next call or command in queuing accordingly.
    probe_management.jpg
  1. We are not sure whether if we do simultaneously 100 probes , what ‘ happen in term of bottleneck or packet storm to system. Thus if we want to test each zone separately, Zone 1 will finish before zone 2 will start and zone 2 will finish before zone 3 will start..
    How do we know the execute commands in center probe or even the rest probe are proceeded? In other word, we will ensure the finish process of zone 1 before execute command in zone 2, or zone 3.

Each API connection fetches data only as you ask for it, and is finished fetching by the time you’ve moved to the next one. PHP’s internal buffers can maintain a limited amount of data before that. In other words - even asynchronous requests are synchronous relative to the connection (and are only really “asynchronous” relative to the order in which they are processed by that one connection and your script).

100 simultaneous (and long running) connections are likely to strain your server a bit, sure, especially if it’s a more “average” machine. On the other hand, if some probes run faster than others, that wouldn’t be much of a problem. If you want to do THAT, I’d recommend running a PHP process for every API connection, and run each in the background (you know, from the command line with “&” at the end).

If you want to probe multiple connections one after the other (synchronously), you can do so from a single PHP script.

On that note,

  1. When testing in Zone A has not finished, the rest zone (2,3) can execute command to probe in their zone according to schedule setting. We may call it that is background processing?

in OS terms, yes.

3.If the process or bandwidth command in each probe is executed and not finish , How do we prevent the other user or server call it again. We need to put the next call or command in queuing accordingly.

If it’s possible that the other end has hanged or is otherwise taking too long, you can set up… if you’ll excuse the pun… a loop around Client::loop($timeout)… that will terminate if the last call didn’t get any data in the $timeout time.