Introduction
We have one more amazing piece of news for our XPO customers. In version v2011 vol 1, we have implemented XPO Profiler - an external profiling tool for XPO-based business applications, allowing you to track internal events in the underlying XPO layer, such as session methods calls and database interaction commands.
XPOProfiler will be initially released as a Beta, and once you install the new version of the Suite, you will find it in the Developer Express v2011 vol 1 | Components | Tools folder under the Start menu:
In this blog I am going to overview some of its features, demonstrate different profiling modes and finally, show you a practical example on using this tool.
Getting started
First, you should modify the application configuration file (this is the App.config file in case of a Windows Forms application or the Web.config file in case of an ASP.NET application) and specify the profiling settings in a special section, as follows:
1: <?xml version="1.0" encoding="utf-8"?>
2: <configuration>
3: <configSections>
4: <section
5: name="DevExpressXpoProfiler"
6: type="DevExpress.Xpo.Logger.ProfilerConfigSection, DevExpress.Data.v11.1, Version=11.1.1.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a"
7: allowLocation="true"
8: allowDefinition="Everywhere" />
9: </configSections>
10: <DevExpressXpoProfiler
11: serverType="DevExpress.Xpo.Logger.Transport.LogServer"
12: serverAssembly="DevExpress.Xpo.v11.1, Version=11.1.1.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a"
13: categories="SQL;Session"
14: port="52934">
15: </DevExpressXpoProfiler>
Take special note that the configSections element must be the first child element of the configuration element.
I anticipate that you already thought that patching the configuration file manually is inconvenient. Well, we have already considered this! XPOProfiler can also update your configuration file automatically. Just choose the corresponding command in the main menu, and select your configuration file in the opened dialog window:
Now all XPO log messages from our application will be transferred to the port we specified. It is also possible to profile several applications at the same time. In order to do this, you can set different port numbers.
XPOProfiler can work in two profiling modes: local and remote. The first mode can be used for profiling client applications on a local machine when the latter is valuable for profiling services hosted on a remote machine.
Local profiling mode
If you profile a local application, you should set the Server name to localhost and specify the port number according to the profiled application settings:
After that, you will be able to see profiling messages in the invoked page of the XPOProfiler window:
Remote profiling mode
To profile your application remotely, you will need an additional tool called XPOProfilerProxy. By default, it is located in the %PROGRAMFILES%\DevExpress 2011.1\Components\Tools\DXperience\ folder. This program must be run on the same computer as your profiled application. You can start XPOProfilerProxy.exe either as a console application or as a service, using the following command line options:
/c – start as console application;
/i – install as service;
/u – uninstall service.
The configuration file of the profiled remote application should also be modified as described above. Port number 52927 is reserved for service purposes, so you cannot specify this number for communications.
Once you are done, create a new profiling page in the XPOProfiler. Then, in the Server name field, specify the name of the computer your application is running on and the port number, according to the profiled application settings:
After that, you will be able to see profiling messages in the invoked page of the XPOProfiler window.
Practical usage
Finally, we would like to show a practical use of the profiler, to easily resolve problems in your XPO application. Let us take a Windows Forms project and declare a persistent class - Person, in it:
1: using DevExpress.Xpo;
2:
3: namespace SampleApp {
4: public class Person : XPObject {
5: string firstName;
6: public string FirstName {
7: get { return firstName; }
8: set { SetPropertyValue<string>("FirstName", ref firstName, value); }
9: }
10: string lastName;
11: public string LastName {
12: get { return lastName; }
13: set { SetPropertyValue<string>("LastName", ref lastName, value); }
14: }
15: int age;
16: public int Age {
17: get { return age; }
18: set { SetPropertyValue<int>("Age", ref age, value); }
19: }
20: public Person(Session session) : base(session) { }
21: public Person() : base(Session.DefaultSession) { }
22: }
23: }
There will be also a form with the GridControl (gridControl1), Session (session1), XPView (xpView1) and SimpleButton (simpleButton1) components. The XPView object is bound to the GridControl and linked to the Session. The ObjectClassInfo property of the XPView object is set to our Person class. The Session is connected to the local MS SQL Server instance. The screenshot below shows what they look like together at design time:
Now, we will handle the Click event of our SimpleButton and write the following code in its Click event handler:
1: private void simpleButton1_Click(object sender, EventArgs e) {
2: Person person = new Person();
3: person.FirstName = "New first name";
4: person.LastName = "New last name";
5: person.Age = 27;
6: person.Save();
7: xpView1.Reload();
8: }
9:
This code is intended to create a new object and reload the XPView to display the changes in the GridControl. However, if you run the application and test this code, you will notice that it does not work – there are simply no new objects appearing in the grid, after the button is clicked.
What is wrong in our code? Let’s find the answer with the help of XPOProfier!
First launch the tool and connect it to our application as we described above (local profiling mode) and retest the problematic area. The following information will appear on the profiler page:
Take special note that there are two Sessions, not one (you will remember that we set only one at design time):
The first Select request is done through the Session object, which is using MSSqlConnectionProvider. Everything functions as expected here and the problem is probably with the second session:
Our assumption is correct, because the Insert request is done through the Session, using AccessConnectionProvider. You will remember that most likely this session is Session.DefaultSession. After that, we see that we violated the first XPO best practice and created a new Person object with the default constructor, by mistake. Let’s fix this bug as follows:
1: private void simpleButton1_Click(object sender, EventArgs e) {
2: Person person = new Person(session1);
3: person.FirstName = "New first name";
4: person.LastName = "New last name";
5: person.Age = 27;
6: person.Save();
7: xpView1.Reload();
8: }
9:
Then start our application and retest the fixed code:
Of course, it is now working as expected.
Although the example here is quite straightforward, and the test mistake in our code might be solved without the profiler, i.e. by just remembering some XPO specifics or detecting an Access database near the executable file, there are of course lots of other and more complex cases, where profiling XPO internals is vital. XPOProfiler can help you save a significant amount of time when solving problems in these kinds of scenarios, or finding bottlenecks in your application. For instance, one more noticeable feature of the XPO profiler is that it automatically detects and informs you of situations when a single Session is accessed from multiple threads.
As always, we are eager to hear your thoughts on this addition to the XPO suite!
Happy XPO-profiling!