ciao, il traffico verso l'esterno non viene influenzato dalla posizione del database. Sia che si trovi su A che su B, il traffico in uscita sarà sempre proporzionale al numero di richieste degli utenti del sito.
Il traffico tra A e B invece puoi mitigarlo ricorrendo alla OutputCache di Asp.Net. Infatti, perché fare continue richieste al database se i dati restituiti sono sempre gli stessi? Potrai poi invalidare la Cache nel momento in cui i dati si aggiornano, grazie ad una SqlDependency. Leggi questo articolo in merito.
http://www.aspitalia.com/articoli/asp.net2/caching.aspx#title_2Valuta questi vantaggi e svantaggi di spostare il database in un proprio server "A".
Vantaggi:
* L'applicazione scala meglio. Se le visite sono così tante che B non riesce a farvi fronte, puoi sempre aggiungere un webserver C che attinge anch'esso i dati da A, e mettere entrambi in
load balancing, così che si spartiscano le richieste.
* Puoi ottimizzare le risorse hardware. Sul webserver magari metti molta più ram, così che tante pagine possano restare in cache e senza paura che IIS e Sql Server si contendano l'uso della memoria.
* Se malaugaratamente dovessero violarti il webserver, la superficie d'attacco del database sarebbe limitata dai (pochi) privilegi che avrai dato all'utente che accede a sql server. Comunque questo punto ha poco senso se su A c'è un solo database che è a completo servizio dell'unica applicazione che è su B. Tanto vale che si trovi sulla stessa macchina, a quel punto.
Svantaggi:
* La latenza aumenta. Se il db si trova su un'altra macchina, il portale impiegherà più tempo a stabilire una connessione e a recuperare i dati;
* Anche la complessità aumenta. Devi gestire due macchine anziché una sola. Basta che o A o B smetta di funzionare e l'intera applicazione va giù.
non sapendo nel dettaglio che cosa fa effettivamente questo portale web,
Beh, questa informazione è cruciale per prendere una decisione consapevole. Se il volume di richieste è imprevedibile, una qualsiasi soluzione hardware che puoi trovare non sarà mai adeguata o nei costi o nelle prestazioni o nell'affidabilità.
Inizialmente, potresti mandare in produzione il portale su
Azure (nel cloud), così per qualche mese potresti misurare gli accessi e capire che hardware ti serve. Puoi fare una
prova gratuita prima di andare in produzione, e da questa pagina puoi calcolare quanto ti costerebbe dopo.
http://www.microsoft.com/windowsazure/pricing-calculator/Una volta su Azure, comunque, io credo che vorrai restarci perché è molto semplice scalare le risorse in base alle necessità, e paghi solo per quello che consumi. Inoltre Azure si preoccupa per te della ridondanza, del load balancing, e delle altre questioni che ti distrarrebbero dallo sviluppo e dal mantenimento del portale.
Dagli un'occhiata, ciao.