Complesso sistema di gestione delle conoscenze con CRM .. scritto internamente

1

Abbiamo tutti sentito parlare di forza vendita e sugarcrm e di sistemi come questo. Sfortunatamente sul mio posto di lavoro ci è stato chiesto di scrivere un sistema simile (piuttosto che una licenza o un acquisto). Fondamentalmente il database è abbastanza grande. Pensa a moduli come: Gruppi aziendali, clienti, programmi, progetti, sottoprogetti e gestione dei problemi. In termini semplici, un gruppo aziendale ha uno o più clienti. Un programma ha uno o più progetti. Un progetto ha uno o più sottoprogetti. E un problema può essere creato su molti sottoprogetti.

Ovviamente il sistema è un po 'più complesso ma, invece di elencare ogni singolo modulo, ritengo sia meglio mantenerlo semplice. In ogni caso, il sistema nel suo stato attuale ha solo due risorse su cui lavorare (fondamentalmente dobbiamo fare tutto: CSS, database, jquery, asp.net e C #). Abbiamo iniziato bene definendo le pagine del master e del footer dell'interfaccia utente in modo tale che possiamo riutilizzarle in tutte le nostre pagine.

Ora arriva la parte difficile. Il sistema avrà circa 4k utenti finali con il 5-10% di utenti concorrenti. Ci stiamo chiedendo se ha senso memorizzare nella cache i dati del nostro database (per esempio 5-10 minuti) piuttosto che colpire continuamente il nostro database. Il motivo è che alcune di queste pagine potrebbero avere 5-10 filtri di ricerca associati alla pagina. Immagina ogni volta che viene effettuata una selezione da una casella di ricerca quanti colpi del database. Anche alcuni di questi campi di ricerca sono in cascata, quindi selezionando ad esempio un menu a discesa iniziale è possibile sovrapporre diverse caselle a discesa sotto di essi.

È sbagliato memorizzare nella cache perché non trovo troppi articoli sul fatto che sia una buona idea o meno. Ricorda che il sistema è simile a un sistema CRM in cui gestiamo i nostri vari clienti, progetti, sottoprogetti, problemi, ecc.

    
posta JonH 10.11.2013 - 06:54
fonte

1 risposta

4

Il caching di alcuni tipi può avere un senso, ma 500 utenti simultanei sono generalmente molto al di sotto del punto in cui avresti bisogno di considerarlo. 1-2 server di qualità aziendale in grado di gestire migliaia di utenti simultanei, anche con un utilizzo piuttosto pesante, se implementato in modo corretto.

È buona norma eseguire la pianificazione della capacità (ecco un esempio Link Server ), ma il caching del database è probabile che sia il punto 5 dell'ottimizzazione (al più presto) , con il caching a livello di applicazione che è qualcosa di più simile al punto 10 - preso se non si è ancora in grado di tenere il passo con la domanda, che non dovrebbe mai verificarsi con numeri simultanei di 1000 lt. A meno che non ti siano consegnate alcune apparecchiature server davvero poco potenti, non dovrebbe essere nulla di cui ti devi preoccupare.

Inoltre, ci sono molti tipi di memorizzazione nella cache, e con tutti i meravigliosi strumenti disponibili manualmente il caching dei dati nell'applicazione - specialmente su un'applicazione basata sui dati come il CRM - è probabilmente il tipo meno utile. Vai con quelli che puoi semplicemente "accendere" e modificare prima, quando trovi una necessità.

Quando e se viene visualizzato un problema di prestazioni, profilo per determinare l'origine dei problemi e adattarlo nel modo in cui influisce meno sullo sviluppo complessivo.

Per quanto riguarda il problema di base del caching, quando è necessario possono essere le api ginocchia. Nel modo più semplice, la maggior parte dei moderni sistemi di database ha facilmente implementato (o automatico) il caching delle query, che può essere un ottimo modo per alleggerire il carico del server, specialmente se si dispone di query elaborate e complesse e centinaia di migliaia di record (o più).

Il caching più aggressivo può essere ... impegnativo e dispendioso in termini di tempo, se non si è già un DBWizard.

    
risposta data 10.11.2013 - 07:58
fonte

Leggi altre domande sui tag