Problemi di prestazioni con oggetti strutturati di grandi dimensioni in .Net Application Cache?

3

La mia app ASP.NET offre molte discussioni di gruppo separate e complete. Come attualmente scritto, i dati globali attivi sono conservati in un oggetto GroupDiscussionObject complesso che è archiviato in System.Web.HttpContext.Current.Application sotto una chiave specifica per quella discussione, cioè

Dim thisDiscussionID as integer = 99
Dim thisDiscussionObject as GroupDiscussionObject
Dim workHT as HashTable
Dim AC = System.Web.HttpContext.Current.Application

thisDiscussionObject = AC("GroupDiscussionObject_" & Trim(Str(thisDiscussionID)))
workHT = thisDicussionObject.ThatHashTable

Il tipo GroupDiscussionObject è un oggetto di classe con molte variabili pubbliche, variabili private accessibili tramite proprietà pubbliche, hashtables, code e così via.

Gli elementi GroupDiscussionObjects vengono inizialmente caricati dal disco e gli aggiornamenti agli elementi figlio vengono sincronizzati con il disco (e controllati tramite una coda per eliminare i conflitti), laddove necessario.

Ora funziona tutto bene. Tuttavia, in un miglioramento, aggiungo sempre più variabili a GroupDiscussionObject.

La mia domanda è, nel quadro di questo approccio, che ci saranno problemi di prestazioni con avere tutti i dati per una discussione dietro una chiave di Application Cache, piuttosto che scomporla e avere gli elementi parziali sotto le chiavi della cache?

Upate: per rifinire la mia domanda, avere tutti i dati sotto una chiave di cache dell'applicazione crea un qualche collo di bottiglia, invece di averlo diviso tra molte chiavi? O è solo un altro indirizzo di memoria e soggetto agli stessi vincoli di accesso di qualsiasi indirizzo di memoria?

    
posta wayfarer 10.11.2016 - 23:29
fonte

2 risposte

3

La memoria non è il problema principale. La concorrenza è il problema principale.

Lo stato dell'applicazione è libero da thread. Per salvare qualcosa, devi utilizzare Applicazione. bloccare . Solo un thread può avere il blocco alla volta. E intendo UNO, in tutto il sito. Non uno per utente, non uno per discussione, non uno per variabile applicativa. Uno, punto.

Se hai qualcosa di diverso da un numero molto basso di utenti o discussioni, troverai che molti dei tuoi thread stanno bloccando, in attesa dello sblocco dello stato dell'applicazione. In questo modo puoi esaurire molto rapidamente i thread di lavoro. A quel punto il tuo sito web inizierà a lanciare 500.13 Server Too Busy errori e nessuno potrà accedere a nessuna delle pagine.

La mia raccomandazione è di archiviare le discussioni in un database. I database sono progettati per gestire la concorrenza molto più facilmente. Le variabili dell'applicazione non sono intese per questo tipo di utilizzo.

    
risposta data 14.03.2017 - 08:24
fonte
0

La risposta sta nel numero concreto di conversazioni, dimensioni degli oggetti di conversazione, dimensioni delle estensioni, requisiti di prestazioni AND di memoria disponibili per questo sistema.

Anche se non aggiungi dati aggiuntivi ma aumenti il numero di conversazioni (il sistema diventa più affollato) potresti riscontrare problemi.

A proposito. Potrebbe essere sufficiente aggiornare la memoria del server prima di cambiare il modo in cui sono archiviate le conversazioni.

    
risposta data 10.11.2016 - 23:58
fonte

Leggi altre domande sui tag