Va bene ignorare le scarse prestazioni di una risorsa che verrà memorizzata nella cache?

A breve termine, sì, va bene.

Sapendo che a lungo termine, ti brucerai. Quindi no, non va bene.

Sì | No dipende molto dal tuo negozio; la quantità di arretrato che è presente; e quanto sia critica questa particolare funzione.

La cache per mascherare i problemi di prestazioni è una stampella ed è una forma di debito tecnico. Il vero problema si verifica quando devi iniziare a fare cambiamenti o aggiornamenti all'interno di quell'area. La cache rappresenta il primo livello di cerotti per questo problema. I cambiamenti futuri produrranno sempre più cerotti finché non risolverai la radice del problema.

Se può essere ragionevolmente facilmente risolto entro i limiti del tuo ambiente, allora dovrebbe essere corretto. Soprattutto se è un'area volatile.

Se stai pensando di prendere scorciatoie sapendo che puoi usare la stampella del caching, allora hai già imboccato la strada sbagliata.

Come sempre, dipende. Il caching può migliorare le prestazioni ovunque tra "whopping" e "not affatto", o anche ridurre le prestazioni.

Se la tua risorsa viene letta spesso ma raramente cambiata, il caching di solito è una buona idea, soprattutto quando la sua generazione non è banale. Se, tuttavia, cambia ogni richiesta, non è possibile memorizzarla nella cache.

Inoltre, può essere utile utilizzare diversi livelli di memorizzazione nella cache, ad esempio una cache di risposta a livello HTTP che fornisce risposte identiche a richieste identiche, una cache di memoria che contiene set di dati prontamente elaborati, un'altra cache che contiene blocchi di dati grezzi dati per ulteriori elaborazioni e, naturalmente, la memorizzazione nella cache fornita con i database e i file system. Il motivo per cui vuoi memorizzare nella cache a diversi livelli è che ci sono diversi punti in cui puoi confrontare condizioni identiche con risultati identici e vuoi memorizzare nella cache ogni volta che ha senso.

Un altro fattore che devi tenere a mente è che la maggior parte dei dati non deve essere disponibile in tempo reale. È spesso accettabile presentare dati che sono, ad esempio, vecchi di un'ora o giù di lì, anche quando esistono dati più recenti. In tal caso, è possibile generare la risorsa in un processo separato, servendo la versione precedente fino a quando viene eseguita la nuova, quindi eseguendo una sostituzione atomica rapida (ad es. Rinominando un file o un'operazione di database atomico). In questo modo, ottieni sempre le massime prestazioni in qualsiasi momento, mentre puoi comunque permetterci di impiegare un po 'di tempo a generare la risorsa. E, meglio ancora, il generatore può funzionare su una macchina diversa se necessario, in modo da non impantanare il server web stesso. Ovviamente non fa male aggiungere uno strato di cache nella parte superiore di quello; dopotutto, servire dalla RAM è ancora un ordine di grandezza più veloce di quello che serve dal disco.

Sarebbe grossolanamente inaccurato dirti che lo è o non va bene perché in definitiva è un compromesso tra i tempi di implementazione e quanto desideri che il tuo programma esegua. Non penso sia giusto dire che le prestazioni del programma hanno sempre la priorità sulle prestazioni, perché in definitiva l'industria del software è un'azienda come le altre e alcuni compromessi sono accettabili.

Tuttavia, penso che l'unica volta in cui va bene ignorare le scarse prestazioni di una risorsa che verrà memorizzata nella cache è se si pianifica il precaricamento di molte risorse che verranno utilizzate all'avvio del programma e la cache non è debole (non butti vecchi dati a favore di nuovi dati). Gli utenti tendono ad avere poca pazienza per i tempi di attesa, ma tendono anche ad essere più tollerabili se si aspettano di dover aspettare, come i momenti in cui stai aprendo un programma o stai creando un rapporto. Puoi approfittare di questo e caricare una volta e mettere questa risorsa nella cache. Non combinare le scarse prestazioni con il caricamento lento, poiché ciò creerà ritardi imprevisti quando l'utente non se lo aspetta.

E, naturalmente, do assicurati di risolvere il problema delle prestazioni alla fine.