Best practice per lo sviluppo di soluzioni > Best practice per le applicazioni a disponibilità elevata
Best practice per le applicazioni a disponibilità elevata
Se si scrivono JavaScript in modo corretto e si riducono i round trip a ThingWorx Platform, si ottiene sempre un miglioramento delle prestazioni. Per supportare la modalità cluster a disponibilità elevata in ThingWorx 9, sono stati modificati l'archiviazione e l'utilizzo del modello ed è stato implementato un meccanismo di stato condiviso per mantenere i dati sincronizzati tra i server. Queste modifiche hanno un impatto sulle prestazioni di alcune API, poiché lavorano di più per recuperare le stesse informazioni. È possibile che il codice che precedentemente non era stato ottimizzato per le prestazioni sia molto più lento in ThingWorx 9 e potrebbe essere lentissimo in un ambiente clustering.
Le informazioni sul modello non sono più memorizzate nell'oggetto. Per ottenere informazioni sul modello, il sistema esplora ogni volta l'albero del modello. Questo influisce su tutte le API che recuperano informazioni sull'oggetto.
Tutti gli stati del servizio JavaScript sono ora memorizzati in un livello della cache.
In modalità a server singolo si tratta di una cache in memoria che è abbastanza veloce ma ha un maggiore sovraccarico rispetto alla semplice memorizzazione nell'oggetto. Nell'esecuzione in modalità cluster la cache viene distribuita e ogni chiamata esegue un round trip a un host remoto. Ciò può aggiungere latenza alle chiamate e non è facilmente controllabile.
Il livello della cache può essere locale o remoto. Il nuovo sistema unidirezionale crea oggetti proxy dall'oggetto JavaScript all'oggetto originale. Pertanto, ogni modifica apportata all'oggetto JavaScript attiva un aggiornamento completo della proprietà nell'oggetto originale. Le modifiche apportate all'oggetto originale non si riflettono nell'oggetto JavaScript.
Ogni oggetto deve essere trattato come oggetto remoto. Con gli oggetti remoti, per rimuovere la latenza, è importante effettuare il minor numero possibile di chiamate nello spazio remoto. Lo stesso approccio deve essere utilizzato quando si chiamano le API sul server: è bene effettuare meno chiamate possibile.
È stato utile?