Quanta configurabilità da dare agli utenti per quanto riguarda la concorrenza?

Non vuoi mai esporre gli utenti medi alle viscere interne di come funziona la tua applicazione, specialmente se la stai supportando. Il BeOS veniva fornito con un'utilità che consentiva di spegnere un processore (questo è prima dei processori multicore) solo per vedere l'impatto sulle prestazioni. E sì, puoi disattivare tutti i processori. In quel momento la macchina si è bloccata e l'unica risorsa per riavviare la macchina.

La maggior parte delle piattaforme fornirà un modo per interrogare il sistema per il numero di core / processori sulla macchina. Eseguendo alcuni test di profilo nel proprio ambiente, è possibile determinare le caratteristiche di come l'applicazione viene eseguita in modo più efficiente. Puoi fare in modo che l'app imposti la sua configurazione interna utilizzando rapporti semplici sul numero di core disponibili. Sono sicuro che stai pensando che è il tipo di cosa che un amministratore di sistema potrebbe voler controllare. Potresti avere o meno ragione.

Se stiamo parlando di software server qui, penso che un approccio migliore sia l'utilizzo di un approccio simile alla tecnologia Hot Spot di Java. Fondamentalmente, Hot Spot ricompilerà porzioni ottimizzate del codice (rimuovendo completamente le sezioni che non verranno mai applicate) e sostituirà la nuova implementazione quando è sicura. Prende le sue decisioni sul comportamento del ramo durante il runtime (e il valore dei valori statici, ecc.).

In un approccio simile, potresti monitorare le aree di prestazione chiave. Finché disponi di una funzione di costo appropriata, disponi di un misuratore efficace per mettere a punto la configurazione in fase di esecuzione e adattarla alle variazioni delle prestazioni al di fuori del controllo dell'applicazione. Se le prestazioni si riducono, è possibile avviare una nuova attività concorrente o eliminarne alcune. Puoi farlo scegliere di eseguire qualcosa in remoto o localmente se il costo delle comunicazioni e il carico corrente del software sul server lo giustificano.

Concedere all'utente l'accesso al modo in cui funzionano gli interni della tua applicazione è come dare loro una pistola carica. La linea di fondo è che a meno che non abbia intenzione di addestrare qualcuno a usare correttamente una pistola, probabilmente è meglio non tenerla in giro - molto meno caricarla. Possono spararsi ai piedi o peggio.

Non penso che dare il controllo dell'utente su queste opzioni sia una buona idea. Ovviamente ciò dipende dal software e dal target demografico dell'utente, ma non riesco a immaginare un'applicazione comune in cui l'utente medio sia interessato a modificare quel tipo di cose. Vogliono solo che l'applicazione funzioni. La regolazione incrementale delle opzioni delle prestazioni tramite tentativi ed errori è probabilmente troppo.

Se hai problemi di prestazioni, risolvili. In caso contrario, non preoccuparti e non complicare l'app e potenzialmente confondere l'utente con opzioni che potrebbero non comprendere. Potresti aprirti a un sacco di ticket di supporto sulla falsariga di "Ho cambiato alcune opzioni e ora la tua applicazione è troppo lenta. Risolvi il problema.", Ammettendo anche che hanno cambiato le impostazioni.