Ridimensiona le app .NET in Microsoft Azure con la cache distribuita
Webinar registrato
Di Ron Hussain
Scopri quali sono i colli di bottiglia della scalabilità per le tue app .NET in Microsoft Azure e come puoi migliorarne la scalabilità con la memorizzazione nella cache distribuita.
Questo webinar riguarda:
- Panoramica rapida dei colli di bottiglia delle prestazioni nelle applicazioni .NET
- Che cos'è la cache distribuita e perché è la risposta in Azure?
- In quale punto della tua applicazione puoi utilizzare la cache distribuita?
- Quali sono alcune caratteristiche importanti in una cache distribuita?
- Alcuni esempi pratici sull'uso di una cache distribuita in Azure
Grazie mille per esserti unito. Lascia che ti informi rapidamente sul webinar. Prima di tutto, mi chiamo Ron Hussain. Sono uno degli esperti tecnici di Alachisoft e sarò il tuo presentatore per il webinar di oggi. Tratterò tutti i dettagli tecnici di cui hai bisogno per scalare le tue applicazioni .NET in Microsoft Azure con l'aiuto di un sistema di cache distribuita in memoria e userò NCache come prodotto di esempio per questo. Questo è il nostro prodotto principale per la memorizzazione nella cache distribuita. Siamo l'orgoglioso creatore di NCache e lo userò come prodotto di esempio. La maggior parte di questo webinar sarà di solo ascolto, il che significa che parlerò per la maggior parte ma tu puoi sempre partecipare. Puoi fare tutte le domande di cui hai bisogno. Sul lato destro dello schermo, c'è questa scheda Domande e risposte. Se espandi la scheda delle domande, puoi pubblicare tutte le domande di cui hai bisogno e, come ho detto, lo terrò d'occhio e risponderò a tutte le domande che pubblicheresti in questa finestra. Quindi, solo per motivi di conferma, se puoi confermare utilizzando la stessa scheda domande e risposte, conferma se riesci a vedere il mio schermo e se riesci a sentirmi bene. Posso iniziare rapidamente. Bene. Vedo già alcune domande in corso di pubblicazione. Quindi, grazie mille per la conferma.
Cominciamo con questo. Ciao a tutti, mi chiamo Ron Hussain come ho detto, sono uno degli esperti tecnici presso Alachisoft e sarò il tuo presentatore per il webinar di oggi. L'argomento che abbiamo scelto oggi è la scalabilità orizzontale delle applicazioni .NET in Microsoft Azure con l'aiuto di un sistema di cache distribuita in memoria. In Alachisoft abbiamo vari prodotti e quello più popolare è NCache, che è un sistema di memorizzazione nella cache distribuito in memoria per applicazioni .NET e Java. NCache sarà il prodotto principale, che userò come esempio ma mi atterrò alle basi di Microsoft Azure. Come usare NCache (Un sistema di memorizzazione nella cache distribuito) in Microsoft Azure e trarne vantaggio in termini di scalabilità, prestazioni dell'applicazione e affidabilità complessiva del sistema nella tua architettura. Quindi, dal momento che hai confermato che puoi vedere il mio schermo, fammi iniziare con questo.
Che cos'è la scalabilità?
Bene! prima di passare effettivamente all'argomento vero e proprio. Parlerò di alcuni concetti di base e inizierò con cos'è la scalabilità? La scalabilità è la capacità di aumentare il carico transazionale sulle applicazioni e allo stesso tempo di non rallentare le applicazioni. Ad esempio, a questo punto, se stai gestendo 1,000 richieste, se il carico dell'applicazione aumenta, più utenti accedi e quindi inizia a utilizzare le tue applicazioni più pesantemente del carico, ad esempio, aumenta da 1,000 a 10,000 richieste al secondo. Ora vuoi far fronte a quel carico maggiore, vuoi gestire quel carico maggiore e, allo stesso tempo, non vuoi rallentare le prestazioni delle tue richieste individuali. Non dovrebbe accadere in modo tale che una richiesta sia in attesa di essere completata e una richiesta sia in fase di completamento, altre richieste lo stiano aspettando. Tali richieste dovrebbero essere gestite esattamente nello stesso periodo di tempo impiegato in precedenza. Ma allo stesso tempo, vuoi quella scalabilità, quella capacità in cui potresti gestire sempre più richieste caricando 10,000 richieste al secondo o 20,000 richieste al secondo. Quindi, senza perdere le prestazioni, se hai la possibilità di aumentare il carico transazionale sulle tue applicazioni, questo è ciò che chiameremmo scalabilità. Ed è su questo che ci concentreremo oggi.
Che cos'è la scalabilità lineare?
C'è un termine associato chiamato scalabilità illimitata. È scalabilità lineare. La scalabilità lineare sta avendo una crescita lineare nella capacità di letture e scritture al secondo. Ad esempio, se aggiungi più server. Quindi, ora che aggiungi un server, hai una certa capacità di gestire le richieste di operazioni di lettura e scrittura. Cosa succede se aggiungi un altro server e poi aggiungi altri server? La possibilità di aggiungere più server e aggiungendo più server, aumenta i numeri di scalabilità, ottieni sempre più capacità gestite dall'architettura dell'applicazione, questo è ciò che chiamiamo scalabilità lineare.
Quali applicazioni necessitano di scalabilità?
Adesso! La prossima domanda sarebbe, che tipo di applicazioni richiederebbe scalabilità. La risposta è molto semplice. Qualsiasi applicazione che potrebbe dover gestire milioni di richieste degli utenti. Se ha a che fare con un enorme carico di transazioni. In genere, abbiamo applicazioni ASP.NET. Se ci sono front-end, ad esempio, un'applicazione di e-commerce, forse un'applicazione di prenotazione aerea, qualsiasi cosa che sia rivolta al pubblico ma abbia molto traffico, quell'applicazione è il principale candidato per la scalabilità.
Quindi, potremmo avere WCF per i servizi Web .NET e l'architettura orientata ai servizi. Potrebbe essere di nuovo attivo o potrebbe essere servizi Web front-end, magari consumati dalle tue applicazioni Web o da applicazioni interne che potresti avere. Quelli potrebbero dover elaborare un'enorme quantità di richieste, un'enorme quantità di dati deve essere recuperata e consegnata ai programmi del chiamante. Quindi, anche questo tipo di applicazioni necessita di scalabilità. E poi potresti voler mettere una sorta di infrastruttura, in grado di gestire la quantità di carico della richiesta.
Poi, abbiamo le applicazioni per big data. Questa è una parola d'ordine comune in questi giorni. Molte applicazioni, molte architetture si stanno muovendo verso di essa, dove potresti dover elaborare enormi quantità di dati per la distribuzione su moduli diversi, processi diversi ma verso la fine, avresti a che fare con molti dati, molti richieste, al fine di elaborare questo.
E poi abbiamo ottime applicazioni informatiche, in cui potresti dover elaborare un'enorme quantità di calcoli attraverso la distribuzione su più server economici, queste sono le applicazioni. Quindi, in generale, qualsiasi applicazione .NET o applicazione Java, che potrebbe dover gestire un milione di richieste dagli utenti o dai programmi di back-end, sono i candidati principali che devono avere scalabilità nell'architettura.
E una volta ci concentreremo su alcuni di questi, passeremo anche ai nostri casi d'uso. E ragazzi siamo solo all'inizio di questo webinar, per quelli di voi che si sono appena iscritti, tratterò solo alcuni concetti di base in termini di cache distribuita. Parlerò di diversi problemi che dovresti affrontare e quindi di soluzioni e parlerò anche dell'implementazione di una cache distribuita, ad esempio NCache in Microsoft Azure. Quindi, se ci sono domande, non esitare a digitare nella scheda domande e risposte. E puoi sempre darmi anche il tuo feedback. Se vuoi partecipare, puoi utilizzare di nuovo la stessa scheda di domande e risposte.
Qual è il problema della scalabilità?
Ora la prossima cosa, una volta definito che abbiamo, che cos'è la scalabilità? Che cos'è la scalabilità lineare e che tipo di applicazioni richiedono scalabilità? Il prossimo e poi il punto più importante di questo webinar, che tipo di applicazioni o che tipo di problemi di scalabilità dovrebbero affrontare le tue applicazioni? Dov'è esattamente il problema della scalabilità?
Ora, l'architettura dell'applicazione potrebbe essere un'applicazione ASP.NET o un servizio WCF, questi si espandono molto bene e si ridimensionano già in modo lineare. Puoi mettere in primo piano un sistema di bilanciamento del carico e puoi semplicemente aggiungere sempre più server app o server Web, server front-end Web e ottieni già una scalabilità lineare dalla tua architettura. Quindi, non ci sono problemi laggiù. Il vero problema per quanto riguarda l'archiviazione dei dati, questi server di applicazioni o server Web, parlerebbero sempre con alcune origini dati di back-end, come il servizio di stato dei database o potrebbe essere qualsiasi file system di back-end o origine di dati legacy per quella materia . Che non può gestire un enorme carico di transazioni e non hai la possibilità di aggiungere sempre più server qui. E questo diagramma lo spiega bene.
Laddove abbiamo lo storage dei dati ha un collo di bottiglia nella scalabilità. Abbiamo l'esempio di ASP.NET WCF proprio qui, ma puoi aggiungere tutti i server che vuoi, inizi con due server, se il tuo carico aumenta puoi aggiungere un altro server, mettere un sistema di bilanciamento del carico in primo piano e quindi utilizzare uniformemente tutto il risorse su questo livello. Quindi, non ci sono problemi. Ma queste caselle applicative o server web front-end parlerebbero sempre con alcune origini dati back-end. E questa è una distribuzione tipica, in cui abbiamo server di database, che non sono così veloci da avviare, e quindi hanno problemi di scalabilità. Sarebbero soffocati dall'enorme carico di transazioni e quindi, in alcuni casi, sono anche un singolo punto di errore. Ma soprattutto, questi server di database in qualsiasi architettura applicativa rappresentano una minaccia molto seria e questo è un collo di bottiglia della scalabilità. Quindi, perderesti tutta la scalabilità che ottieni su questo livello una volta indirizzate tutte le tue richieste ad alcuni server di database. E lo stesso vale per lo stato della sessione ASP.NET. Se usi SQL Server o un server di stato della sessione per quello è perché rimane su quello. Sarà sempre un unico server che ospita tutti i dati della sessione e la sessione è un tipo di dati molto transazionale e quindi è necessaria un'origine dati molto scalabile per gestire tali richieste. Quindi, questa è la sfida principale che stiamo cercando di affrontare con l'aiuto di un sistema di memorizzazione nella cache distribuito.
La soluzione: cache distribuita in memoria
La soluzione è molto semplice, come ho detto, potresti usare un sistema scalabile di cache distribuita in memoria. Come NCache per gestire tutti i problemi di cui abbiamo appena parlato associati alle origini dati per quanto riguarda la scalabilità.
La prossima cosa che farò rapidamente è parlare di alcune nozioni di base del sistema di memorizzazione nella cache distribuita in memoria come NCache. Ci sono alcune caratteristiche importanti, in cui potresti trovare NCache e mi aspetto che questo faccia parte della maggior parte dei nostri sistemi di memorizzazione nella cache distribuita in memoria, che sono disponibili. Quindi, a questo proposito, così NCache se devo definire, quale sarebbe un sistema di memorizzazione nella cache in memoria?
Clustering dinamico
È un cluster di più server cache economici, che sono uniti tra loro, puoi estrarre la loro memoria e la capacità della CPU. Quindi, sono uniti in una capacità e stai estraendo la loro memoria e le risorse della CPU. Quindi, fisicamente potrebbero essere più server, che non sono così costosi una volta che un Web, una semplice configurazione del server Web farebbe, è qualcosa che potresti usare per la memorizzazione nella cache, e quindi quei server si uniscono e la capacità logica formale. Quindi, dal punto di vista dell'applicazione, stai solo utilizzando una cache distribuita ma fisicamente potrebbe avere più server che lavorano dietro le quinte, sfruttando tutta la potenza di calcolo e la memoria per creare questa cache distribuita in memoria. Quindi, questa è la prima e più importante caratteristica che non è questo singolo server. Avrebbe più server che lavorano in combinazione tra loro. Quindi, siamo già avanti rispetto al database, dove avremmo solo un server che ospita tutti i dati e gestisce tutte le richieste.
Coerenza dei dati
La caratteristica successiva e questa riguarda la coerenza dei dati poiché abbiamo a che fare con più server dietro le quinte, la prossima domanda sarebbe, come gestiremmo gli aggiornamenti. Ad esempio, gli stessi dati vengono aggiornati su uno o due server o se sono presenti repliche o più copie di dati su server diversi. Pertanto, indipendentemente dalla topologia utilizzata, i dati devono essere aggiornati in modo coerente. Quindi, una volta aggiornato qualcosa su qualsiasi server di cache, tutti gli aggiornamenti dovrebbero essere visibili a tutti i server di cache sulla cache distribuita. E a proposito, sto usando alcuni visibili, non sto usando il termine replica. La replica è un'altra caratteristica. Quindi, per visibile intendo che, ad esempio, ottieni un handle di richiesta dal server uno, i dati vengono aggiornati. Se la richiesta successiva va al server due, se avevi gli stessi dati anche sul server due, dovresti ottenere il valore aggiornato e non il valore non aggiornato dalla cache distribuita.
Quindi, questa è una caratteristica molto importante in termini di cache distribuita, in cui tutti gli aggiornamenti dei dati devono essere applicati in modo coerente su tutti i server di memorizzazione nella cache. E questa dovrebbe essere responsabilità della cache distribuita, non della tua applicazione. L'architettura dovrebbe supportare questo modello.
Scalabilità lineare
La prossima cosa, che è in linea con il nostro argomento oggi, è come scalare linearmente. Pertanto, la cache distribuita dovrebbe scalare linearmente verso l'esterno per la capacità transazionale e di memoria. Dovrebbe darti via, dove puoi aggiungere sempre più server di memorizzazione nella cache e poiché avevi più server di memorizzazione nella cache, ottieni una scalabilità lineare. Ti avevo mostrato un grafico prima. Quindi, questo è ciò a cui mi riferisco qui, dove aggiungi sempre più server, dovresti aumentare la capacità di quanti richiedenti puoi gestire e, allo stesso tempo, quanti dati, quanti dati possono essere archiviati nel cache distribuita linearmente. Quindi, questa è una caratteristica molto importante, che ti offre una scalabilità lineare dalla cache distribuita e che rende l'architettura generale dell'applicazione molto scalabile.
Replica dei dati per l'affidabilità
Quarta caratteristica importante. Questa è l'opzione uno, puoi scegliere una topologia, che supporta anche la replica. Hai una cache distribuita, che replica i dati tra i server per affidabilità. Se un server si interrompe o è necessario portarlo offline per la manutenzione, non dovresti preoccuparti della perdita di dati o dell'interruzione dell'applicazione. Quindi, queste sono alcune caratteristiche importanti della cache distribuita. Li tratterò in modo sempre più dettagliato nelle prossime diapositive e poi parleremo anche della distribuzione specifica di Azure di una cache distribuita. Come utilizzare la cache distribuita in Microsoft Azure? Per favore fatemi sapere se ci sono domande finora. Si prega di utilizzare la scheda Domande e risposte. Vedo alcune mani alzate in generale, il go-to-meeting ha questo problema, dove mostra molte mani alzate, ma per favore fatemi sapere se ci sono effettivamente delle domande. Si prega di digitare nella scheda domande e risposte e sarò molto felice di rispondere a quelle per te. Penso che dovremmo continuare.
Ecco la tipica distribuzione di una cache distribuita. Questa è una distribuzione generale, non è specifica per Microsoft Azure.
NCache Distribuzione in Microsoft Azure
Passerò alla distribuzione di NCache in Microsoft Azure subito dopo. Quindi, in genere potrebbe essere on-premise o potrebbe essere cloud, non ci sono molte cose che cambieranno per quanto riguarda la distribuzione di NCache va. Questo è il modo in cui normalmente verresti distribuito NCache, dove avresti un livello dedicato di memorizzazione nella cache.
Potrebbero essere scatole fisiche in locale, potrebbero essere VM scatole ospitate o anche queste potrebbero essere vere macchine virtuali cloud, in cui è sufficiente ottenere una VM dal cloud e quindi utilizzarla per la memorizzazione nella cache. Puoi formulare una cache su caselle di cache dedicate separate, quella è consigliata. Una piattaforma preferita è a 64 bit e l'unico prerequisito per NCache è .NET 4.0. E poi le tue applicazioni, anche queste potrebbero essere on-premise o ospitate. Questi potrebbero essere distribuiti direttamente sui server in IIS o potrebbero essere ruoli Web o di lavoro, per quanto riguarda Microsoft Azure. Tutti possono connettersi a questo livello di memorizzazione nella cache per i requisiti dei dati. Potresti avere un'installazione separata per questi, un livello separato per questi, o avrai anche tutto sullo stesso livello. Entrambi i modelli sono supportati. Ma una volta che ti presenti NCache nell'architettura dell'applicazione, una volta distribuito per la memorizzazione nella cache degli oggetti o per la memorizzazione nella cache della sessione, tratterò NCache casi d'uso una volta che ci spostiamo verso i casi d'uso.
Una volta che inizi a usare NCache, salva i tuoi viaggi costosi attraverso il retro e i database. E poi ti offre una piattaforma molto scalabile proprio qui, dove puoi aggiungere tutti i server che vuoi e puoi scalare. Ora confronta questo con il diagramma che ti ho mostrato prima.
Avevi una piattaforma molto scalabile proprio qui, ma questa era la principale fonte di contesa. La principale fonte di collo di bottiglia della scalabilità. Ora, se lo confronti, ora hai una piattaforma molto scalabile tra il livello dell'applicazione e il database. Questa è una piattaforma molto scalabile e di nuovo ora hai una fonte di dati in termini di cache distribuita, che è ancora una volta molto scalabile. Puoi aggiungere tutti i server che vuoi. Se il tuo carico aumenta, non devi preoccuparti che le origini dati back-end vengano soffocate in quel momento. Puoi aggiungere tutti i server che vuoi e puoi aumentare linearmente la tua capacità di gestione delle richieste NCache. Fammi sapere se ci sono domande sull'architettura di distribuzione di NCache ma nel complesso è molto semplice.
Ora, la prossima cosa è come distribuire NCache in Microsoft Azure. Quindi, userò il nostro sito web. Userò un diagramma da lì, quindi per favore abbi pazienza. La distribuzione in Microsoft Azure non è molto diversa da quella che abbiamo in locale.
Quindi, prima di tutto, è consigliabile che questa sia la distribuzione di base, in cui hai tutto sulla stessa rete virtuale di Microsoft Azure. Ad esempio, crei una rete virtuale e poi disponi di macchine virtuali Microsoft Azure, la distribuzione lato server sarà sempre su macchine virtuali. Quindi, questo è il modello per cui abbiamo scelto NCache in Microsoft Azure. Crei una VM o scegliendo la stessa rete virtuale crei tutte le tue distribuzioni di VM. Ad esempio, puoi iniziare con tre VMS come mostrato qui e poi puoi aggiungere tutte le macchine virtuali necessarie a questo livello di memorizzazione nella cache. Preferibilmente vogliamo che anche le tue applicazioni si trovino sulla stessa rete virtuale di Azure. Quindi, tutto può far parte della stessa rete virtuale in cui ottieni la maggior parte delle prestazioni e quindi i vantaggi della stabilità NCache. Quando non ci sono requisiti rigidi su questo, potresti sempre avere applicazioni distribuite su VM diverse.
Quindi, sulla base di questo modello, l'architettura dell'applicazione può essere sulla VM stessa, il che significa che l'applicazione può essere distribuita direttamente su IIS che gestisci tu stesso e poi, prendine il pieno carico o potrebbe essere il ruolo Web di Azure o i ruoli di lavoro entrambi i modelli sono supportati dal lato dell'applicazione ma NCache la distribuzione lato server sarà sempre nelle macchine virtuali. Quindi, è così che dovresti candidarti NCache e in realtà te lo mostrerò una volta che passeremo alla nostra parte pratica.
Un altro tipo di distribuzione è che potresti avere una rete virtuale di Azure specifica per il tuo NCache VM server, in cui tutti i tuoi server fanno parte della stessa rete virtuale. Preferibilmente anche la stessa sottorete. E poi le tue applicazioni potrebbero trovarsi anche su una rete virtuale separata. In tal caso, dovresti avere una sorta di porte inoltrate su NCache rete virtuale. Ad esempio, le porte private vengono mappate sulla porta pubblica qui e quindi le tue applicazioni utilizzano questa porta pubblica per connettersi effettivamente NCache. Potrebbe essere necessario eseguire alcune configurazioni extra qui, ma abbiamo un documento di aiuto dettagliato disponibile per questo, ma funziona senza problemi. È possibile che questo server di rete virtuale acceda ai server di memorizzazione nella cache da un'altra rete virtuale. E potresti persino avere le applicazioni cache-to-cache con l'aiuto della stessa funzione.
Quindi, questo è un altro tipo di distribuzione, ma l'approccio preferito, quello consigliato, è che tutti i server cache e i server delle applicazioni siano distribuiti sulla stessa rete virtuale di Microsoft Azure. Questo è il momento in cui otterresti i maggiori vantaggi NCache. Per favore fatemi sapere se ci sono domande.
Abbiamo anche una guida alla distribuzione di Azure disponibile sul nostro sito Web, se potessi portarti al supporto. In realtà, lasciami andare alla documentazione qui. Nella documentazione abbiamo una guida specifica, una guida all'implementazione che copre tutti questi dettagli in modo molto dettagliato.
Bene. C'è una domanda. Com'è NCache diversa da Redis? Bene. L'agenda di oggi è più di utilizzo NCache o usando un sistema di memorizzazione nella cache distribuito in Microsoft Azure. Abbiamo un webinar separato Redis NCache. Dove si parla di diverse funzionalità disponibili in NCache e poi non ne fa parte Redis. Per una rapida risposta su questo, ti consiglio di andare alla nostra pagina di confronto proprio qui, e quindi hai a Redis NCache. Puoi registrarti rapidamente per questo e quindi dovresti essere in grado di vedere tutte le funzionalità, funzionalità per funzionalità di confronto NCache Redis. E in effetti, abbiamo anche un webinar proprio per questo, che è un webinar sul nostro canale YouTube. Quindi, se accedi solo a YouTube, cerca Alachisoft e poi sotto Alachisoft ci saranno molti video e uno di quei video lo avrebbe fatto Redis fonti NCache titolo. C'è un webinar separato su questo. Spero che questo risponda alla tua domanda. Ci sono più domande su questo. Bene. tornando a, dal momento che abbiamo coperto la distribuzione, per favore fatemi sapere se ci sono domande relative alla distribuzione e sarò molto felice di rispondere a queste domande per voi.
Usi comuni della cache distribuita
La prossima cosa è come usare la cache distribuita? Quali sono le aree comuni, in cui useresti un sistema di cache distribuita come NCache? Ho appena elencato tre di quelli più comuni, ma questi potrebbero essere specifici del settore, questo potrebbe essere specifico per le tue esigenze, casi d'uso, potrebbero essere modi diversi in cui potresti utilizzare NCache. Ma principalmente questi sono divisi in queste tre categorie.
Memorizzazione nella cache dei dati dell'applicazione
La prima categoria è la memorizzazione nella cache dei dati dell'applicazione. Puoi usare un sistema di cache distribuito come NCache come memorizzazione nella cache dei dati dell'applicazione. Tutto ciò che in precedenza era presente nel database e le tue applicazioni andavano nei database, ora puoi inserirlo NCache. E puoi ottenere una cache in memoria più veloce rispetto al database per accedere a tutti i dati che avevi in precedenza nel database. Quindi, migliori le prestazioni delle tue applicazioni e, soprattutto, riduci linearmente le dimensioni laddove il database non riesce a farlo. Puoi scalare ad alcuni livelli drammatici. Puoi gestire un'enorme quantità di carichi di transazioni e puoi aggiungere tutti i server che desideri. E questo comporta NCache API. Potresti semplicemente aggiungere dati in una coppia chiave-valore. La chiave è una stringa e il valore è un oggetto consentito .NET, puoi memorizzare nella cache i tuoi oggetti di dominio, raccolte, set di dati, immagini, qualsiasi tipo di dato relativo all'applicazione può essere memorizzato nella cache utilizzando il nostro modello di memorizzazione nella cache degli oggetti. E poi questo ti darebbe alcuni enormi vantaggi in termini di funzionalità che stiamo offrendo sul lato della memorizzazione nella cache dei dati.
Cache affidabile e scalabile per dati specifici ASP.NET
Il prossimo caso d'uso riguarda le applicazioni specifiche di ASP.NET. Ad esempio, ASP.NET e c'è un modo molto semplice per iniziare NCache. Abbiamo tre opzioni qui.
Archiviazione sessioni ASP.NET
Abbiamo l'archiviazione dello stato della sessione ASP.NET. È possibile utilizzarlo nei moduli Web MVC o ASP.NET o qualsiasi applicazione Web ASP.NET può utilizzarlo. Senza alcuna modifica al codice, è possibile archiviare i dati della sessione in una cache distribuita. E a differenza del database o del server di stato, non sarà un singolo server. Potrebbe avere più server. Quindi, è molto scalabile, è molto affidabile perché abbiamo i dati di sessione replicati su tutti i server e anche da esso ottieni prestazioni molto buone perché è in memoria. E tutto senza modifiche al codice. E con NCache, abbiamo anche una distribuzione di sessioni multisito. Potresti avere due data center, sincronizzare le tue sessioni senza modifiche al codice. Quindi, queste sono alcune funzionalità estese che puoi utilizzare. Al di fuori del nostro supporto per lo stato della sessione per le applicazioni ASP.NET e ciò non richiede modifiche al codice.
ASP.NET View State Caching
La prossima caratteristica su questo è ASP.NET view state, anche questa non è un'opzione di modifica del codice. Per quelli di voi che vogliono sapere, qual è lo stato di visualizzazione? Lo stato di visualizzazione è la gestione dello stato lato client. Ad esempio, se gli stati di visualizzazione vengono applicati solo ai moduli Web, l'architettura MVC non ha più il tuo stato. Per i moduli web ASP.NET, tutti i controlli tutti i pulsanti o tutti i widget che hai sulle tue pagine, quelli contribuiscono a creare lo stato di visualizzazione, che viene inviato al browser in relazione alla nostra risposta, lo stato di visualizzazione è unito a il pacchetto di risposta e quindi rispedito al browser. Sul lato browser, non viene mai utilizzato. Rimane semplicemente lì e quando si esegue il postback, lo stato di visualizzazione arriva insieme al pacchetto di richiesta sul server ed è allora che si utilizza effettivamente lo stato di visualizzazione. Quindi, viene sempre rispedito al browser come parte della risposta, riportato al server come parte della richiesta, quindi i tuoi pacchetti di richiesta e risposta diventano più pesanti. Non è mai realmente utilizzato nel lato browser. Viene sempre utilizzato sul lato server. Assorbe gran parte della tua larghezza di banda in particolare sotto un enorme carico di transazioni.
Quindi, abbiamo molti problemi ad esso associati in termini di prestazioni e in termini di utilizzo della larghezza di banda. Insieme a NCache puoi memorizzare i tuoi stati di visualizzazione sul lato server, puoi tenerlo sul lato server NCache, invia un piccolo token fittizio al browser. Quindi, i tuoi stati di visualizzazione diventano di dimensioni inferiori, migliorano i costi di utilizzo della larghezza di banda. Risparmi molta larghezza di banda su questo. E allo stesso tempo, i pacchetti più piccoli sono più facili da elaborare. La tua richiesta e risposta il pacchetto diventa più piccolo e quindi ciò contribuisce anche a migliorare le prestazioni della tua applicazione. Quindi, una volta che inizi a utilizzare il nostro, ottieni prestazioni e riduzione dei costi di utilizzo della larghezza di banda ASP.NET view state fornitore. E questa è anche un'opzione senza modifica del codice per NCache. E puoi usarlo molto facilmente in Microsoft Azure.
Cache di output ASP.NET
La terza caratteristica importante qui è il provider di caching dell'output ASP.NET, per ASP.NET MVC e per le web farm. Se hai contenuto abbastanza statico all'interno della tua applicazione su quattro pagine diverse per richieste diverse, invece di eseguire nuovamente il rendering e rieseguire tutte quelle richieste, anche se ottieni gli stessi dati in risposta a tali richieste, ha senso memorizzarli nella cache e quindi utilizzare l'output memorizzato nella cache per le richieste successive. Se ricevi di nuovo la stessa richiesta, non eseguire il drill e quindi estrarre semplicemente il contenuto della cache NCache direttamente. Quindi, ti consentiamo di archiviare l'intero output della pagina ASP.NET in NCache e da utilizzare per richieste successive. E anche questa non è una modifica del codice perché consente di risparmiare molta potenza di elaborazione, molto tempo di esecuzione e molti vantaggi in termini di prestazioni si ottengono con l'aiuto del nostro provider di cache di output ASP.NET.
Quindi, questi sono tre aspetti importanti con cui puoi iniziare rapidamente. Queste sono tutte opzioni di modifica del codice. Potrebbero essere necessari 10-15 minuti per la configurazione e quindi potresti iniziare a vedere tutti i vantaggi di cui abbiamo appena discusso. E in Microsoft Azure, non c'è davvero alcun sostituto per questi. Finiresti per utilizzare le opzioni predefinite, il che significa che mantieni tutto nel processore in questo database. E abbiamo già parlato di quali sono i problemi associati a questi. Quindi, ti consiglio vivamente di dare un'occhiata a queste funzionalità per iniziare e quindi, una volta che il tuo caso d'uso progredisce, potresti iniziare a utilizzare la memorizzazione nella cache dei dati dell'applicazione insieme. Il terzo importante caso d'uso di NCache, Sto dedicando molto tempo a questi in modo da poter trasmettere il significato dell'utilizzo di una cache distribuita nelle architetture delle applicazioni. Per favore fatemi sapere se ci sono domande a questo punto finora.
Condivisione dei dati di runtime scalabile tramite messaggistica
Ora terzo caso d'uso importante di NCache è che potresti usarlo in modo scalabile e molto affidabile, in modo scalabile per la piattaforma di condivisione dei dati di runtime con l'aiuto del nostro supporto di messaggistica. Simile alla coda MSN e al servizio di messaggistica Java. Abbiamo anche una piattaforma di messaggistica. Dal momento che hai già dei dati nella cache. Ad esempio, alcuni dati vengono aggiunti, hai dei cataloghi di prodotti, un prodotto viene aggiunto, aggiornato o rimosso dalla cache, desideri ricevere una notifica in base al fatto che potresti avere il nostro sistema di propagazione delle notifiche di eventi, che può propagarsi e quindi notificare utilizzare se i dati cambiano nella cache. Quindi, ci sono messaggi a livello di dati, a cui puoi collegarti e iniziare a utilizzare quei messaggi secondo necessità, e poi potrebbero esserci anche alcuni messaggi di applicazioni personalizzate, in cui un'applicazione può comunicare con altre applicazioni con l'aiuto della nostra piattaforma di messaggistica. Quindi, è una condivisione dei dati molto potente perché un'applicazione può condividere i dati con un'altra e quindi potrebbe anche essere la condivisione di messaggi tra diverse applicazioni che utilizzano lo stesso sistema di memorizzazione nella cache distribuito. Quindi, questa è una funzionalità molto potente, molte persone non la conoscono ma è molto potente in termini di capacità che offre.
Per favore, fammi sapere che ci sono domande. Questi sono alcuni casi d'uso importanti di NCache, che tratterò rapidamente. Una volta che si prevede di utilizzare una cache distribuita in Microsoft Azure, c'è un concetto molto importante, molto importante la scena da realizzare direi.
Quali dati memorizzare nella cache?
Che tipo di dati devono essere memorizzati nella cache? Ora la cache distribuita è solitamente per i dati più facilmente accessibili, dove hai più letture e scritture e quindi i dati vengono letti ancora e ancora per le richieste successive. Ho classificato i dati in due diverse categorie. Potresti avere dati permanenti, che di solito esistono nel database, potrebbero cambiare ma la frequenza delle modifiche non è eccezionale, ecco perché li ho ulteriormente suddivisi in dati di riferimento e transazionali. Ma abbiamo dati permanenti e poi abbiamo dati transitori. I dati permanenti sono quelli che esistono realmente nel database ed è molto importante memorizzarli nella cache. In modo da ridurre i viaggi costosi ai database di back-end.
E poi, abbiamo dati transitori che sono dati temporanei, che sono di breve durata, possono essere validi solo per l'ambito dell'utente corrente o solo per l'ambito del ciclo dell'applicazione corrente per quella materia. Potrebbero essere configurazioni utente, impostazioni utente, sessioni ASP.NET utente, visualizzazione della cache di output dello stato. Di solito non appartiene al database, ma ha senso tenerlo nella cache a seconda di quanto tempo ne hai bisogno e quante volte ne hai bisogno una volta memorizzato nella cache. Quindi questi dati possono essere ulteriormente suddivisi in altre categorie. Ad esempio, dove i dati vengono principalmente letti, più letture che scritture o un numero uguale di letture o scritture. Quindi, il riferimento è più letture che scritture e le transazioni sono letture oltre che scritture.
E poi, abbiamo dati transitori che sono dati temporanei, che sono di breve durata, possono essere validi solo per l'ambito dell'utente corrente o solo per l'ambito del ciclo dell'applicazione corrente per quella materia. Potrebbero essere configurazioni utente, impostazioni utente, sessioni ASP.NET utente, visualizzazione della cache di output dello stato. Di solito non appartiene al database, ma ha senso tenerlo nella cache a seconda di quanto tempo ne hai bisogno e quante volte ne hai bisogno una volta memorizzato nella cache. Quindi questi dati possono essere ulteriormente suddivisi in altre categorie. Ad esempio, dove i dati vengono principalmente letti, più letture che scritture o un numero uguale di letture o scritture. Quindi, il riferimento è più letture che scritture e le transazioni sono letture oltre che scritture. Quindi, potresti considerare di memorizzare nella cache tutti i tuoi dati di riferimento, di solito sono i tuoi dati permanenti che appartengono al database. Prova a portarlo nella cache distribuita e mettilo nella cache il più possibile, in modo da non tornare ai database. E ottieni la maggior parte dei vantaggi in termini di prestazioni che sono necessari da questo. E poi, dovresti considerare di memorizzare nella cache alcuni dei tuoi dati di transazione, come lo stato della sessione ASP.NET, lo stato di visualizzazione e la memorizzazione nella cache di output perché non vuoi perdere le prestazioni durante il recupero di questi dati transitori o dati transazionali dalle origini dati back-end . A seconda del numero di utenti, se hai milioni di utenti che hanno effettuato l'accesso, pensa a uno scenario in cui vai al database due volte per utente, potresti vedere quanto tempo impiegheresti per ottenere quei dati da una fonte più lenta , dall'origine dati di back-end. Ottenere dalla cache e per questo dovresti assolutamente considerare di memorizzarlo nella cache distribuita.
Panoramica dell'API di memorizzazione nella cache
Ecco come appare la memorizzazione nella cache. È una tabella hash come Interface. Abbiamo una chiave basata su stringa e quindi abbiamo un oggetto come valore. L'oggetto potrebbe essere qualsiasi oggetto parametro .NET. Potresti avere tutto ciò che è consentito da .NET, archiviato come cache degli oggetti. Considerando che la chiave di stringa, potresti trovare una formazione di chiavi significativa. Ad esempio, tutti i dipendenti con ID dipendente 1000, un dipendente con ID dipendente 1000 possono essere archiviati con questa chiave proprio qui. Tutti gli ordini di quel dipendente possono avere questa chiave, dove hai gli ordini dei dipendenti e quindi l'ID di quel dipendente. Potrebbe esserci anche un parametro di runtime. E poi, potresti avere una domanda da parte dei dipendenti. Ad esempio, si memorizza nella cache la query responsabile e l'argomento è stato trovare il codice dipendenti in base a un titolo uguale a manager. Quindi, potresti ottenere una raccolta archiviata come un singolo oggetto nella cache. Quindi, questo è solo un esempio di come la chiave della cache può essere formulata, ma puoi trovare qualsiasi tecnica di base della chiave secondo necessità. È solo un esempio, usa ciò che ha più senso per la tua applicazione.
Ragazzi, fatemi sapere se ci sono domande? Non vedo molte domande oggi. Per favore fatemi sapere se ci sono domande finora. Inoltre, fammi sapere se sto andando troppo lento o troppo veloce su una porzione specifica, in modo da poter mantenere un ritmo. Potresti anche darmi il tuo feedback utilizzando la stessa scheda di risposta alla domanda e dedicherò più tempo anche a una funzione specifica.
Ragazzi, fatemi sapere se ci sono domande? Non vedo molte domande oggi. Per favore fatemi sapere se ci sono domande finora. Inoltre, fammi sapere se sto andando troppo lento o troppo veloce su una porzione specifica, in modo da poter mantenere un ritmo. Potresti anche darmi il tuo feedback utilizzando la stessa scheda di risposta alla domanda e dedicherò più tempo anche a una funzione specifica. Bene. C'è una domanda, che dire dei dati spaziali? Bene. Possiamo interrogare anche quel tipo di dati? Sì. Assolutamente, abbiamo un supporto per le query molto forte, questo oggetto può essere di qualsiasi tipo. Quindi, lascia che ti dica che questo copre tutti i tipi di dati che prevedi di memorizzare nella cache. Ora i dati possono essere interrogati in base a diversi argomenti, in base a diversi parametri che trasmetti. In effetti, abbiamo un linguaggio di query a oggetti molto potente, che ho pianificato proprio qui. Quindi, abbiamo query parallele con l'aiuto del linguaggio di query a oggetti. E potresti eseguire query molto flessibili con l'aiuto del nostro linguaggio di query a oggetti. Ad esempio, c'è una tua domanda. Se vogliamo avvicinare tutte le sedi alla posizione attuale, ad esempio, sì. puoi. Ad esempio, hai tutti i dati propagati nella cache. Hai tutti i menu, memorizzati nella cache separatamente come oggetti separati. Destra? E poi potresti avere i loro attributi di oggetto, che possono anche darti informazioni sulla posizione. Quindi, puoi eseguire una query che dice seleziona tutte le sedi, dove la sede è quella posizione uguale a questa. Quindi, se gli attributi dell'oggetto hanno queste informazioni, puoi ottenere tutti i record corrispondenti dalla cache di distribuzione. Ecco perché un modo per farlo.
Il secondo modo per farlo è trasmettere le informazioni spaziali o tutte le informazioni su cui è necessario interrogare come parte di quegli oggetti sotto forma di tag. Memorizzi i tuoi oggetti e poi memorizzi parole chiave aggiuntive, che sono proprio qui come tag. Questi sono identificatori che identificano, che creano raccolte logiche nella cache. Quindi, potresti semplicemente usare l'API basata su tag, dove dici prendi per tag e quindi ottieni l'intera raccolta che corrisponde ai risultati o puoi persino eseguire una query in cui dici di selezionare luoghi in cui tag è uguale a e tag è essenzialmente una posizione che hai già aggiunto, dove tag equivale a una posizione XYZ e otterresti tutti i record corrispondenti in base a quel criterio. Quindi, questi sono i due modi in cui puoi gestire le query, in cui puoi aggiungere tag sopra i tuoi oggetti o semplicemente fare affidamento sugli attributi dell'oggetto reale. E quindi esegui SQL come query di ricerca su di essi. Spero che risponda alle tue domande. Per favore fatemi sapere se ci sono altre domande su questo.
C'è un'altra domanda. Posso impostare la scadenza di determinati elementi memorizzati nella cache in base agli eventi? Ad esempio, un record è cache e scade se viene aggiornato nel database. Assolutamente! abbiamo due tipi di scadenze. Abbiamo, il tempo è scadenza e ci sono due tipi di scadenze, quindi se il tempo scade è possibile far scadere gli elementi e questa scadenza può anche essere basata sulla dipendenza dal database. Ad esempio, qualcosa cambia nel database e questo risponderebbe alla tua domanda. Ad esempio, un record cambia nel database in cui avevi un record nella cache, che dipendeva da quello, non appena quel record del database cambia, il database può inviare una notifica di evento e l'elemento nella cache può essere rimosso automaticamente dalla parte anteriore da la cache. Quindi, può essere scaduto non appena scade nel database. Quindi, questo è esattamente ciò che offriamo in termini di dipendenze di database relazionali e la dipendenza SQL lo coprirebbe. Apprezzerei se potessimo passare rapidamente attraverso un'altra diapositiva e poi passare alla nostra porzione di memorizzazione nella cache degli oggetti e questo dovrebbe rispondere a molte domande. Per favore fatemi sapere, se ci sono altre domande altrimenti, riprenderò la presentazione dallo stesso bit.
C'è una domanda. Puoi mostrare un esempio persiste e recuperare i dati dalla cache di esempio? Ti consiglierei rapidamente di guardare i nostri campioni, che vengono e iniziano con NCache e quelli sono disponibili anche sul nostro sito web. Quindi, se ti porto rapidamente ai nostri campioni, ecco qua e NCache. Posso guidarti verso il campione, che gestisce esattamente questo. Quindi, abbiamo la sincronizzazione del database e quindi abbiamo le dipendenze. Quindi, questi dovrebbero. Gli handle di dipendenza, la dipendenza SQL e la sincronizzazione del database sono un altro tipo di esempio, che aiuta a gestire lo scenario con l'aiuto di richieste di lettura e scrittura. Spero che questo risponda alla tua domanda. Grazie mille.
C'è un'altra domanda. Possiamo interrogarlo per ordinare i dati? Sì. abbiamo raggruppato per un ordine di supporto. Quindi, potresti usare quegli attributi insieme alla query. Bravissimi ragazzi! Grazie mille per aver inviato queste domande. Questi li apprezzo molto. Per favore, falli venire. Dal momento che, questo è stato pianificato verso la fine della nostra presentazione e stavo già per coprirli, ma è bello avere tutte le domande in arrivo, quindi per favore continua a farle. Grazie mille.
NCache Architettura
Ora la prossima cosa, andrò rapidamente all'architettura. La cache distribuita è molto elastica in termini di aggiunta o rimozione di server. Puoi aggiungere tutti i server che vuoi. Puoi portare offline qualsiasi server. Si basa sul clustering della cache basato su TCP. È il nostro implementato un protocollo di domande. Non utilizziamo cluster di terze parti o Windows. Anche in Microsoft Azure faresti affidamento solo su un indirizzo IP e una porta e NCache si occuperebbe del resto. È un'architettura peer-to-peer al 100%. Non esiste un singolo punto di errore, puoi portare offline qualsiasi server e aggiungere nuovi server e client non avrebbe alcun impatto. Puoi applicare dinamicamente le modifiche a un cluster di cache in esecuzione. Quindi queste configurazioni sono dinamiche in modo tale che questi server siano in costante comunicazione con i client. Qualsiasi server che si interrompe o viene aggiunto un nuovo server viene immediatamente notificato. C'è una mappa in memoria, che viene propagata al client e che viene aggiornata ogni volta che c'è una modifica nella cache. Pertanto, queste mappe delle informazioni sull'appartenenza al cluster e la mappa delle informazioni sulla topologia della cache vengono aggiornate non appena si verifica una modifica nel cluster della cache. Quindi, c'è un supporto per il failover della connessione, oltre al fatto che se un server si interrompe, i client lo automatizzano e i server lo fanno uscire e i nodi sopravvissuti diventano automaticamente disponibili e i client si connettono automaticamente. Quindi, in breve, non avrebbe alcuna perdita di dati o tempi di inattività delle applicazioni per quanto riguarda le applicazioni client e quindi ci sono quattro diverse topologie tra cui è possibile scegliere.
Topologie di memorizzazione nella cache
La modalità attiva e passiva o la modalità master o slave verrebbe determinata in base alle topologie di memorizzazione nella cache. Come ho detto, è un'architettura peer-to-peer. Quindi, ogni server partecipa in modo indipendente al cluster di cache. Quindi, non c'è dipendenza o non c'è il concetto di host principale come avevi AppFabric oppure non c'è attivo o passivo o in termini di configurazione o in termini di gestione del cluster. Ogni server è indipendente al 100% in termini di configurazione, in termini di posizione nel cluster di cache. Ma ci sono diverse topologie di memorizzazione nella cache e abbiamo attivo e passivo, ma quelli sono basati sui dati nella cache. Se i dati sono disponibili attivamente, li chiamiamo attivi e se i dati sono solo backup, i client non sono collegati ad essi, li chiamiamo passivi. Ma questo server passivo viene nuovamente aggiunto alla cache nell'architettura peer-to-peer al 100%.
C'è una domanda. Esiste un SDK per piattaforme mobili, Android o iOS da utilizzare NCache nelle app mobili native? Al momento abbiamo .NET e l'API Java, stiamo lavorando su un'API riposante, quindi, se verrà rilasciata, sono abbastanza sicuro che saresti in grado di usarlo da app Android e iOS. Per favore, mandami un'e-mail su questo, mandami una richiesta in merito e lo presenterò all'ingegneria e ti risponderò rapidamente con le tempistiche anche su questo.
Ora abbiamo quattro diverse topologie di memorizzazione nella cache.
cache specchiata
Abbiamo rispecchiato, che è attivo/passivo. Passerò rapidamente in rassegna questi perché questo non è il nostro programma oggi. Voglio concentrarmi maggiormente sulla nostra parte pratica. Quindi, ti darò un'idea delle diverse topologie NCache Offerte. Abbiamo quattro diverse topologie. Mirrored Cache, è un attivo-passivo a due nodi. Hai tutti i client collegati attivi e poi abbiamo un server di backup proprio qui. Se attivo scende, i backup diventano automaticamente attivi. E questi client eseguono automaticamente il failover. Questo è consigliato per le configurazioni più piccole, molto buono per le letture, molto buono per il diritto ed è anche molto affidabile.
Cache replicata
Poi abbiamo Replicated, è un modello attivo-attivo. Quindi, entrambi i server sono attivi ma i client sono distribuiti. Quindi, se hai sei ruoli Web o ruoli di lavoro in Microsoft Azure, con bilanciamento del carico uniforme, alcuni si collegherebbero al server uno e altri al server due. E qui abbiamo un modello di sincronizzazione.
In mirroring avevamo la sincronizzazione, quindi anche le prestazioni di lettura sono state molto veloci. In replicato abbiamo sempre un modello di sincronizzazione. Quindi, abbiamo un'intera copia della cache su ciascun server e questi server hanno gli stessi dati e in modo sincronizzato tutti gli aggiornamenti vengono applicati su tutti i server. Ad esempio, aggiorni l'elemento del server numero due sul server uno, viene applicato sul server due in modo sincronizzato solo dopo che l'operazione viene completata. Ma le letture, che vengono applicate localmente sul server a cui è connesso il client. Quindi, le letture sono molto veloci, molto scalabili, le scritture sono molto coerenti, direi perché se cambi qualcosa qui avresti sempre quella modifica anche qui e solo quell'operazione verrebbe completata. Quindi, per una transazione di dati affidabile per gli aggiornamenti, per prestazioni superveloci questa è un'ottima topologia da avere, se perdi il server uno, questi client eseguirebbero il failover sul server due e se perdi il server due, questi client eseguirebbero il failover. Quindi, non c'è perdita di dati, nessun rimbalzo dell'applicazione.
Cache partizionata
Quindi abbiamo partizionato la cache, dove abbiamo partizionato i dati e quindi abbiamo partizionato con la replica. Quindi, abbiamo i dati partizionati, dove potresti avere due o più server secondo necessità e i dati vengono automaticamente divisi su tutti i server. Alcuni dati andrebbero al server uno e alcuni dati andrebbero al server due. Le mappe di distribuzione delle monete sono già a conoscenza, dove esistono dati nella cache, individueranno il server e userebbero quel server per leggere e scrivere dati. Più server significano più copie di lettura dalla cache, più scritture, più server da cui leggere i dati, più server su cui scrivere i dati. Quindi, questi server contribuiscono alle prestazioni complessive, alla scalabilità complessiva. Quindi, più server significano più scalabilità dalla cache. Partizionato non ha alcun backup.
Cache di replica partizione
Abbiamo partizioni con repliche, in cui è possibile eseguire il backup di ciascuna partizione su un altro server in una partizione di replica passiva. Ad esempio, quindi il backup di uno è sul server due e il backup del server due è sul server uno. Quindi, non c'è perdita di dati, se il server uno si interrompe o se è necessario portare il server offline. I backup vengono resi disponibili in una sola volta. E questo è anche scalabile in modo molto lineare, infatti, è la nostra topologia più scalabile in termini di numeri di prestazioni.
Lascia che ti mostri rapidamente alcuni numeri di riferimento per supportare questo. Per favore fatemi sapere se ci sono domande? Come ho detto, scorrerò rapidamente queste topologie per risparmiare tempo qui.
Ecco la cache con mirroring con due nodi. Replicato molto bene per le letture, le scritture non sono così scalabili, ma puoi vedere il punto qui perché ha la natura di sincronizzazione degli aggiornamenti e delle partizioni con le letture e la scalabilità delle scritture. Repliche partizionate con letture e scritture, questo ha anche backup in modo da ottenere backup insieme a prestazioni e scalabilità. E poi abbiamo anche partizionato le repliche con la replica di sincronizzazione.
Cache cliente
Ci sono anche alcune altre funzionalità, ad esempio, supportiamo anche la memorizzazione nella cache locale vicino al client senza modifiche al codice, puoi anche attivare la memorizzazione nella cache sul lato dell'applicazione. E questa cache sarebbe sincronizzata con la cache del server, consigliata principalmente per il tipo di dati di riferimento. Quindi, se hai più letture che scritture, potresti volerlo attivare e questo ti darebbe miglioramenti delle prestazioni super veloci oltre alla tua applicazione esistente. Salva i tuoi viaggi attraverso la rete in una cache distribuita. Questo sta già salvando i tuoi viaggi sul retro nei database, ma puoi anche salvare questo viaggio in cui devi attraversare la rete utilizzando una cache del client. Devi solo spegnerlo. E puoi persino farlo durante il processo alla tua applicazione per salvare ulteriormente la serializzazione e la comunicazione tra processi. E NCache gestisce tutta la sincronizzazione. Se qualcosa cambia qui, viene propagato qui così come in altre cache client e viceversa. È un'ottima caratteristica per iniziare. Ho già trattato i benchmark delle prestazioni.
Replica WAN della cache distribuita
Quindi abbiamo anche il supporto per la replica WAN in Microsoft Azure. Ad esempio, se hai due data center, uno a New York e l'altro forse in Europa, potresti anche trasferire i dati da un data center all'altro. Potresti avere un cluster di cache qui e con l'aiuto del nostro bridge, di cui viene anche eseguito il backup con i nodi attivo-passivo, puoi trasferire i dati al bridge e quindi il bridge può a sua volta trasferirli al sito di destinazione. Questo potrebbe essere attivo-passivo per lo scenario DR o potrebbe essere anche attivo-attivo.
BENE. C'è una domanda. Posso utilizzare la cache del client in un sistema disconnesso costituito da app mobili senza connettività di rete temporanea? Questa è un'ottima domanda. La domanda è che posso usare la cache del client in modalità disconnessa. Ne abbiamo parlato; questa era una richiesta di funzionalità da parte di uno dei clienti e poi ne abbiamo discusso a lungo. Quindi, c'è un requisito specifico che ti interessa. Abbiamo già dei piani, ne abbiamo già discusso e poiché abbiamo già ricevuto una richiesta simile a questa. Se potessi semplicemente inviarmi un'e-mail su questo, voglio che la cache del client venga utilizzata per il mio caso d'uso e voglio che venga utilizzata anche in modalità disconnessa. Sarò molto felice di trasmetterlo all'ingegneria perché ne stanno già discutendo e capita che lo forniscano. Grazie mille.
Bene. Aspetterò la tua email in questo caso. A questo punto, la cache del client cammina in combinazione con la cache del server. Se questo va giù nella cache del client poiché si sincronizza con una cache del server, quindi anche questo perderebbe tutti i dati. Ma stiamo pianificando di utilizzare una modalità disconnessa, in cui anche se la connessione al server si interrompe, la cache del client rimane attiva e accoda anche alcune operazioni da eseguire in una fase successiva.
Demo pratica
La prossima cosa, ti mostrerò rapidamente una demo pratica. Come funziona il prodotto reale? Abbiamo poco tempo a disposizione, credo che abbiamo dieci minuti. Quindi, ti fornirò rapidamente una panoramica di Azure. Ciò di cui hai essenzialmente bisogno per iniziare NCache è per il quale pianifichi la distribuzione NCache.
La prima cosa di cui hai bisogno è creare una rete virtuale di Azure. Vieni in Microsoft Azure, crea una rete virtuale. Potresti semplicemente usare la creazione rapida o la creazione personalizzata e quindi, ad esempio, se scelgo la creazione rapida, posso semplicemente dire NCache VM. Questa sarebbe una rete virtuale che userò per NCache e poi potrei semplicemente creare questa rete virtuale. Potresti semplicemente fornire dettagli specifici sulla rete virtuale, se necessario. Oppure potresti avere già una rete virtuale nel tuo ambiente che vorresti utilizzare NCache schieramenti. Quindi, questo è il nostro primo passo. Ho alcune reti virtuali che sono già state create. Quindi, posso semplicemente andare avanti e andare al passaggio successivo.
Il prossimo passo sarebbe creare NCache macchine virtuali. Hai solo bisogno di creare una macchina virtuale che può avere NCache preinstallato, potresti semplicemente installarlo NCache prendi la nostra immagine Microsoft Azure VM da Azure marketplace quello è per NCache professional ma se ti interessa NCache enterprise, potresti semplicemente utilizzare il server 2012 di immagini semplici. Installare NCache sopra di esso e quindi salva l'immagine per una fase successiva e quindi caricala, ogni volta che devi generare una nuova VM per NCache distribuzione del server. Quindi, dalla galleria, potrei semplicemente scegliere un'immagine, ad esempio il server 2012. Potrei scegliere il prossimo su questo solo dargli un nome. Ad esempio, demo 3. Sceglierò un livello di server e quindi potrei semplicemente inserire alcune informazioni secondo necessità.
Questi sono passaggi specifici di Azure. Quindi, sono abbastanza sicuro che saresti familiare con questo. La prossima cosa che è la più importante è se vuoi crearne uno nuovo cloud service oppure usa quello che c'è già. Ad esempio, se utilizzo il benchmark, rileverà automaticamente anche la rete virtuale. Ma potresti creare le tue VM per essere lì da sole cloud serviceanche per questo potresti scegliere di crearne uno nuovo cloud service. Ma consiglierei comunque di scegliere una rete virtuale per tutte le VM del server e quindi dovrebbe essere la stessa per tutte le VM del server per NCache. Quindi, per ottenere più prestazioni dal sistema per quanto riguarda la comunicazione da server a server. Quindi, sceglierò questo benchmark e, in base a quello, potrei scegliere il prossimo.
È possibile inserire alcuni dettagli specifici sulla rete, se necessario. Ma nel complesso, questo è tutto ciò di cui ho bisogno. Quindi, potrei solo... Ok. Il server cloud che ho scelto non supporta questo tipo di macchina virtuale. Quindi, devo solo scegliere di crearne uno nuovo cloud service con quello. Bene. Quindi, dirò solo che approva e il gioco è fatto. Quindi, ecco come andrebbe. Cancellerò solo questo. Ho già questi server qui e, in effetti, posso accedere rapidamente a pochi server, che ho già configurato. Quindi, per favore abbiate pazienza con me. Lascia che ti mostri come iniziare a creare una cache, configurarla e testarla rapidamente nel tuo ambiente. Abbiamo una decina di minuti. Quindi, voglio sfruttarlo appieno. E ragazzi, sentitevi liberi di postare tutte le domande di cui avete bisogno. Rispondo sempre alle domande mentre preparo l'ambiente.
Bene. Ho già questi server. Posso accedere rapidamente a questi. Li stiamo già usando per alcuni test, penso di aver incasinato la password proprio qui, per favore abbi pazienza. Ecco qua! BENE! ecco qua! allora ho quella Demo 2 proprio qui. Quindi, queste sono le mie due scatole, ecco qua. BENE! Quindi, ho queste due scatole già configurate che fanno parte della stessa rete virtuale in Microsoft Azure.
C'è una domanda. Ho bisogno di una macchina virtuale per forza o posso usare un server delle app di Azure? che dire del docker? Non abbiamo ancora alcun supporto per la finestra mobile. Posso verificare con l'ingegneria se stanno lavorando su uno. Per quanto riguarda il modello di server, per NCache è necessario disporre di una VM su Microsoft Azure. L'applicazione virtuale potrebbe essere un modello di servizio, potrebbe essere a cloud service, potrebbe essere un ruolo Web, potrebbe essere un ruolo di lavoro, potrebbe essere una vera macchina virtuale in cui è distribuita l'applicazione. Ma il NCache la parte del server deve essere una VM e, come ho detto, il modo più semplice sarebbe creare un'immagine VM preconfigurata di NCache. Tienilo nella galleria e quindi caricalo, quando devi generare una nuova istanza di esso. Puoi anche scegliere lo stesso per il ridimensionamento automatico, dove sono disponibili i modelli di VM, NCache installato attivato e configurato, generi semplicemente quelle nuove VM, quando il tuo nodo cresce fino a un certo limite.
C'è un'altra domanda. Potresti aver già menzionato la crittografia e la compressione per la riduzione dei dati in termini di utilizzo della larghezza di banda e credo che tu stia chiedendo informazioni sulla crittografia e la compressione. Sì! queste due funzionalità sono disponibili senza modifiche al codice. Puoi crittografare i tuoi dati per la trasmissione di dati sensibili, i dati possono essere crittografati e quindi anche i dati possono essere compressi. Quindi, questi ne fanno parte NCache sostegno. Grazie mille per aver posto queste domande. Per favore fatemi sapere se ci sono altre domande.
Creazione di un ambiente
Voglio mostrarti rapidamente il prodotto reale in azione. Quindi, la prossima cosa che devi fare è andare sul nostro sito Web e installare NCache o la versione cloud, che è proprio qui, che è cloud professionale, è disponibile in Microsoft Azure marketplace oppure scarica la normale Enterprise Edition e installala sulle tue VM Microsoft Azure. Ho già eseguito l'installazione Enterprise. Quindi, il passaggio uno è completo. Ora il secondo passaggio consiste nel creare una cache senza nome e per questo è possibile avviare un file NCache strumento di gestione che viene installato con NCache. Quindi, puoi semplicemente gestire tutto da uno dei VMS secondo necessità oppure puoi semplicemente gestirlo da un server separato che ha accesso sulla rete a questi server.
Crea una cache raggruppata
Il passaggio successivo consiste nel creare una cache denominata. Lo farò velocemente. Si chiama cache demo.
Questo è il nome che utilizzerai per tutte le tue applicazioni client per utilizzare questa cache. Potresti fare riferimento a questo nome per andare avanti e recuperare i dati dalla cache. Sceglierò la topologia della cache di replica partizionata perché questa è la più consigliata.
Sceglierò il prossimo su questo scegliere Async come opzione di replica perché è più veloce. Server 1 e guarda che utilizza l'IP privato dei server ed è per questo che ti ho consigliato di misurare la rete virtuale in termini di distribuzione da server a server. In modo che siano accessibili sugli IP interni e tu abbia una comunicazione molto veloce in corso tra i server.
La porta TCP per la comunicazione per impostazione predefinita Azure VMS ha il firewall aperto. Quindi, ti consiglierei di disattivarlo o almeno di dare un pugno NCache porte per la comunicazione sul firewall. E poi la dimensione della cache per server si basa sulla memoria che si basa sui dati, che prevedi di avere nella cache. Quindi, se hai bisogno di due giga di dimensione della cache, trova la giusta quantità di memoria specificata qui. Questo è solo un limite superiore, se la cache si riempie hai due opzioni, puoi rifiutare nuovi aggiornamenti il che significa che non è possibile aggiungere dati, otterresti un'eccezione o puoi attivare gli sfratti dove puoi semplicemente specificare una percentuale di sfratto e questi algoritmi possono controllare quanti elementi possono essere rimossi utilizzando questi algoritmi per fare spazio ai nuovi elementi. Quindi, se la tua cache si riempie, gli sfratti vengono attivati, alcuni elementi verranno automaticamente rimossi e potrai aggiungerne altri. Scelgo solo di finire con l'impostazione predefinita.
Quindi questo completa il nostro passaggio 2, in cui abbiamo configurato la cache nel riquadro di destra, ci sono tutte le impostazioni relative a questa cache. Il passaggio 3 consiste nell'aggiungere il nodo client, potrei semplicemente aggiungere la demo 3 ma poiché abbiamo solo due server e aggiungerò anche queste due caselle come client. Il passaggio 4 consiste nell'avviare e testare questo cluster di cache, per questo farò semplicemente clic con il pulsante destro del mouse e lo sceglierò e questo avvierà questa cache su tutto il mio server di memorizzazione nella cache e tra l'altro questi nodi client sono in realtà i miei ruoli Web o VM, dove la mia applicazione è distribuita.
Quindi, è proprio per questo che ti ho consigliato di mantenere tutto anche sulla stessa rete. Quindi, da cui potresti semplicemente gestirli NCache Gestore. E fai clic con il pulsante destro del mouse sulle statistiche per aprire i contatori perf-mon. La cache è stata avviata, alcune impostazioni sono disattivate e non possono essere modificate mentre la cache è in esecuzione, ma è comunque possibile modificare alcune impostazioni, ad esempio attivare la compressione, fare clic con il pulsante destro del mouse e scegliere le configurazioni di applicazione forzata. Ti chiederà prima di salvare il progetto. Quindi, lo farò e poi applicherò le configurazioni. Ecco qua.
Ora la cache è stata configurata, i client sono stati configurati. Abbiamo finito con tre passaggi, abbiamo installato NCache.
Simula lo stress e monitora le statistiche della cache
Abbiamo creato la cache, configurato i client, abbiamo finito dal punto di vista della configurazione, ma dobbiamo solo avviare ed eseguire questo cluster di cache e per questo userò solo uno strumento di stress test, che viene installato con NCache. Ed eseguilo sulla mia cache. In modo che potessi vedere anche qualche attività. Accederò anche alla mia seconda casella ed eseguirò anche questa applicazione basata su console. Quindi, quello e prima, eseguo la seconda istanza per guardare il contatore delle richieste al secondo. Abbiamo circa un migliaio di richieste al secondo generate da un'istanza dello strumento di stress test.
Sul secondo server, eseguirò questo. Quindi, abbiamo un po' più di carico e notiamo che il contatore delle richieste al secondo è quasi raddoppiato. Duemila richieste al secondo.
Anche se ho eseguito un'istanza da questa scatola, utilizzava ancora entrambi i server. Ho eseguito un'altra istanza in cui l'applicazione utilizzava entrambi i server in combinazione l'uno con l'altro e quindi abbiamo questo strumento di monitoraggio, che ci fornisce integrità, CPU, richiesta, dimensione, rete e matrici diverse dal lato server come con noi dal dalla parte del cliente.
E potresti anche creare le tue dashboard come ho fatto io qui. Mi dispiace ragazzi a causa dei limiti di tempo, dovevo essere un po' veloce per questo, ma questi sono stati cinque semplici passaggi per iniziare con NCache. La nostra cache è attiva e funzionante.
Usa il NCache Campioni
La prossima cosa è usare la cache nelle tue applicazioni effettive e per questo puoi semplicemente fare riferimento rapidamente al nostro NCache campioni. Ad esempio, se si desidera utilizzare le operazioni di base, questo è l'esempio. Se si desidera utilizzare lo stato della sessione, è possibile utilizzare questa applicazione dello stato della sessione ASP.NET. In questo elenco sono disponibili anche esempi di visualizzazione dello stato e di output nella cache. Quindi, approfittane e fai riferimento a questo per l'utilizzo NCache nelle applicazioni reali.
C'è una domanda. Posso configurare due livelli di cache, uno più grande uguale a 200 GB su uno stato persistente e uno più piccolo uguale a 1 GB più volatile in memoria, e avere una memoria di livello 1 sincronizzata con un sottoinsieme della memoria comunemente referenziata oggetti dalla cache di livello 2? Questo è possibile. Hai due domande. La prima domanda è se puoi creare due diverse cache con due diverse memorie. Sì. La maggior parte dei nostri clienti può creare una cache per i dati statici e un'altra per i dati dinamici. Quindi, è qualcosa che puoi fare e puoi creare configurazioni completamente diverse per queste due cache.
La prossima domanda è: è possibile sincronizzare i dati tra queste due cache? Sì. Puoi. C'è questa dipendenza dalla sincronizzazione della cache. Quella funzione è disponibile privatamente, ma posso condividere alcuni dettagli su come implementarli e potresti anche avere una dipendenza di sincronizzazione tra due diverse cache. Questa stessa funzionalità è ciò che utilizziamo le cache in natura ovunque abbiamo la cache del client, che è una cache ed è sincronizzata con la cache in cluster configurata su altri server. Quindi sì. Per rispondere alla tua domanda sì, puoi avere due diverse cache e potresti anche avere la sincronizzazione tra i dati in queste due cache.
Lo riassumerò rapidamente per te, ci sono molti aumenti della cache degli oggetti di cui puoi trarre vantaggio, questi fanno parte di NCache supporto per la memorizzazione nella cache degli oggetti e quindi abbiamo già trattato lo stato di visualizzazione della sessione ASP.NET. Ci sono anche alcune integrazioni di terze parti. Quindi, questa è essenzialmente la fine del nostro webinar. Mi scuso per aver eseguito alcuni bit a causa di vincoli di tempo, ma solo per ribadire, abbiamo coperto alcuni dettagli di base sui problemi di impossibilità, parlato della memorizzazione nella cache di distribuzione in memoria nella soluzione, parlato della distribuzione in Microsoft Azure, diversi casi d'uso , supporto per il clustering, supporto per la topologia all'interno NCache. Abbiamo avuto una demo pratica specifica su come iniziare in Microsoft Azure fino a NCache va.
Per favore fatemi sapere, come vi è piaciuta la presentazione? Come ti è piaciuto il prodotto in generale? Dammi il tuo feedback su questo. Ci sono alcune cose che puoi fare verso la fine. Puoi visitare il nostro sito Web e scaricare una versione di prova di 30 giorni di NCache. Potresti anche scegliere la nostra edizione cloud, che è NCache professional cloud, è disponibile su Microsoft Azure. Abbiamo anche un cliente. Quindi puoi anche usare le tue macchine virtuali di Azure per andare con il prodotto Enterprise Edition, se necessario. Puoi metterti in contatto con il nostro team di supporto andando alla pagina di supporto. Ci sono alcuni dettagli di contatto a cui puoi metterti in contatto con il supporto support@alachisoft.com.Puoi richiedere una demo del prodotto secondo necessità e puoi anche metterti in contatto con il nostro team di vendita per informazioni sui prezzi. Quindi, siamo già al traguardo di un'ora, quindi penso che sia ora di salutarci. Per favore fatemi sapere se ci sono domande anche dopo questa demo. Potete mettervi in contatto via e-mail o tramite telefono e sarò molto felice di vedere tutte le vostre domande. Grazie mille ragazzi. È stato un piacere presentare NCache webinar oggi. Per favore, fammi sapere come ti è piaciuto il prodotto, come ti è piaciuta la presentazione e possiamo sempre prenderlo da lì. Grazie mille per il vostro tempo, a tutti.