# Timed Colored Petri Net-Based Event Generators for Web Systems Simulation
## 4 Case Study  
We provide a simple example to demonstrate the usage of the proposed solution. It combines the most advanced timed stochastic generator model and a simplified model of a web server. The HTCPN structure of the system is presented in Figure 13.  
The model reuses the generator structure presented in Figure 11 along with all the initial markings, resulting in the sequence of generated events shown in Figure 12. The generator is now enclosed inside the substitution transition EventGenerator to better display the new web server structure. In the part consisting of the transition mapToRequest and the place Requests, the generated events are first mapped from their generic representation Evt1, Evt2, Evt3 to request form (Usr1,Res1), (Usr1,Res2), (Usr2,Res2), respectively. Requests are pairs that indicate a user and a resource needed for it. Any execution of the transition addToQueue puts a triple including the user, the resource, and the entry time now() of a new request into the FIFO queue modeled by the place ReqFIFO. It is a model of the buffer collecting the requests waiting for processing by the server. The FIFO regime is asserted by the list in ReqFIFO, the input elements are added to its end, while the exiting ones are removed from its beginning by the transition startProc. The latter transition executes whenever the FIFO list is not empty and the guard expression n > 0 is satisfied, and its execution models start request processing. In turn, execution of the transition endProc models the processing completion. Between the start and completion, the token representing the processed request is held in the place Processed with a time delay being the processing time depending on the related user and resource. The delay is determined by the expression of the arc from startProc to  
Figure 12: Number of events as a function of time obtained from the timed stochastic model. Figure 13: Simulation HTCPN-based model of web server system (initial marking). Processed. The value of the token in NProc represents the number of free processors and it is used to block the processing of new requests while all processors are busy. Remaining elements: QueueLoad, cleanUp, Finished register data from the model for further analysis. In particular, the final marking of QueueLoad represents FIFO entry and exit times of the requests delayed by the queue, while the final marking of Finished contains the entry, starting, and completion times of all processed requests. Simulation experiments have been performed for the configurations with 8 and 16 processors. One can observe on histograms in Figure 14 that there are many delayed requests while using 8 processors and the delays reach up to 4 s (Figure 13(a)). On the other hand, there are only a few insignificant delays in the case of 16 processors (Figure 13(b)). It immediately reveals that the requests cannot be effectively processed in the first configuration, while the second one is sufficient. This observation is consistent with other characteristics plotted below. The number of requests waiting in the input FIFO queue as a function of time is shown in Figure 14(a). There are almost no waiting requests for 16 processors, while their number starts to increase since about 8 s for the server with 8 processors, up to approximately 40 requests. Note that the FIFO queue delay time as a function of the request entry time (Figure 14(b)) is proportional to the number of waiting requests, and its maximum value is about 4 s, in accordance to the histogram in Figure 13(a). The data useful for processor load analysis is given in Figure 16. The 8-processor server is fully loaded since 8 s and it does not process requests on time. There is no such problem in the second case, where the number of processors turns out just right and all processors work together only at very short time intervals (Figure 15(a)). As long as the servers are not overloaded they process requests with similar efficiency, but then the 16-processor server works relatively faster (Figure 15(b)).