XPO – 11.1 Sneak Peek - Profile it!

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.

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: 

 Take special note that there are two Sessions, not one (you will remember that we set only one at design time):

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!

Free DevExpress Products - Get Your Copy Today