Risultati test con richieste incrementali

Poiché fintanto che si è lavorato su documenti di media complessità, intorno alle 10 pagine, nei test precedenti i due modelli hanno ottenuto valori comparabili, si è deciso, in questa seconda fase di test, di mantenere fissata questa quantità e agire stavolta sul numero di utenti, andando a stressare i sistemi con carichi gradualmente maggiori, partendo da 3 richieste concorrenti fino ad arrivare a 100.

Figura 61 - Tempi di esecuzione con richieste incrementali

Partendo ancora una volta dall’analisi del caso isolato di MapReduce senza upload, di nuovo in giallo nel grafico, sono sempre più evidenti i vantaggi dell’elaborazione parallela dei documenti, che risulta dunque essere non solo indipendente dal numero di pagine, ma anche dal numero di utenti. Anche in questo caso, nessuna delle esecuzioni è mai durata più di un secondo. Un risultato molto convincente, che già di per sé potrebbe spingere verso l’adozione di un modello sequenziale.

Oltretutto, in questo caso, risulta essere preferibile perfino il modello parallelo con annesso upload dei risultati, effettuato in modo sufficientemente rapido da consentire di terminare l’esecuzione prima della controparte sequenziale. Quest’ultimo, infatti, seppure si comporti inizialmente meglio, fino al test con 20 richieste, è messo sotto sforzo dall’elevato numero di utenti nelle sessioni di test immediatamente successive, riscontrando un ripido aumento nei tempi già nella gestione di 30 richieste. Una tale dilatazione temporale è dovuta a un inevitabile accodamento delle richieste, non essendo il servizio capace di scalare con la medesima elasticità delle FaaS che implementano i mapper, seppure esso sia stato replicato su più nodi per rendere il confronto formalmente più corretto e realistico.

Osservando il grafico, è inoltre degno di nota il comportamento del MapReduce in corrispondenza del test con 40 richieste. È infatti possibile notare una riduzione dei tempi, rispetto al caso che lo precede. Il motivo è, anche in questo caso, dovuto ai cold start che, non essendosi verificati in quella particolare situazione, hanno permesso di raggiungere un tempo globale inferiore.

Questa fase di test è stata particolarmente significativa, perché ha permesso di trovare il punto a partire dal quale il modello realizzato va effettivamente a diventare preferibile al

modello standard sequenziale, non soltanto da un punto di vista dei tempi di esecuzione, ma anche e soprattutto da un punto di vista della correttezza nel servizio delle risposte. In questo caso, infatti, l’incremento del numero degli utenti fittizi è arrivato persino a causare alcuni errori di esecuzione, distinguibili in timeout delle richieste a causa degli accodamenti e in fallimenti nell’istanziazione dei container a causa di un’occupazione eccessiva delle risorse.

In Figura 62 si può osservare il report sul numero degli errori riscontrati nelle varie fasi del test, a seconda del numero di richieste effettuate.

Figura 62 - Numero di errori con richieste incrementali

Senza l’overhead del salvataggio dei risultati parziali, il MapReduce privato del meccanismo di upload ha concluso l’intera schiera di test senza mai riportare errori. Per quanto riguarda invece la versione completa, in rosso, gli unici errori sono stati riportati negli ultimi due test, i più critici in termini di occupazione delle risorse: un solo mapper fallito su 500, nel test da 50 richieste per 10 pagine, e 2 mapper falliti su 1000, nel test da 100 richieste per 10 pagine. Le percentuali di errore sono dunque prossime allo zero e ciò che le ha causate è stato semplicemente l’eccessivo sovraccarico sul cluster, che non ha potuto rispondere al bisogno di creare un numero così elevato di container: errori dunque facilmente evitabili dotandosi di un cluster con capacità maggiori.

Non si può fare lo stesso discorso per il sequenziale, che invece è stato affetto da una percentuale considerevole di errori, tra il 10% e il 15%. In questo caso la maggior parte degli errori è stato dovuto all’occorrenza di multipli response timeout (fissati a 120s nei test). La ragione è da trovarsi nell’accodamento delle richieste che si è verificato a partire

dal test con 30 richieste, che si riflette tra l’altro nella crescita improvvisa dei tempi, visualizzabile in Figura 61 proprio in corrispondenza delle 30 richieste.

In generale in questa seconda fase di test, per quanto riguarda l’occupazione della memoria, si sottolinea che il numero crescente di documenti e pagine da elaborare si riflette, nel MapReduce, in un numero crescente di mapper, e quindi di container da istanziare, il che comporta un consumo della memoria maggiore rispetto al caso sequenziale, ma comunque equamente distribuito sui nodi. Mediamente è stato osservato un consumo del MapReduce pari a circa 2-3 volte quello del programma sequenziale. Anche gli effetti di questo aspetto negativo si risolverebbero, in un eventuale scenario di produzione, utilizzando un cluster di dimensioni maggiori che possa smistare più efficacemente il carico.

6.6.3 Risultati test con frequenze maggiorate

In tutti i test presentati, è stata impostata una frequenza di invio delle richieste pari a 1 req/s. Un’ultima fase di test ha tentato di evidenziare eventuali cambiamenti andando aumentare tale frequenza. In generale, non sono state evidenziate particolari differenze, se non un carico leggermente maggiore sui nodi e una dilatazione, seppur minima, dei tempi. In particolare, dato il ridotto numero di operazioni che deve eseguire ogni mapper, un aumento nella frequenza delle richieste non ha comportato criticità. La maggiore difficoltà che ha invece incontrato il modello sequenziale nel gestire importanti flussi di richieste in ingresso ha fatto mantenere i valori negativi riportati nel test precedente. Date le marginali differenze, non è risultata di interesse un’analisi più approfondita di questo scenario.

Va infine fatta un’ultima considerazione generale che riguarda i tempi registrati nel MapReduce per tutti i test appena osservati. Sebbene la decisione di considerare il tempo massimo ottenuto in ogni gruppo di mapper sia formalmente la più corretta, è giusto sottolineare che, spesso, questa ha portato a registrare valori piuttosto elevati a causa anche di un solo mapper che, per motivi di sovraccarico o per cold start, ha terminato l’esecuzione molto dopo degli altri, influenzando negativamente il tempo globale. In particolare, per dare un’idea orientativa, si è visto che mediamente, in un gruppo di mapper, circa l’80-85% riusciva a completare il proprio lavoro tra i 200ms e i 700ms, mentre solo il restante 15-20% necessitava di secondi addizionali. Questa stima va dunque ulteriormente a far propendere verso il modello parallelo, tendenzialmente capace di terminare i propri task in tempi notevolmente minori rispetto alla controparte sequenziale.