## 5 Dynamic Optimization of the Crowdsourcing Platform
### Dynamic Optimization Engine Based on Metric Indices
```
1:Procedure BUILD (Input: _dbname_, _n_vectors_, _n_pivots_)
2:Index.obj[] = load_DB(dbname)
3:Index.n_pivots = n_pivots
4:Index.Table = array_n_vectors, n_pivots]
5:fork = 0 to k = Index.n_pivots - 1 do
6:Index.piv[k] = obj[k];
7:endfor
8:fori = 0 to i = Index.n_vectors - 1 do
9:forj = 0 to j = Index.n_pivots - 1 do
10:Index.Table[i, j] = distance (Index.obj[i], Index.piv[j])
11:endfor
12:endfor
13:return Index;
```
**Algorithm 2** Algorithm used to build the pivot-based indices. ### Crowdsourcing Platform Parameter Configuration: Scheme of Two Metric Indices

In our case study, it was expected that all tasks reaching the volunteer community would obtain consensus, as the processed images contributed to creating disaster situation maps. So, it was important to maximize the consensus percentage. Moreover, several factors indirectly influence whether the consensus percentage rises or falls. In other words, anything causing task resolution delays can have a negative impact on consensus levels. These factors include the time-to-live (TTL) of the tasks, the consensus threshold required for voting (C), and the overutilization of the platform resources. The TTL represents the period of time in which tasks are active, and then must be completed. If in that period of time a task cannot be resolved, then it is discarded and terminated without consensus. Overutilization can be caused by (a) a high occupancy of the ISP network or the P2P network, (b) the absence of volunteers available to process the tasks, (c) the overload of the server, which prevents it from sending tasks to the volunteer community in time, and also delays in the reception and processing of volunteer responses. Likewise, a high consensus threshold (\(C\)) will require the server to gather more matching responses from volunteers before it can declare a consensus. Note that during the time the server waits to gather \(H\) responses, the TTL could run out, causing the task to terminate without consensus. Finally, we kept the ISP network utilization between 20% and 40%. We kept the IPS network utilization above 20% so that the network was not underutilized and below 40% to prevent the system from becoming saturated in case of abrupt increases in input tasks. Then, as we explained before, we aimed to adjust the configuration parameters of the crowdsourcing platform in two situations: (1) when the platform is overloaded or under stress and (2) a second situation in which we aimed to recover the original parameter configuration values, when the platform is not under stress. In Figure 5, we show the steps involved in the building phase of our proposed dynamic optimization engine. As we explained before, we simulated the crowdsourcing platform to create the configuration vectors which in turn were used to create the metric space database. Then, we built the two indices, one for workload (or stressed) situations and the other for non-workload situations (or non-stressed). The indices were built using the same configuration vector database but with different weighting (\(R_{1},R_{2},R_{3}\)) for the subgroups of controllable parameters, non-controllable parameters, and the metrics. Notice that when the platform is under stress, the utilization metric of the networks, the server, or the peers will be above 40%. Therefore, we want to retrieve a configuration vector with values of the metrics below 40%. To this end, in the input configuration vector we set the values of the metrics reporting work overload to 20%. Then, we set \(R_{3}>R_{2}\) to prioritize recovering configuration vectors with performance metrics close to 20%. Figure 6 illustrates how to use the two indices and the constants \(R_{1},R_{2}\) and, \(R_{3}\). This example shows the variation in the average ISP utilization. At time \(T_{1}\), the ISP utilization is above 40%, so the platform is in a stressful situation.