{'fraction_non_alphanumeric': 0.022176022176022176, 'fraction_numerical': 0.0, 'mean_word_length': 5.446428571428571, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Analysing the Performances of Grid Services Handling Job Submission

Generally, users working on a Grid infrastructure have a keen interest in knowing (tight) upper bounds for execution times of useful Grid services and their own submitted jobs. However, the execution environments and times in a Grid infrastructure may widely vary in practice, because of several and diverse factors, including: the unpredictable delays on network links, peaks of service requests, the relatively unpredictable outcomes of resource negotiation, changes in services and resources availability (due to partial failure, etc.).It therefore appears that, for successful Grid operation, a crucial ability is that to analyse, and accordingly tune, the amount of resources needed to smoothly execute requests presented to  Grid services by user-submitted jobs. For such a tuning to be possible and effective, a suitable characterisation should be available of the times spent executing the services provided by the Grid middleware.This paper focuses on those Grid services, handling job submission, whose execution times can vary substantially, analysing what  factors determine or affect this variability. We present and analyse a set of measures that have been carried on a real infrastructure, as usage conditions vary. This knowledge can be very handy to detect the occurrence of anomalous states in Grid operation, and timely start appropriate recovery actions.