I would start by trying to simulate real users and then crank that up till your server room temperature is a 3 digit ;-)
Things to consider: - Network bandwith. Silverlight apps can be quite huge (>1MB). So if 1000 users start up the application at the same time in the morning 8AM. You get >1GB of data that you need to push out over your pipe. Internally that might be OK, but for the internetz you might think about hosting your XAP on a CDN. - Network bandwith #2. Measure the bandwith usage of 1 user using your app, and then 10 users (100 users). Does it scale? Where do the below numbers go? - Make sure to measure on the servers: - CPU, memory, Disk IO, network (perfmon) You can get very fancy with performance testing, till you have an automated stresstest in the cloud that runs every night and sends you a report in the morning. But you can get a very good feeling about performance with jut some manual verifications. Make sure to write your results down for later comparison. Not that I have been bitten by that ;-) .peter.gfader. http://blog.gfader.com fat fingers + tiny touchscreen -> short emails On Jan 25, 2012 8:05 AM, "Grant Molloy" <[email protected]> wrote: > I'd start with testing the easiest points first, the actual service and > the components behind it. > > Rig up an application to hit these points in a multi threaded fashion. > Eg. > In a loop x long, create a new thread and fire off a call to svc or method. > Repeat y times with z interval. > > Grant > On 25/01/2012 4:38 PM, "Greg Keogh" <[email protected]> wrote: > >> Some potential customers have asked if our product has been stress >> tested. The answer is that we’re not telling them until we figure out if >> it’s possible. Web searches produce lots of hits on this subject, but I >> thought it would be wise to ask here first to see if anyone has experience >> and advice.**** >> >> ** ** >> >> Our app is actually composed of a Silverlight 4 app in the browser >> client, a C++ COM component at the other, and a WCF service to allow the >> two to talk to each other via XML. So there are many potential points for >> performance trouble: Loading the SL app, rendering complex graphics in the >> SL app, transmitting XML (it’s zipped), network speed, IIS performance, and >> performance of the C++ component which further talks to the file system and >> contacts a master authentication server using FTP. The author the C++ >> component says it was not written with multithreading in mind.**** >> >> ** ** >> >> So we have to think of a way of stress testing this conglomeration. I’ll >> continue reading web search results in the meantime.**** >> >> ** ** >> >> Greg**** >> >
