Creazione di un servizio per l'esecuzione di logica / query e aggiornamento di una tabella rispetto all'esecuzione di logica / query sugli aggiornamenti del client

Question

Creazione di un servizio per l'esecuzione di logica / query e aggiornamento di una tabella rispetto all'esecuzione di logica / query sugli aggiornamenti del client

#1 da (1 voti)

3

Non sono sicuro se questa è una cosa. Mi dispiace per il titolo ambiguo - non ero proprio sicuro di come spiegarlo. Fondamentalmente ho una pagina web ASP.NET che esegue due query SQL e fa un po 'di logica per produrre una pagina di stato per il nostro reparto di consegna. Si aggiorna / aggiorna ogni 30 secondi, pertanto il database viene interrogato due volte su ogni aggiornamento del client. Bene, sempre più persone usano questa applicazione quindi ci sono sempre più richieste / minuto. Inoltre, è in esecuzione contro il nostro database principale e posso vederlo causare rallentamenti man mano che vengono create più app web personalizzate.

Quello che sto considerando è creare un'applicazione console e eseguirla come un servizio su un server separato che esegue query / logic ogni 10 secondi (meno della quantità di aggiornamenti eseguiti da più client). Il servizio aggiornerà una tabella che è separata dal nostro database principale. Quindi il client dovrà solo leggere quella tabella e formattare l'output invece di fare la logica principale.

Pensieri? Altre idee?

Modifica: tempi di esecuzione (fino a 30 volte / minuto):

(1605 row(s) affected)
   SQL Server Execution Times:
   CPU time = 1123 ms,  elapsed time = 1199 ms.
(78 row(s) affected)
   SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 4 ms.

Succedono anche nel database principale che centinaia usano durante il giorno. Non c'è stato un rallentamento significativo, ma sto cercando di essere a prova di futuro. Anche se l'ho rallentato molto quando inviavo ~ 300 query al minuto una volta per il test. "Mi dispiace!"

c# sql asp.net efficiency

posta justiceorjustus 01.06.2016 - 15:19

fonte

1 risposta

Leggi altre domande sui tag c# sql asp.net efficiency

IoC, Unity: creazione di un componente con parametri concreti aggiuntivi Richiesta di memorizzazione nella cache per l'applicazione Symfony 3 con 1 milione di combinazioni di parametri di query

score 1 · Answer 1

Quanto lavoro è necessario per ottenere i dati da visualizzare? Se si tratta di una query abbastanza semplice, ripeterla ogni volta potrebbe essere un po 'più di lavoro che eseguirla una volta, salvando i risultati da qualche altra parte nel DB e quindi disegnando da lì.

Tutti gli utenti vedono gli stessi dati? Voglio dire, ci sono dei parametri su questo schermo, o il display è lo stesso per tutti? Se ci sono opzioni disponibili, allora dovresti memorizzare più di un set di dati, meno utenti userebbero ogni set e ogni vantaggio diminuirà.

Se le prestazioni sono davvero un problema, è possibile memorizzare i risultati della query in memoria anziché sul DB. In asp.net c'è una cosa chiamata "dati dell'applicazione", dati condivisi da tutti gli utenti dell'applicazione. È possibile creare un oggetto per contenere i dati, stamparli e memorizzarli nei dati dell'applicazione. Poi, quando la pagina ne ha bisogno, controlla se c'è qualcosa lì e se il timestamp indica che è ancora fresco. In tal caso, utilizzare il valore dai dati dell'applicazione. Altrimenti, esegui la query e crea l'oggetto.

Ho fatto qualcosa di simile in una mia app: leggiamo un sacco di dati dal DB che cambiano molto raramente, come una volta ogni poche settimane, ma sono accessibili a migliaia di utenti al giorno. Quindi l'ho letto dal DB e lo ho memorizzato nella cache. Nel mio caso, non utilizzo un timestamp, ma piuttosto l'applicazione che aggiorna i dati invia un messaggio all'applicazione che lo mostra dicendogli di svuotare la cache quando i dati vengono aggiornati, ma un'idea simile.

Il codice sarebbe qualcosa di simile (non ho fatto C # in un momento - scusami se non ho la sintassi abbastanza corretta):

StatusData sd=Application("StatusData");
if (sd==null || sd.timestamp < now().AddSeconds(-10)) {
  sd=new StatusData();
  sd.timestamp=now();
  Application("StatusData")=sd;
}
... whether the IF was true or false, you now have a valid StatusData object ...

(Si noti che questo codice è potenzialmente difettoso in quanto se un utente colpisce questa logica e inizia a costruire un nuovo oggetto StatusData, e prima che venga eseguito un altro utente, questa logica verrà creata, ne verrà creata un'altra. non inserisce un nuovo oggetto StatusData nei dati dell'applicazione fino a quando non viene compilato correttamente, ma potrebbe esserci qualche spreco di duplicazione. Puoi batterlo creando un Mutex o varie altre tecniche per forzarlo su un singolo thread, non volevo entrare in un altro livello di complessità, che sia importante dipende da quanto è probabile che ciò accada.)

Tutto ciò presuppone, naturalmente, che il lavoro richiesto per eseguire la query per creare la pagina di stato sia significativo e si verifichi abbastanza spesso per essere rilevante.