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!

  • Digg
  • del.icio.us
  • Facebook
  • StumbleUpon
  • Technorati
  • Twitter

Tags: , , ,

4 Responses to “TiNoleggio & Partners”

  1. sa_su_ke Says:
    December 31st, 2010 at 5:05 pm

    molto interessante. Hai provato a vedere anche node.js? Supporta la gestione di richieste http asincrone

  2. francesco Says:
    September 2nd, 2011 at 2:38 am

    ciao,
    non ho ben capito perchè parli di due (2) sistemi di parallelizzazione: «Oltre alla parallelizzazione dei processi di ricerca dei partner, è stato implementato un ulteriore livello di parallelizzazione: quello delle richieste HTTP»

    quando cerchi i risultati sul sistema del partner lo fai con richieste http no? solo quelli devi parallelizzare o sbaglio?

    poi ti volevo chiedere riguardo alle richieste http in parallelo che fai:
    - usi curl_multi_exec ?
    - quanti handle in parallelo hai in media per ogni esecuzione?
    - hai provato a stimare i tempi morti di ogni richiesta? nel senso se hai 5 richieste in parallelo e diciamo che quattro di esse impiegano 5 sec. mentre la quinta impiega 15 sec. le altre sono ferme per 10 secondi.
    il chè può essere influente se i risultati non occupano molta memoria…ma se ogni richiesta ti restituisce qualche MB di dati…la RAM te la giochi facilmente.
    - hai pensato ad un sistema di cache dei dati? (se faccio la stessa ricerca a distanza di poche ore come procedi?)

    ultima domanda :) che software utilizzi per i disegni (che sono troppo fighi)

    ciao.

    ps. sto affrontando un progetto simile al tuo (altre cose non noleggi) quindi potrebbe essere interessante confrontarci.

  3. Lina Sino Says:
    October 11th, 2011 at 7:18 pm

    i disegni sono fantastici, ma c’e’ la versione italiana? ;) grazie, Lina

  4. rpgames Says:
    October 31st, 2011 at 1:26 am

    Anche se sono alle prime armi, sembra tutto abbastanza chiaro!

Leave a Reply