cancel
Showing results for 
Search instead for 
Did you mean: 

Performance of MI Apps after porting to MI 7.0

Former Member
0 Kudos

Hi gurus from Sdn,

Have a real big problem. I had to port some MI applications (AWT, Windows Mobile 2003, Generic Sync) from ME 2.1 to MI 7.0. But now the performance is so what bad. On ME 2.1 the apps perform really good (can't believe it, but it's true). The infrastructure (network, wlan access poits, handheld devices - 64MB) doesn't change (and it defenetly couldn't change). Made a lot of performace tests and all connections are good (backend - mi server - client), but the problem is, that the MI Client now needs about 6 to 20 secs to display the next sreen (outbound container has only one table line, with four fields in it!!!!, AWT screen also have to display only four labels). What makes me really thinking is, that when I look at the trace files I always see XML syntax in it. Are the data now send as XML? And if yes, are there any possibilities to switch back to the good old string data , cause who wants to parse XML on an handheld with 64MB Are there any possibilites, why the old version of the apps can't, doesn't work on MI 7.0?

Thx,

Daniel

Accepted Solutions (1)

Accepted Solutions (1)

AjithC
Employee
Employee
0 Kudos

Hi,

I think you are talking about application performace and not sync performacne. In MI, XML is used for communicating with the server, but data is not stored as XML in the PDA.

Also some of the ME API's are depricated in MI. Also there is some changes in the client framwork of MI. Please check the guidelines.

Regards

Ajith

Former Member
0 Kudos

Hi Ajith,

First thx for your reply, but as I described in my thread, I had no problem with sync performance between MI and Client. The problem is that MI Client framework is sowhat slow. And defenetly SAP changes the behaviour of the client. 1. MI 70 libraries are about 3 times greater than ME 2.1 ibs (and also ME 2.5 libs > SP 13). 2. I've don't use any deprecated library in my source code. 3. the app use only Java SDK 1.3 features, so there should normally no different between app running on ME21 and MI70. It's always easy to say, the problem is in the application. But thats definetly not the case.

And as you stated "Data is not stored as XML", you are right data is not stored as XML (you won't find an xml file on the client, and that was no different in ME21, files were always stored as binaries, and the file extensions has nothing to do with the content of the file), but the difference in MI70 is now, the binaries are no more text files they are XML files. Or would you tell me that the guys from SAP take everthing what is snyced and convert that only for the traces to xml (I don't think so).

Regards,

Daniel

AjithC
Employee
Employee
0 Kudos

Hi Daniel,

As I said before, data is exchanged beween server and client in XML format. Its not stored in client as XML file or in XML format.

During sync, data is sent from server in XML format. its converted to binary and then stored in local persistance. With 640 & 7.0 you can even use DB2e as local database in client.

The reason you see xml mesages in trace is what set during the sync time.

Your application will be compactible. No doubt about that. What I mean was you may not be using the most efficient APIs to read and write data. From 640 SP13, there is a significant change in the client architecute and that's the reason the library is huge..

If you can provide me more details like where exactly you find performance problem reading or writing, which API you are using etc, it will be more useful in finding out the issue..

Regards

Ajith

Former Member
0 Kudos

Hi Daniel,

I thought from the first initial request your problem is the sync as such. As in the previour replies I can tell you that the XML format is only used for sync and data transport. Local storage is not XML, it is in binary format in FileIO or DB2e. I had some problems with that as I switched from 2.1 to 2.5 in the past, but changing the persistence layer solved that issue. The hughe API is cause by the new persistence layer and because of compatibility they have the old persistence layer as well -> another reason for the bigger size.

Well, I guess you have just switched a few things but still use the old persistence API. Please have a look into the latest MDK - there you should see how the new API works and how you can use the query API for example to select data. Without knowledge of the APP it is really difficult to give you a hint why you have the problem - but as I know from my experience, with the new API the App is faster now then it was with ME2.1.

Hope this helps a little to give you a hint where to look to have a better performance.

Regards,

Oliver

Former Member
0 Kudos

Hi Ajith, Oliver,

Thx for your replies. Your answer were really helpfull to make things a little bit clearer. To tell you something about the problem with the apps, it's not the sync the problem (performs perfectly), problem appears after the data is synched and the client needs to work with the synced data, in detail, read the synched data and display it on the next screen. The app uses no persistance (only POJOs to work with). I'm with you when you say, check the app (and I thik everything should't be changed). Maybe you have some input to help me to find the most bottle necks (and maybe you have some code samples for me, e.g. about sync and FIO persistance, MDK is nice but it's typically SAP, some examples but no real world examples -:().

I know that there are new features in the API (I had no problem with other apps on other clients with more memory). But it's always the same with Java, more features means more memory consumption.

I will let this thread open for discussions, input and so on.

thx & regards,

daniel

p.s. I'm looking forward to here from you

Former Member
0 Kudos

Hi Daniel,

If i got you correct then according to your last post sync is not a problem but only working with the data after it is downloaded. In other terms its the page navigation that is creating a problem. Am i right here? If you are using a JSP based application, then you can deploy the Tomcat addon contained in note 1009703. This addon can be deployed on devices other than Windows Mobile 2005 as well.

Also something for you and others to know about

Of late we have done some performance improvements on the client for synchronization and the results of the performance improvement are documented in the Additional information section of note 1124824. Kindly refer to the same and may you can upgrade to this or higher SP.

Hope this helps.

Best Regards

Sivakumar

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Daniel,

Yes the data is sent in the form of XML. There is no way you can change that to string format.

Thanks,

Preetham S