Comments
3 comments
-
cjlotz wrote:Question 4
Thinking about the CI process, how would one go about profiling your application. I'm using a MSBuild script to drive our whole CI process. I can succesfully fire off the command line profiler, but the problem is that the script will suspend the build process until it times out (if specified) or else hang indefinitely.
I've made some further progress w.r.t the above mentioned issue. I discovered an AsynExec MSBuild task that works quite nicely and I've incorporated that into the build process without any problems. This allows me to start the Profiler and then launch soapUI command line test runner to drive the web services.
Question 7
I've got a another question though. Through the UI it is possible to select File I/O and SQL Server Reads/Writes when profiling the application. I can't seem to find command line arguments for these options. Are they available from the command line?
Thanks - things are starting to take shape nicely :-) -
cjlotz wrote:Hi
Question 1
How does one indicate on the command line that it should profile IIS? From trial and error it seems like specifying the /port:80 tells ANTS that I'm interested in profiling IIS? Can you please confirm?
The setup for IIS is somewhat involved, as it's slightly different for each version. This means that there would end up being a lot of options relating to IIS, most of which are specific to a particular version of Windows. Another consideration is that profiling IIS requires restarting it, so we wanted to make sure that the 'standard' way of doing things would be to use the WebDev (Cassini) server instead.
The way to profile an IIS session is to initially do so from the UI and save out a project file. You can then use this to initiate profiling with the /project option. Any additional settings you specify on the command line will override those in the project file.Question 2
When I try using the following command args:
/ll /ows /port:80 /force /timeout:60 /csv:Results1.csv /data:Results2.csv
I get the following exception:
Looks like a problem with the error reporting: it's supposed to complain that you haven't told it what to profile here, but is just dumping out an exception instead.Question 3
To work around the issues in Question 2 I created an app6 project file. I can then successfully run the command line profiler using the /p: argument. However, after the profiling session ends I get the following exception:
The problem seems to be related to writing out the results file. When I look on disk however, both the csv and app6results file is created. I don't see any summary information though. I am also able to open the app6results file with the UI and all information seems to display correctly.
Yes, I think you're right here: I'll need to do some investigation before I know for sure what's going on here.Question 4
Thinking about the CI process, how would one go about profiling your application. I'm using a MSBuild script to drive our whole CI process. I can succesfully fire off the command line profiler, but the problem is that the script will suspend the build process until it times out (if specified) or else hang indefinitely. The only way I can think of making this work is by running the profiler as a service on the build agents. However, I don't want to continuously profile the application. I have specific build configurations that I want to profile. So how would one go about integrating this into an automated build process?
This is easier with a command-line application or set of unit tests as these run for a finite amount of time. For server processes, the intention is that you use the /timeout option to tell ANTS to stop profiling for a while and have a separate script that is launched simultaneously and actually performs whichever actions you wish to profile.
Suspending the build process while profiling is occurring was intended: having other processes running will affect the measured time, so in most cases it's desirable for profiling to be an exclusive task.
It would be possible to add something to the tool that would make it launch another process if that would help with this.Question 5
When profiling the application through the UI, I don't get any line-leve details - only a method summary. I've seen somebody else complain about this as well.
Is this from results saved via the command line or just directly through the UI? The command line reports don't contain line level results by default so it turns them off to increase performance. The /lineLevel option can be used to turn them back on in that case.
If it's in the UI, are the methods with source showing up in bold? If they aren't then it doesn't think that they have associated source code for whatever reason, most likely because it can't find the pdb debugging data. There are a few reasons this can happen with ASP.NET pages, the most usual being that debugging is turned off in the config file.Question 6
ETA of a version that solves these problems ;-)
Well, I'm working on attach to process at the moment, and I need to move on to Silverlight 4 support after that, but after all of that I should be in a position to start looking at these things. If all goes smoothly, that should mean 2-3 weeks, but we've been hitting a lot of roadbumps with the details of these features so it's difficult to make any promises.I've got a another question though. Through the UI it is possible to select File I/O and SQL Server Reads/Writes when profiling the application. I can't seem to find command line arguments for these options. Are they available from the command line?
Ah, good point. No, they're not at the moment, as they were added later on. They should definitely be in the final version, though (depending on how time works out, the initial revision might only support viewing the data through the UI, though I'll look in to adding it to the XML report as well) -
The way to profile an IIS session is to initially do so from the UI and save out a project file. You can then use this to initiate profiling with the /project option. Any additional settings you specify on the command line will override those in the project file.
100% Working fine although my project specifies File I/O and SQL Server Reads/Writes and I'm not getting the info without overriding it from the command line. This seems to be related to Question 7 though.It would be possible to add something to the tool that would make it launch another process if that would help with this.
I think people might find that useful although as I posted later on, I worked around the issue using the AsyncTask. This works fine. I fire off the profiler with a Timeout period and then fire off the soapUI LoadTestRunner. The results are written out after the timeout period.Is this from results saved via the command line or just directly through the UI?If it's in the UI, are the methods with source showing up in bold? If they aren't then it doesn't think that they have associated source code for whatever reason, most likely because it can't find the pdb debugging data. There are a few reasons this can happen with ASP.NET pages, the most usual being that debugging is turned off in the config file.Well, I'm working on attach to process at the moment, and I need to move on to Silverlight 4 support after that, but after all of that I should be in a position to start looking at these things.Ah, good point. No, they're not at the moment, as they were added later on. They should definitely be in the final version, though (depending on how time works out, the initial revision might only support viewing the data through the UI, though I'll look in to adding it to the XML report as well)
Question 8
I have another question - comparisons between performance runs. Do you support this or plan to support this in future? I know dotTrace has the ability and if I remember Compuware DevPartner as well.
Add comment
Please sign in to leave a comment.
I'm trying to get the command line tool working with the aim to include it as part of our continuous integration process. However, I've run into a few issues that I would like to clarify.
Some background - I'm trying to profile the server side WCF Services of our Silverlight 3 application. The services are hosted in IIS 7 (Win 7) and running from the default port 80 - http://localhost/OK52. The idea is to "drive" the services using soapUI's command line test runnner to serve up a load against the server.
Question 1
How does one indicate on the command line that it should profile IIS? From trial and error it seems like specifying the /port:80 tells ANTS that I'm interested in profiling IIS? Can you please confirm?
Question 2
When I try using the following command args:
/ll /ows /port:80 /force /timeout:60 /csv:Results1.csv /data:Results2.csv
I get the following exception:
Question 3
To work around the issues in Question 2 I created an app6 project file. I can then successfully run the command line profiler using the /p: argument. However, after the profiling session ends I get the following exception:
The problem seems to be related to writing out the results file. When I look on disk however, both the csv and app6results file is created. I don't see any summary information though. I am also able to open the app6results file with the UI and all information seems to display correctly.
Question 4
Thinking about the CI process, how would one go about profiling your application. I'm using a MSBuild script to drive our whole CI process. I can succesfully fire off the command line profiler, but the problem is that the script will suspend the build process until it times out (if specified) or else hang indefinitely. The only way I can think of making this work is by running the profiler as a service on the build agents. However, I don't want to continuously profile the application. I have specific build configurations that I want to profile. So how would one go about integrating this into an automated build process?
Question 5
When profiling the application through the UI, I don't get any line-leve details - only a method summary. I've seen somebody else complain about this as well.
Question 6
ETA of a version that solves these problems ;-)
Thanks
Carel