ciao,
Sl4ck3r ha scritto:
Poi cmq tu dici che usare il DB su un altro server aumenta i tempi di latenza però scusa l'I/O su disco non migliora ? Un conto è se l'HD e la CPU devono soddisfare richieste HTTP e SQL Query un conto è se uno fà una cosa e l'altro un altra.
Certo, ma facendo delle misurazioni con il Performance Monitor, il Sql Profiler o altro strumento, dovresti cercare di capire se è effettivamente la soluzione migliore nel tuo caso. E capirlo non è una cosa immediata, ma puoi prepararti al meglio ai veri momenti di picco facendo delle "simulazioni di carico" con il tool WCat.
http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1466Sl4ck3r ha scritto:
adesso quali sono queste risorse in questo caso determinanti ? CPU o Hard Disk che non ce la fà ??
Non ho modo di saperlo... se ti suggerisco di misurare è perché non c'è una soluzione universalmente valida per ogni sistema e quindi bisogna "investigare".
Quello che mi viene in mente, se posizionassi il db su un'altra macchina, è che la tua applicazione *potrebbe* subire ripetutamente un certo
overhead nella trasmissione dei dati in rete locale. Da quanto mi è sembrato di capire, la tua applicazione fa molte query (anche se "veloci") e deve soddisfare un certo numero di richieste al secondo, quindi questa tipologia di utilizzo potrebbe rendere più evidente il problema.
Sl4ck3r ha scritto:
Cioè spesso si consiglia di porre il DB su un altro Server, almeno così ho spesso sentito
E' vero ma non è un dogma. Quello diventa necessario quando hai più di un webserver che devono accedere ad una fonte di dati comune, oppure quando vuoi proteggere i dati dietro un firewall in modo che siano un po' più protetti se qualcuno dovesse bucarti il webserver.
E comunque tra le macchine c'è sempre un link Gigabit diretto, con Jumbo frames abilitati, mentre le tue macchine, correggimi se sbaglio, potrebbero non essere fisicamente neanche nella stessa stanza.
Nella scelta devi considerare anche il costo del mantenimento di un secondo server che si rivelerà effettivamente utile solo nei momenti di picco. Non sempre aumentare il proprio hardware ti dà il miglior rapporto benefici/costi.
Sl4ck3r ha scritto:
.non posso spendere soldi a potenziare e magari poi il problema persiste e non ho concluso niente..
Appunto :)
Sl4ck3r ha scritto:
Poi per I/O io comunque mi riferisco a quello su disco;
Sì sì, anch'io. Da questo punto di vista *potrebbe* essere più efficiente ed economico aggiungere al primo server un disco allo stato solido che userai solo per il database. Gli SSD sono enormemente più rapidi quando si tratta di accesso casuale ai dati. Qui trovi dei benchmark.
http://www.xlr8yourmac.com/IDE/SSD_vs_VelociRaptor_vs_Raptor/SSD_vs_VelociRaptor_Raptor.html
Queste, comunque, sono tutte idee campate in aria finché non hai delle misurazioni alla mano che ti suggeriscano quale strada intraprendere.
La prima cosa che farei per affrontare il problema è fare uno stress test per misurare il numero di richieste che il server può gestire e, al contempo, misurare i consumi di ram, cpu e disco nel periodo di tempo. Studiati i vari indicatori del performance monitor per avere un'idea su quali ti possano rilevare dove l'applicazione trascorre la maggior parte del tempo.
Hai anche quest'ottimo strumento gratuito che si chiama
New Relic per misurare le performance (la versione Pro è in prova per 14 giorni). Guarda il video, il tizio fumettoso non sa proprio da dove iniziare :)
http://newrelic.com/why-new-relic/how-it-worksPoi, in base alle statistiche ottenute, andrei ad ottimizzare l'applicazione affinché faccia richieste al database il meno possibile. Questo, come già detto, puoi ottenerlo con i meccanismi di caching di asp.net, oppure infilando in uno stesso SqlCommand più comandi INSERT e UPDATE e query SELECT.
Poi, a ripetere lo stress test e annotare gli eventuali miglioramenti.
Vai avanti così finché continui a notare miglioramenti. Sperimenta anche varie impostazioni della connection string, specie quelle che riguardano il connection pooling.
http://msdn.microsoft.com/it-it/library/system.data.sqlclient.sqlconnection.connectionstring%28v=vs.80%29.aspxQuando, nonostante le ottimizzazioni, non riesci a superare una certa soglia di richieste contemporanee allora potrai valutare hardware migliore o se invece affidarti ai servizi cloud per una maggiore scalabilità. A quel punto avrai anche maggiore consapevolezza su quali siano i "punti deboli" della macchina (es. non ha abbastanza RAM per accomodare la cache, oppure il disco non è abbastanza veloce, ecc..)
Nonostante non ti abbia dato la risposta che cercavi spero comunque di esserti stato utile per iniziare ad affrontare la questione.
ciao,
Modificato da BrightSoul il 07 novembre 2011 22.57 -
