2012-09-28 17 views
8

Sto eseguendo un test in cui sto confrontando il tempo di recupero b/w appfabric e SQL Server 2008 e sembra che l'appFabric esegua 4 volte più lentamente di SQL Server.Appfabric Cache sta eseguendo 4x più lentamente di SQL Server 2008 ??

Ho una configurazione di SQL Server 2008 che contiene solo una tabella con 4 colonne (tutte nvarchar). Il tavolo ha 6000 righe. Inserisco la stessa riga (come oggetto serializzabile CLR) nella cache di appfabric. Sto facendo girare un ciclo per recuperare i dati x volte.

Ecco il codice

public class AppFabricCache 
{ 
readonly DataCache myDefaultCache; 

public AppFabricCache() 
{ 
//------------------------- 
// Configure Cache Client 
//------------------------- 

//Define Array for 1 Cache Host 
var servers = new List<DataCacheServerEndpoint>(1); 

//Specify Cache Host Details 
// Parameter 1 = host name 
// Parameter 2 = cache port number 
servers.Add(new DataCacheServerEndpoint(@"localhost", 22233)); 

//Create cache configuration 
var configuration = new DataCacheFactoryConfiguration(); 

//Set the cache host(s) 
configuration.Servers = servers; 

//Set default properties for local cache (local cache disabled) 
configuration.LocalCacheProperties = new DataCacheLocalCacheProperties(); 

//Disable exception messages since this sample works on a cache aside 
DataCacheClientLogManager.ChangeLogLevel(System.Diagnostics.TraceLevel.Off); 

//Pass configuration settings to cacheFactory constructor 
DataCacheFactory myCacheFactory = new DataCacheFactory(configuration); 

//Get reference to named cache called "default" 
myDefaultCache = myCacheFactory.GetCache("default"); 
} 

public bool TryGetCachedObject(string key, out object value) 
{ 
value = myDefaultCache.Get(key); 
bool result = value != null; 
return result; 
} 

public void PutItemIntoCache(string key, object value) 
{ 
myDefaultCache.Put(key, value, TimeSpan.FromDays(365)); 
} 

} 

Ed ecco il ciclo per recuperare i dati dalla cache

public double RunReadStressTest(int numberOfIterations, out int recordReadCount) 
{ 
recordReadCount = 0; 
Stopwatch sw = Stopwatch.StartNew(); 
for (int i = 0; i < numberOfIterations; i++) 
{ 
for (int j = 1; j <= 6000; j++) 
{ 
string posId = "PosId-" + j; 
try 
{ 
object value; 
if (TryGetCachedObject(posId, out value)) 
recordReadCount++; 
} 
catch (Exception e) 
{ 
Trace.WriteLine("AS%% - Exception - " + e.Message); 
} 
} 
} 
sw.Stop(); 
return sw.ElapsedMilliseconds; 
} 
} 

Ho esattamente la stessa logica per recuperare i dati da SQL Server. Si crea una

sqlCommand = 'Select * from TableName where posId = 'someId'' 

ecco i risultati ...

SQL Server 2008 R2 Reading-1(ms) Reading-2(ms) Reading-3(ms) Average Time in Seconds 
Iteration Count = 5 2528    2649   2665     2.614 
Iteration Count = 10 5280    5445   5343     5.356 
Iteration Count = 15 7978    8370   7800     8.049333333 
Iteration Count = 20 9277    9643   10220    9.713333333 

AppFabric     Reading-1   Reading-2 Reading-3 Average Time in Seconds 
Iteration Count = 5  10301   10160   10186    10.21566667 
Iteration Count = 10  20130   20191   20650    20.32366667 
Iteration Count = 15  30747   30571   30647    30.655 
Iteration Count = 20  40448   40541   40503    40.49733333 

mi manca qualcosa qui? Perché è così lento?

risposta

0

Penso che il test sia parziale e i risultati non sono ottimali.

A proposito di cache distribuita

  • cache locale: avete disabilitato local cache funzione. Gli oggetti cache vengono sempre recuperati dal server; il trasferimento di rete e la deserializzazione hanno un costo.
  • BulkGet: BulkGet migliora le prestazioni quando viene utilizzato con oggetti di piccole dimensioni, ad esempio, quando si recuperano molti oggetti con dimensioni da 1 a 5 KB o inferiori.
  • Nessuna compressione dati: nessuna compressione tra AppFabric e Cache Client. Controllare this.

Informazioni sul test di

Un'altra cosa importante è che il tuo non stanno testando la stessa cosa: da un lato si prova SELECT * e e l'altro lato si prova N x ottenere l'articolo.

+1

Non penso che tu abbia già usato la cache in precedenza. Solo conoscere alcune cose non è abbastanza. >> Se abilito la cache locale, sarebbe un test scorretto. >> Bulk get - avrei potuto fare lo stesso anche per il server SQL e sono abbastanza sicuro che sarebbe molto veloce. Sql Server non odia nulla di più del semplice recupero di una singola riga. >> Perché dovrei voler abilitare la compressione solo per i record di 6k. ciascuno con solo 4 spazi per le stringhe. – user1707312

+0

@ user1707312 Non capisco il tuo commento. potresti spiegare ? Non sono un maestro di AppFabric. L'ho usato da un anno. Se hai già usato d-cache, dovresti anche sapere che l'uso di d-cache non ha come obiettivo il miglioramento delle prestazioni, ma la scalabilità . "Load Testing" in un ciclo for su un singolo client con una singola tabella di dati non è l'approccio migliore. – Cybermaxs

+0

dimenticare -it non lascia entrare. Dal punto di vista delle prestazioni di Btw-form prova a confrontare AppFabric con Memcache/Couchbase. – user1707312

1

Questo potrebbe essere causato dalla serializzazione integrata di .Net.

. La serializzazione netta utilizza la riflessione che a sua volta ha una prestazione scadente pari a . Consiglierei di esaminare l'uso del codice di serializzazione scritto personalizzato.

2

La differenza è il sovraccarico della rete. Nel tuo esempio SQL, salti sulla rete una volta e seleziona N righe. Nell'esempio AppFabric, si salta sulla rete PER RECORD anziché in massa. Questa è la differenza. Per provarlo, archivia temporaneamente i tuoi record in AppFabric come elenco e recupera l'elenco una sola volta oppure utilizza l'API Bulk di AppFabric per selezionarli tutti in una sola richiesta, il che dovrebbe spiegare gran parte della differenza.

+1

non penso che lo stia facendo: sembra che stia recuperando i dati riga per riga: sqlCommand = 'Seleziona * da TableName dove posId =' someId '' –

Problemi correlati