Quanto devo preoccuparmi del bilanciamento del carico?

3

Attualmente sto lavorando a un progetto che prevede che le applicazioni client (desktop e android e web) comunichino con vari processi in esecuzione su uno o più server.

La mia domanda è: quanto dovrei pensare al bilanciamento del carico e simili?

Tutti i progetti su cui ho lavorato prima consistevano nella creazione di applicazioni per uso interno all'interno delle aziende, quindi il numero di connessioni era sempre molto basso (probabilmente non più di 50 alla volta).

Tuttavia nel mio tempo ho deciso di iniziare a creare un software di contabilità, solo perché. Quindi, mi sono ritrovato con un'applicazione desktop WPF e un sito Web ASP.NET MVC e un'app Android che si connettono a vari processi / dati in esecuzione sul mio server.

Sul server c'è un database SQL (MS), vari servizi WCF per la comunicazione da client a server e alcuni servizi che eseguono operazioni di pulizia.

Funziona bene quando sto testando e solo io sono connesso. Tuttavia non ho idea di come si ridimensionerà se alcune persone iniziano a connettersi contemporaneamente.

Non sono nemmeno sicuro se rilascerò il software, per non parlare di chiunque lo usi! Tuttavia, come parte di un esercizio di apprendimento, come dovrei sviluppare il sistema in modo che possa assumere un grande carico e non crash / ritardo.

Sono consapevole che questa potrebbe essere una domanda molto aperta e potrebbe essere soggettiva a molte cose, ma come ho detto non ho esperienza in questo reparto ed è qualcosa che mi piacerebbe imparare.

    
posta Nick Williams 04.04.2013 - 14:20
fonte

4 risposte

10

However I have no idea how it will scale if a few people start connecting at once.

L'ottimizzazione prematura è la radice di tutti i mali . Se funziona, non aggiustarlo e, se sei curioso di farlo, non perdere il sonno e testalo.

Non importa se rilascerai mai il software, ci sono numerosi strumenti che possono aiutarti a eseguire test automatici di carico e stress, simulando migliaia o persino milioni di connessioni. È davvero così semplice, se i tuoi test mostrano che c'è un problema, risolvilo, se no, vai avanti.

    
risposta data 04.04.2013 - 14:26
fonte
4

Come ha detto Yannis, l'ottimizzazione prematura è la radice di tutti i mali.

Tuttavia, alcuni aspetti come la sicurezza e la scalabilità possono essere davvero difficili da risolvere "successivamente".

Nel tuo caso, ritengo che un buon compromesso sia quello di non creare scalabilità, ma tenerlo a mente e cercare di evitare decisioni di progettazione fondamentali che renderanno impossibile aggiungere in seguito:

  • apolidia, i sapori REST sono buoni
  • client e server usa e getta sono buoni
  • i thread di lavoro di lunga durata possono essere problematici
  • tutto ciò che si basa sulla sincronizzazione / serializzazione globale o solo un attore che elabora qualcosa può essere problematico

Inoltre, in generale, i livelli di app sono più facili da ridimensionare orizzontalmente rispetto a un database, quindi quando il lavoro di bilanciamento tra di essi è più utile il lavoro sul server delle app.

    
risposta data 04.04.2013 - 18:10
fonte
2

La scalabilità di un'applicazione Web è in genere un problema di distribuzione, presupponendo che siano state seguite le corrette pratiche di sviluppo del software nello sviluppo dell'applicazione Web (ad esempio, non memorizzare i dati utente in statica o contesti applicazione / server.)

La maggior parte dei server Web, come Apache, può essere configurata per fungere da bilanciamento del carico su più server di applicazioni delegando le richieste per contesti specifici. I server Web possono essere bilanciati dal carico sedendosi dietro un commutatore di contenuti che è configurato per delegare le richieste in arrivo.

Un certo numero di server applicazioni in molte tecnologie diverse può anche essere configurato per avere la condivisione delle sessioni, la distribuzione automatica della server farm e altro ancora. Un singhiozzo in cui potresti incorrere potrebbe essere programmato come se non avessi implementato la pianificazione delle attività tenendo conto della concorrenza, quindi ogni server verrà eseguito e farà le sue cose, il che potrebbe essere negativo. Anche in questo caso, molti server di applicazioni dispongono di funzionalità di pianificazione delle attività incorporate, in modo che non sia necessario implementarle direttamente all'interno dell'applicazione.

La maggior parte dei database principali ha un numero di opzioni di bilanciamento del carico e possibili configurazioni. Potrebbe essere semplice come configurare un server per un failover a freddo, o qualcosa di complesso come più nodi di server di database, ognuno gestendo le proprie richieste utente, piani di query e connessioni database in modo concorrente rispetto a una condivisone condivisa.

La condivisione file contenente i dati può anche essere concomitante e avere un failover montando su qualcosa di semplice come un array RAID di unità disco o qualcosa di costoso e complesso come una SAN (Storage Area Network).

E se tutto questo non è sufficiente e non hai soldi o accesso a un data center per i migliori giocattoli ... c'è sempre un fornitore di servizi cloud che ti dà sostanzialmente una scalabilità infinita.

    
risposta data 04.04.2013 - 15:07
fonte
1

Per quanto riguarda il "ridimensionamento per bilanciamento del carico", assicurati di sapere quali sono le proprietà necessarie per il bilanciamento del carico. Se la tua gestione delle sessioni si basa ogni volta sullo stesso server delle applicazioni, hai bisogno di sessioni persistenti.

Se ridimensiona i tuoi front-end, come vengono utilizzati i tuoi back-end (storage, database, ...)?

Però è difficile dare una risposta dura e veloce.

    
risposta data 04.04.2013 - 17:36
fonte

Leggi altre domande sui tag