TiNoleggio & Partners

Non allarmatevi, non mi riferisco ad una manifestazione con cantante lirico e ospiti internazionali, nè ad una società di revisione conti, ma all’ultimo progetto che sto seguendo.

Parlo di www.tinoleggio.it, portale di ricerca comparata per il noleggio di mezzi di trasporto, dall’automobile alla barca, creazione di una giovane start-up milanese che nel suo arsenale web annovera anche www.tiprovo.it e altri diversi progetti interessanti ancora in cantiere. TiNoleggio permette di trovare le tariffe (teoricamente) più basse sul mercato grazie alle numerose partnership intrecciate con società di noleggio o altri aggregatori di prezzi. Queste partnership commerciali devono naturalmente essere tradotte in software: e qui arriviamo al perchè sono stato chiamato 15 giorni fa a dare il mio contributo al progetto (se ve lo state chiedendo: sì, è squillato il telefono rosso che tengo nascosto dietro il quadro di Rembrandt)

Ci sono due problemi da risolvere. Il primo è che le modalità di accesso ai dati forniti dai partner, tramite le quali effettuare le ricerche, sono abbastanza variegate: database, API, siti web sui quali lanciare spider. Il secondo è che, all’aumentare dei partner, aumenta anche il tempo computazionale di ricerca, ed è fondamentale evitare di raggiungere il famigerato TAU (Traguardo di Assopimento Utente).

Uniformare i partner

La soluzione al primo problema è semplice: incapsuliamo i partner e i loro meccanismi di ricerca all’interno di una serie di classi polimorfe. Abbiamo quindi diverse classi Partner, contenenti definizioni e dettagli relativi ai partner, e PartnerSearchEngine, che incorporano la logica di ricerca sui dati del partner. In questo modo viene definita una linea guida per creare un futuro partner, in modo totalmente indolore, in quanto il motore di ricerca di TiNoleggio non dovrà essere riadattato per gestire la nuova integrazione: saprà già quali metodi chiamare per ottenere ciò che gli serve.

Parallelizzare le ricerche

Anche qui non parliamo di rocket science: se 3 processi ci mettono 3, 5 e 7 secondi ad eseguirsi, e vogliamo che il tempo di esecuzione totale sia sotto i 15 secondi, dovremo eseguirli in parallelo. Il tempo di esecuzione totale sarà quello di esecuzione del processo più lento (in linea teorica; bisogna tenere in considerazione l’overhead e il maggior consumo di risorse hardware).
In PHP, abbiamo due modi per eseguire processi paralleli: l’utilizzo delle fork e la chiamata di script lanciati in background (su Unix, in questo caso) Dato che le fork sono assolutamente sconsigliate in ambiente Apache, si ricade forzatamente sulla seconda opzione. Ci sono diverse funzioni che permettono di eseguire script in background: io ho utilizzato proc_open, flessibile e potente.

Oltre alla parallelizzazione dei processi di ricerca dei partner, è stato implementato un ulteriore livello di parallelizzazione: quello delle richieste HTTP, nel caso in cui la ricerca preveda l’utilizzo di chiamate ad API del partner o spidering del loro sito. Tutto ciò è stato ottenuto utilizzando la libreria cURL (modulo PHP da installare a parte), della quale ho incapsulato le funzinoalità in un paio di classi, per facilitarne l’utilizzo.

Come sempre, consigli e commenti sono sempre ben accetti!

Tags: , , ,