Come ottimizzare l'applicazione con un numero enorme di richieste di database al minuto

Question

Come ottimizzare l'applicazione con un numero enorme di richieste di database al minuto

#1 da (4 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (-1 voti)

2

Devo fornire free demo di alcuni servizi agli utenti finali nella mia applicazione. La demo gratuita potrebbe essere di 30 mins, 1 hours, 5 hours ecc. ( predefined time ) per un nuovo utente per una sola volta.

L'utente può anche consumare quel tempo in parti. come in 30 minuti di demo gratuita, possono usare come 10 minuti oggi, 15 minuti domani e il resto del tempo il giorno successivo ecc. Ora se un utente sceglie la demo gratuita di 30 minuti ed effettua il login & usando il servizio. Posso limitare l'utente per 30 minuti tramite la sua ora di inizio & fine del tempo. Posso inviarli alla pagina di pagamento se somma di start & il tempo di fine è uguale a 30 min.

Ora il problema si presenta con alcune condizioni incerte come se l'utente chiudesse il browser o la sua rete smettesse di funzionare o qualcos'altro alla fine durante la loro sessione attiva. In questo, non riesco a calcolare il loro tempo consumato a causa della mancanza di tempo di fine.

Lo scenario potrebbe essere come sotto (per 30 min demo).

UserID  StartTime           EndTime             Consumed(mins)
10      09-04-2015 10:00    09-04-2015 10:10        10
10      10-04-2015 05:00    10-04-2015 05:04        4
10      11-04-2015 07:46    11-04-2015 07:56        10
10      11-04-2015 10:00    // Browser closed or any uncertain condition
10      11-04-2015 11:00    // How to restrict user to use actual 30 mins because I do not have EndTime in above row to calculate Consumed mins.

Potrei avere più di 100000 utenti allo stesso tempo per utilizzare i nostri servizi, quindi sto trovando una soluzione efficiente per questo.

Secondo la mia comprensione, posso creare un lavoro separato per controllare LastActiviteTime dell'utente e in base al quale posso aggiornare i loro consumi (min) nel database. Quel lavoro verrebbe eseguito ogni minuto e, d'altra parte, il browser di ogni sessione utente aggiornerebbe il LastActiveTime nel database.

Questo può risolvere il mio problema, ma non sono molto sicuro delle prestazioni della mia applicazione a causa dell'enorme numero di richieste di database al minuto.

Si prega di consulenza.

design database architecture .net enterprise-architecture

posta Jitendra Pancholi 09.04.2015 - 07:29

fonte

4 risposte

Leggi altre domande sui tag design database architecture .net enterprise-architecture

Scegli dinamicamente la classe di fabbrica corretta con Inversion of Control Va bene deprecare i metodi che devono essere pubblici a causa del modello di packaging ma non devono essere utilizzati al di fuori del codebase in Java?

score 4 · Answer 1

Non penso che prendere una decisione se il tempo di prova è esaurito sul client è una buona idea. Questo può essere facilmente ingannato e non può essere calcolato con una certa precisione.

Dato che hai un'applicazione web, immagino, sarebbe molto meglio limitare un numero di chiamate API che un utente di prova può effettuare senza pagamento. Puoi fare alcuni test e mappare un numero medio di chiamate API in un momento, un utente medio spende il tuo software.

score 0 · Answer 2

Hai ragione nel senso che non puoi garantire il logout con un'applicazione web, in cui essenzialmente scarichi un programma client e poi fai richieste intermittenti per i dati sul server.

Ci sono alcune soluzioni a questo problema che conosco

1: definisci 'disconnesso' come si verifica automaticamente dopo un periodo di inattività

Potrebbe non essere la cosa migliore per te con periodi così brevi di 30 minuti come un utente che si blocca in un computer utilizzerà il timeout inattività + tempo effettivo

2: usa javascript per eseguire costantemente il polling sul server "Sono connesso!" puoi migliorarlo con websocket o polling lungo

Questo ti dà più risoluzione temporale di 1 ma al costo di elaborare costantemente i messaggi

Per il tuo caso specifico, penso che tu debba solo definire il "tempo usato" nei tuoi termini di servizio per tenere conto della possibilità di crash che impiegano un po 'più di tempo.

O il cliente perde qualche minuto perché include il periodo di inattività, oppure può raggirarti per qualche minuto perché misura l'ultima volta che sei sicuro di aver effettuato l'accesso piuttosto che quando presumi che sono disconnessi.

score 0 · Answer 3

Poiché gli utenti saranno in qualche modo autenticati durante l'utilizzo, potresti "segnalare" lo stato degli account di prova e tenere traccia della loro attività:

Utente A accede.
L'utente A esegue un'azione contro il servizio
Viene tracciata una combinazione dell'ID utente + timestamp
Controlla il più recente timestamp associato allo stesso ID utente
SE il controllo passa (il più recente e quello corrente sono compresi nell'intervallo consentito), eseguire l'azione richiesta
ELSE puoi rifiutare la richiesta (la tua "finestra" di prova è scaduta).

Questo può essere più utile e coprire i piani di abbonamento e simili, serve solo una manciata di bandiere facilmente gestibili. È anche a prova di manomissione in una certa misura, dal momento che è tutto sul lato server (non sto considerando l'account hackerato, ma questo è un altro problema).

Questo approccio inizierebbe "il conteggio" quando gli utenti eseguono la prima richiesta. Se vuoi considerare l'intervallo di inizio al momento della registrazione, puoi semplicemente "tracciare" un'azione falsa per fornirti un timestamp da confrontare.

score -1 · Answer 4

Suppongo che con questo numero di utenti non si tratti di hosting ma di server dedicati in cui è possibile installare tutto il necessario per il servizio. Se è giusto, il mio suggerimento è di utilizzare alcuni archivi esterni come Redis, dove il token di accesso (o altro identificatore utente passato da client a server) sarà la chiave e il valore è tutti i dati che vuoi sapere sull'utente, compreso il tempo rimasto in demo .

Ogni volta che la richiesta viene ricevuta dall'utente, è possibile aggiornare il tempo trascorso in Redis senza inserire dati indesiderati nel database e sovraccaricarlo con le richieste. E il profitto addizionale è che puoi impostare quando il record Redis sarà terminato, potrebbe essere fatto automaticamente da Redis se non aggiorni la data di fine del record.

In questo caso gli utenti potrebbero avere un limite di tempo per utilizzare la loro demo e non è necessario fare nulla per implementarlo.