Media Object Oddities

Back on the MOBJ issues - sorry for continuing this scrabble game.

In DV - MOBJ work great; Fat, ES/Reports and Web.
In PY - MOBJ work great for WEB - they suck for FAT and ES/Reports. When saving a MOBJ from a web client - it takes about a second. When saving from a FAT - go get your Coffee!. We are getting complaints about some reports taking seconds in DV - and minutes (many minutes) in PY... I know that a couple of these reports hit Media Objects...

Any of you gurus have a good guess what might be misconstrewed on our behalf

8.12, Solaris, and a bunch of other things

(db)

DB,

Turn on your debug log locally and run one of the the reports that you consistently have the issue with. Then run the results through the Performance Workbench, where you can use the log parser to display the timing on each line. That should confirm whether or not media objects are your problem.

We've been live on 8.12 (8.96 H1) for a month and a half and our only problem with media objects so far have been getting the Active X controls installed for individual browsers. Do you have 8.12 in PD and if so, how does it compare to PY and DV?

Francois
8.12/8.96 H1/SQL 2000/JDBC 2005/Websphere 6.0

P.S. - Nice to know there are other JDE users in Idaho....

[ QUOTE ]
Back on the MOBJ issues - sorry for continuing this scrabble game.

In DV - MOBJ work great; Fat, ES/Reports and Web.
In PY - MOBJ work great for WEB - they suck for FAT and ES/Reports. When saving a MOBJ from a web client - it takes about a second. When saving from a FAT - go get your Coffee!. We are getting complaints about some reports taking seconds in DV - and minutes (many minutes) in PY... I know that a couple of these reports hit Media Objects...

Any of you gurus have a good guess what might be misconstrewed on our behalf

8.12, Solaris, and a bunch of other things

(db)

[/ QUOTE ]

WAG - Indexes on F00165
Second WAG - Datasource/Timeout issues with F00165


Hmmmmmm, now that I think about it....MO on the web are cached and written later while the fat client writes immediately. Something to think about.

Here's a test you could try:

Rename the PY812 pathcode to PY812_bak.

Rename the DV812 pathcode to PY812. Test.

Change the names back (obviously).

Wally,

More info on the Performance Workbench Log Parcer - when you get a chance...
Where / How; then I can, most likely, figure the rest.

In the log, PY FAT - we get the time gaps between when the 'MOBJ Save/Exist'
is pushed and the screen returns... some times several minutes. On the Web
- it's instantaneous.

(db)




--

PerfWorkbench is available on the knowledge garden. Do a search for "Performance Workbench" or "PerfWorkbench"

[ QUOTE ]
Wally,<br><br>More info on the Performance Workbench Log Parcer - when you get a chance...<br>Where / How; then I can, most likely, figure the rest.<br><br>In the log, PY FAT - we get the time gaps between when the 'MOBJ Save/Exist'<br>is pushed and the screen returns... some times several minutes. On the Web<br>- it's instantaneous.<br><br>(db)<br><br><br><br><br>-- <br>

[/ QUOTE ]

But, on the web the MO save is cached. I was thinking about this last night and your troubleshooting approach is skewed because of this. Something is holding up the MO write in PY and I would concentrate my efforts there. I think you may be looking at the wrong half-split.

Here's the link to the Performance Workbench tool on the Weed Garden (although I admit that the gardening is much improved):
Performance Workbench Download

It's very simple to use and there is a sufficient explanation of the tool on the link page. Good luck.

Francois

Perfect - thank you:
* 0.016 seconds: May 14 15:53:05.518342 - 5244/2400 WRK:Starting
jdeCallObject

So did parsing the log help identify what is taking so long? I don't see how .016 seconds could be your problem. I'm just curious whether you've made any progress with the issue.

I have the 'real' tech guy looking at it this week.

The previous post was what the Performance Workbench provided back -

(db)




--

Just to update - the issue appears to have been a conversion issue!

The object was marked Unicode - however, it was non-unicode. Apparently the conversion failed, but marked it as completed anyway.

now you know what I know - and canoeing is half the paddle