Serious performance issues with no solution in sight

I hate to be in such desperate need of help, but these forums have been extraordinarily helpful before, so I'm hoping someone will be able to help me with this series of problems.
I honestly don't know how to describe the problem beyond that it seems like the computer is coming apart.
The problem started about a week and a half, maybe two weeks, ago. I was having problems with Safari at first. Every time I used it, I would get the spinning ball, and it would take several minutes to open. If Safari was opened, the computer seemed to just lock up. No other applications could be opened, and no folders could be used. On top of that, whenever that spinning ball appeared, a series of clicking sounds could be heard coming from the upper left hand portion of the laptop (not the screen). The only way I could make it stop was to force quit (and even that was a luck of the draw issue).
I took the computer in to be checked out, but their scans and tests showed the same results as mine: nothing is wrong. The problem has since spread beyond Safari, which I ended up erasing from my computer. That same rhythmic clicking happens whenever the spinning ball appears. I have tried to find some kind of pattern to the sound/spinning ball, but have thus far been unsuccessful.
It has happened when using iTunes, saving with appleworks, having AOL instant messenger open, using Firefox, using quicktime. Whenever it happens, my system basically locks up and renders all applications useless. Force quitting is the only way I can get things going again, and even then it can take several minutes for me to even be able to force quit.
Also, software updates quit before I can download them.
I apologize for the long post, but I want to try and provide as much information as possible.
To me this sounds like a failing hard drive, and that is what the tech thought, but the tests just show nothing is wrong, and I cannot comprehend why.
My many thanks in advance for any help you can provide.

Hi Samuel,
I will agree that louder than normal clicking is a sign of something wrong with the hard drive. But you might just be hearing the hard drive working normally, it just might be doing it a lot more.
If you haven't tried a permissions repair, try one. It's worth a try, and I have known it to improve the performance of my Macs to some extent.
Also, if you have access to it, Try DiskWarrior. DiskWarrior is a program that will take your hard drive and rebuild the directory for it, clearing up errors and improving overall performance.
If you've got the means to do this, try reformatting your system. It's a lot of work, I'll admit, but perhaps something got corrupted and it could be messing up your performance.
Another thing you can try is to boot OS X from some sort of external hard drive (if you happen to have a friend who happens to own an external hard drive with OS X on it... wait, am I the only one??? darn.) and see if the problem exists when running off the other drive. If you don't happen to have such a hard drive (I mean, everyone's got a spare external hard drive with OS X installed on it, don't they?) you can simply boot a friend's Mac in FireWire target disk mode (boot the computer while holding T key), connect the 2 computers, and boot your system from the friend's hard drive (by holding the option key at startup). Of course, if none of your friends own Macs, you need to find better friends!
Basically, though, if your computer successfully boots from one of these other systems and doesn't exhibit these symptoms, then it's something with your hard drive. Try first to reformat (or at least re-install OS X), and if that doesn't work, you'll have to do a repair.
If you have to resort to calling tech support, I'll bet you $10,000 that they're going to ask you to reset the PMU and/or the PRAM on your system. Your computer could have dirt on it, and they'd have you reset the PRAM and the PMU.

Similar Messages

Serious performance issue with LV 7.1 Development Environment

I'm posting this issue to the forums prior to submitting a bug report to ensure that the problems I'm having are reproducible. To reproduce this bug, you're going to have to be an advanced user with a large project (hundreds to thousands of VIs) as the performance problem is related to the number of VIs loaded.
The issue is the increasingly poor performance of the LabVIEW 7.1 Development Environment as the number of VIs in memory increases. The actions affected include switching between front panel and diagram, saving a VI, copy and paste, clicking a menu, and the mysterious time spent (compiling? editing the runtime menu? changing the toolbar state?) between pressing the run button and when the code actually starts executing. Scrolling and, interestingly, copying via a control-drag are not affected. Running time of entirely on-diagram code does not seem to be affected.
These problems are quite severe and significantly decrease my productivity as a programmer. Since they are development environment UI issues, it's been difficult for me to find a good example VI; the best I can do is the attached "LV Speed Test.vi". It doesn't test the issues that affect me most, but it seems to suffer from the same problem.
This simple VI just shows and hides the menu bar 100 times in a tight for loop. When it is the only VI loaded, it executes in about 350 msec on my machine. (2.4 GHz P-IV/640 MB RAM/Win2k). However, when I load a single project-encompassing VI (let's call it the "giant") that references a total of about 900 user and VI-lib subVIs, the test routine takes almost a minute and half to run...about 240 times slower! I've tried this on my laptop with similar results.
The problem appears to be related to the *number* of VIs loaded and not the memory utilization. For example, if I close the "giant", and create a new VI ("memhog") that does nothing but initialize a length 20,000,000 array of doubles and stores it in an uninitialized shift register, LabView's overall memory usage (as shown in the task manager) jumps enormously, but LV Speed Test executes in about 450 msec...only slightly slower than with a fresh copy of Labview.
The problem seems to be related to excessive context switching. The Windows task manager shows over a thirteen hundred page faults occur when "LV Speed Test" is run with the "giant" in the background, versus zero or none when run by itself or when "memhog" has used up 160+MB of space.
The problem only seems to affect the frontmost window. (Unfortunately, that's where we LV programmers spend all of our time!) If you start "LV Speed Test" and then put "giant" in the foreground "LV Speed Test" runs much faster. In fact, if you use the VI server to put the "giant" VI in the foreground programmatically at the start of "LV Speed Test", execution time drops back to 450 msec, and there are no page faults!
These results show the issue is not related to video drivers or the Windows virtual memory system. My suspicion is that there is a faulty routine in LV 7.1 that is traversing the entire VI hierarchy every time certain events are thrown in the foreground window. It could be due to a problem with the Windows event tracking system, but this seems less likely.
I have been programming LV for about 7 years and switched from LV 6.1 to 7.1 about four months ago. I know NI engineers have put thousands of hours developing and testing LV 7.1, but honestly I find myself wishing I had never upgraded from using LV 6.1. (To whomever thought "hide trailing zeros" should be the default for floating point controls...what were you thinking?!)
I know each new version of LabView causes old-timers like me to grouse that things were better back in the days when we etched our block diagrams on stone tablets, etc., and honestly I'm not going to go back. I am committed to LabView 7.1. I just wish it were not so slow on my big projects!
Attachments:
LV_Speed_Test.vi ‏22 KB

Hi,
I can confirm this behavior. Setting the execution system to "user
interface" helps a bit, but there is still a big difference.
I get a feeling it has something to do with window messages, perhaps
WM_PAINT or something, that is handled differently if a VI is not
frontmost... But what do I know...
Don't know if it should be called a bug, but it sure is something that could
be optimized.
Regards,
Wiebe.
"Rob Calhoun" wrote in message
news:[email protected]...
> I'm posting this issue to the forums prior to submitting a bug report
> to ensure that the problems I'm having are reproducible. To reproduce
> this bug, you're going to have to be an advanced user with a large
> project (hundreds to thousands of VIs) as the performance problem is
> related to the number of VIs loaded.
>
> The issue is the increasingly poor performance of the LabVIEW 7.1
> Development Environment as the number of VIs in memory increases. The
> actions affected include switching between front panel and diagram,
> saving a VI, copy and paste, clicking a menu, and the mysterious time
> spent (compiling? editing the runtime menu? changing the toolbar
> state?) between pressing the run button and when the code actually
> starts executing. Scrolling and, interestingly, copying via a
> control-drag are not affected. Running time of entirely on-diagram
> code does not seem to be affected.
>
> These problems are quite severe and significantly decrease my
> productivity as a programmer. Since they are development environment
> UI issues, it's been difficult for me to find a good example VI; the
> best I can do is the attached "LV Speed Test.vi". It doesn't test the
> issues that affect me most, but it seems to suffer from the same
> problem.
>
> This simple VI just shows and hides the menu bar 100 times in a tight
> for loop. When it is the only VI loaded, it executes in about 350 msec
> on my machine. (2.4 GHz P-IV/640 MB RAM/Win2k). However, when I load a
> single project-encompassing VI (let's call it the "giant") that
> references a total of about 900 user and VI-lib subVIs, the test
> routine takes almost a minute and half to run...about 240 times
> slower! I've tried this on my laptop with similar results.
>
> The problem appears to be related to the *number* of VIs loaded and
> not the memory utilization. For example, if I close the "giant", and
> create a new VI ("memhog") that does nothing but initialize a length
> 20,000,000 array of doubles and stores it in an uninitialized shift
> register, LabView's overall memory usage (as shown in the task
> manager) jumps enormously, but LV Speed Test executes in about 450
> msec...only slightly slower than with a fresh copy of Labview.
>
> The problem seems to be related to excessive context switching. The
> Windows task manager shows over a thirteen hundred page faults occur
> when "LV Speed Test" is run with the "giant" in the background, versus
> zero or none when run by itself or when "memhog" has used up 160+MB of
> space.
>
> The problem only seems to affect the frontmost window. (Unfortunately,
> that's where we LV programmers spend all of our time!) If you start
> "LV Speed Test" and then put "giant" in the foreground "LV Speed Test"
> runs much faster. In fact, if you use the VI server to put the "giant"
> VI in the foreground programmatically at the start of "LV Speed Test",
> execution time drops back to 450 msec, and there are no page faults!
>
> These results show the issue is not related to video drivers or the
> Windows virtual memory system. My suspicion is that there is a faulty
> routine in LV 7.1 that is traversing the entire VI hierarchy every
> time certain events are thrown in the foreground window. It could be
> due to a problem with the Windows event tracking system, but this
> seems less likely.
>
> I have been programming LV for about 7 years and switched from LV 6.1
> to 7.1 about four months ago. I know NI engineers have put thousands
> of hours developing and testing LV 7.1, but honestly I find myself
> wishing I had never upgraded from using LV 6.1. (To whomever thought
> "hide trailing zeros" should be the default for floating point
> controls...what were you thinking?!)
>
> I know each new version of LabView causes old-timers like me to grouse
> that things were better back in the days when we etched our block
> diagrams on stone tablets, etc., and honestly I'm not going to go
> back. I am committed to LabView 7.1. I just wish it were not so slow
> on my big projects!

ERP Sales Order : Performance issues with Product Proposal

Hi
we are working on CRM 2007 solution and are facing serious performance issues with the ERP Sales Order functionality provided in the ICWC of this version.
In our development we are adding items in the ERP cart as soon as the user clicks on the 'New Sales Order' button of the sales order sreen. We get the items by very simple and optimized call to the ERP system and then add these entities in the Item Cart (Item collection ...in simple sense).
For adding 10 items the application takes 10 seconds and this is too much for adding just 10 items.
Can you please provide any Notes/alternative solution to resolve this issue.
Regards
Ajitabh

Hi Ajithabh,
Please apply the following SAP notes:
1061423 - Interaction Center ERP Order Performance improvement
1262277 - Performance: CRM value help causes dumps in ERP
1292817 - Performance: Reduce RFC calls during creation of ERP order.
1319885 - ERP sales order search with external reference
1326527 - Reducing number of RFC calls in IC ERP Sales Order
I hope it helps!
Regards,
Gabriel Santana

Performance issue with BW Extractor 0CRM_SRV_PROCESS_H

Hi There,
We have a serious performance issue with BW extractor 0CRM_SRV_PROCESS_H in CRM . We recently applied SAP Note: 1330249 to optimise the performance, Even after applying the note it remains slow, Please can any one update the solution if they had same issue with this Extractor or know about this issue.
Thanks,
R

Hi Ramesh,
There are some instructions available in note 1330249 that shoul help you.
I don't know what is the current release in the system, but there are corrections to be implemented by Tcode SNOTE and also manual steps(in table SMOFPARSFA).
I hope it contributes.
Regards,
Sinara Moraes

Performance Issues with large XML (1-1.5MB) files

Hi,
I'm using an XML Schema based Object relational storage for my XML documents which are typically 1-1.5 MB in size and having serious performance issues with XPath Query.
When I do XPath query against an element of SQLType varchar2, I get a good performance. But when I do a similar XPath query against an element of SQLType Collection (Varray of varchar2), I get a very ordinary performance.
I have also created indexes on extract() and analyzed my XMLType table and indexes, but I have no performance gain. Also, I have tried all sorts of storage options available for Collections ie. Varray's, Nested Tables, IOT's, LOB's, Inline, etc... and all these gave me same bad performance.
I even tried creating XMLType views based on XPath queries but the performance didn't improve much.
I guess I'm running out of options and patience as well.;)
I would appreciate any ideas/suggestions, please help.....
Thanks;
Ramakrishna Chinta

Are you having similar symptoms as I am? http://discussions.apple.com/thread.jspa?threadID=2234792&tstart=0

Performance issues with Oracle EE 9.2.0.4 and RedHat 2.1

Hello,
I am having some serious performance issues with Oracle Enterprise Edition 9.2.0.4 and RedHat Linux 2.1. The processor goes berserk at 100% for long (some 5 min.) periods of time, and all the ram memory gets used.
Some environment characteristics:
Machine: Intel Pentium IV 2.0GHz with 1GB of RAM.
OS: RedHat Linux 2.1 Enterprise.
Oracle: Oracle Enterprise Edition 9.2.0.4
Application: We have a small web-application with 10 users (for now) and very basic queries (all in stored procedures). Also we use the latest version of ODP.NET with default connection settings (some low pooling, etc).
Does anyone know what could be going on?
Is anybody else having this similar behavior?
We change from SQL-Server so we are not the world expert on the matter. But we want a reliable system nonetheless.
Please help us out, gives some tips, tricks, or guides
Thanks to all,
Frank

Thank you very much and sorry I couldnt write sooner. It seems that the administrator doesnt see the kswap going on so much, so I dont really know what is going on.
We are looking at some queries and some indexing but this is nuts, if I had some poor queries, which we dont really, the server would show pick right?
But he goes crazy and has two oracle processes taking all the resources. There seems to be little swapping going on.
Son now what? They are all ready talking about MS-SQL please help me out here, this is crazy!!!
We have, may be the most powerful combinations here. What is oracle doing?
We even kill the Working Process of the IIS and have no one do anything with the database and still dose two processes going on.
Can some one help me?
Thanks,
Frank

Performance Issue with BSIS(open accounting items)

Hey All,
      I am having serious performance issue with a accrual report which gets all open GL items, and need some tips for optimization.
The main issue is that I am accesing large tables like BSIS, BSEG, BSAS etc without proper indexes and that I am dealing with huge amounts of data.
The select itself take a long time and after that as I have so much data overall execution is slow too.
The select which concerns me the most is:
SELECT zuonr hkont gjahr belnr buzei budat blart wrbtr shkzg xblnr waers bukrs
             INTO TABLE i_bsis
              FROM bsis
              WHERE bukrs = '1000'
              AND hkont in r_hkont
              AND budat <= p_lcdate
              AND augdt = 0
              AND augbl = space
              AND gsber = c_ZRL1
              AND gjahr BETWEEN l_gjahr2 AND l_gjahr
              AND ( blart = c_re      "Invoice
              OR    blart = c_we      "Goods receipt
              OR    blart = c_zc      "Invoice Cancels
              OR    blart = c_kp ).   "Accounting offset
I have seen other related threads, but was not that helpful.
We already have a secondary index on bukrs hkont and budat, and i have checked in ST05 that it does use it. But inspite that it takes more than 15 hrs to complete(maybe because of huge data).
Any Input is highly appreciated.
Thanks

Thank you Thomas for your inputs:
You said that R_HKONT contains several ranges of account numbers. If these ranges cover a significant
portion of the overall existing account numbers, then there is no really quick access possible via the
BSIS primary key.
Unfortunately R_HKONT contains all account numbers.
As Rob said, your index on HKONT and BUDAT does not help much, since you are selecting "<=" on
BUDAT. No chance of narrowing down that range?
Will look into this.
What about GSBER? Does the value in c_ZRL1 provide a rather small subset of the overall values? Then
an index on BUKRS and GSBER might be helpful.
ZRL1 does provide a decent selection . But I dont know if one more index is a good idea on overall
system performance.
I assume that the four document types are not very selective, so it probably does not pay off to
investigate selecting on BKPF (there is an index involving BLART) and joining BSIS for the additional
information. You still might want to look into it though.
I did try to investigate this option too. Based on other threads related to BSIS and Robs Suggestion in
those threads I tried this:
SELECT bukrs belnr gjahr blart budat
FROM bkpf INTO TABLE bkpf_l
        WHERE bukrs = c_pepsico
        AND bstat IN (' ', 'A', 'B', 'D', 'M', 'S', 'V', 'W', 'Z')
        AND blart IN ('RE', 'WE', 'ZC', 'KP')
        AND gjahr BETWEEN l_gjahr2 AND l_gjahr
        AND budat <= p_lcdate.
SELECT zuonr hkont gjahr belnr buzei budat blart wrbtr shkzg xblnr waers bukrs
           FROM bsis INTO TABLE i_bsis FOR ALL ENTRIES IN bkpf_l
                     WHERE bukrs = bkpf_l-bukrs
                      AND hkont IN r_hkont
                      AND budat = bkpf_l-budat
                      AND augdt = 0
                      AND augbl = space
                      AND gjahr = bkpf_l-gjahr
                      AND belnr = bkpf_l-belnr
                      AND blart = bkpf_l-blart
                      AND gsber = c_zrl1.
The improves the select on BSIS a lot, but the first select on BKPF kills it. Not sure if this would help
improve performance.
Also I was wondering whether it helps on refreshing the tabe statistics through DB20. The last refresh
was done 7 months back. How frequently should we do this? Will it help?

Performance issue with view selection after migration from oracle to MaxDb

Hello,
After the migration from oracle to MaxDb we have serious performance issues with a lot of our tableview selections.
Does anybody know about this problem and how to solve it ??
Best regards !!!
Gert-Jan

Hello Gert-Jan,
most probably you need additional indexes to get better performance.
Using the command monitor you can identify the long running SQL statements and check the optimizer access strategy. Then you can decide which indexes might help.
If this is about an SAP system, you can find additional information about performance analysis in SAP notes 725489 and 819641.
SAP Hosting provides the so-called service 'MaxDB Migration Support' to help you in such cases. The service description can be found here:
http://www.saphosting.de/mediacenter/pdfs/solutionbriefs/MaxDB_de.pdf
http://www.saphosting.com/mediacenter/pdfs/solutionbriefs/maxDB-migration-support_en.pdf.
Best regards,
Melanie Handreck

Performance issue with using buffering in a APPL0 or APPL1 Table

Hi,
Can anyone please tell me whether there's any serious performace issue with using buffering for a Master or Transaction table? I'm asking this because when I run code inspector for my transp table I'm getting information message:
Message Code 0011 ==> Buffereing is Activated but Delivery Class Is "A" and Message Code 0014 ==> Buffereing is Activated but Data Class Is "APPL1".
So what's other way round for improving performance.
Thanks,
Mahesh M.S.

Hi,
have you read the documentation?
Let me paste it here for you:
Buffering is switched on for the examined table and it has data type 'APPL0' or 'APPL1'.
Tables with data type 'APPL0' or 'APPL1' should contain master or transaction data, so these tables should either contain a large amount of data or their content should change frequently. Therefore buffering the table is unfavourable. Very large tables suppress other tables in the buffer memory and hence slow done any access to them. Transaction data should not be buffered because the synchronization of the changes on the various application servers is very time consuming.
In exceptional cases, small master data tables ('APPL0', size category 0) can be buffered.
The solution depends on the table content. If it is master or transaction data, the table should not be buffered. If the table content does not consist of master or transaction data, the data type should be corrected accordingly.
This should answer your questions...
Kind regards,
Hermann

Performance issues with BAPI_PROJECT_MAINTAIN

Hi,
We are facing Performance issues with BAPI_PROJECT_MAINTAIN.Would like to know any suggestions for improving performance.
I would also like to know statistics regarding how much time is required to create a project with 3000 activities, 100 WBS etc.
Regards

Yes, I have. But didnt find any one relevant. If you can share time reqd for particular number of objects or suggest any solutions.
Regards

Performance issues with Motion (position, scale, rotate) and GTX 590

I'm experiencing performance issues with my Premiere Pro CC when I scale, position or rotate a clip in the program monitor.
I have no performance issues with playback! It's only, when i move something with the mouse or by changing the x,y-values of Position in the Motion-Dialog in video effects.
Premiere then lags terribly and updates the program monitor only about once per second - this makes it very difficult and cumbersome to work and position things.
On a second Premiere installation on my laptop, performance is fine and fluid - allthough it doesn't have GPU support and is a much slower computer.
I'm pretty sure this has somehow to do with my graphic card, which is a Nvidia GTX 590.
I was told by the support, that it is actually a dual graphic card, which is not supported/liked by Premiere.
The thing is, until the latest Premiere update, I did not have performance issues at all with this card.
I also read on the forum that others with the GTX 590 did not experience any problems with it
So where does this come from?
There is no change in performance whether or not I activate Mercury Playback Engine GPU acceleration.
I also tried deactivating one of the 2 gpus, but there also was no change.
Does anyone else know this problem and has anyone a solution?
I'm running Premiere CC on a Win 7 64bit engine, Nvidia GTX 590, latest driver (of today),

I am suffering from the same phenomenon since I updated just before christmas, I think.
I am hardly able to do scaling, rotating and translating in the program monitor itslef - whil motion has been highlighted in teh effect controls.
In the effect controls I can scale, rotate etc however.
Also I have noticed there is a yellow box with handles in teh program monitor. I remember it was white before.
I cannot figure out what to change in my preferences. What has happened?
best,
Hans Wessels
Premiere CC
Mac Pro OSX 10.7.5
16 GB 1066 MHz DD3
2 X NVIDIA GeForce GT 120 512 MB

Performance issues with respect scheme registration,select & insert query

I am facing performance issues with respect to schema registration,Select & insert query towards 10.2.0.3 version.It is taking around 45 minutes to register schema and it is taking around 5 min to insert a single document into xml db where as it was taking less than min to insert a single document into xml db of 9.2.0.6 version.Would like to know the issue and solution to resolve this issue.Please help me out on this as it is very urgent for me

Since it appears that this is an XML DB specific question, you're probably better off posting in the XML DB. The folks over there have much more experience with the ins and outs of that particular product.
Justin

Performance Issue with VL06O report

Hi,
We are having performance issue with VL06O report, when run with forwarding agent. It is taking about an hour with forwarding agent. The issue is with VBPA table and we found one OSS note, but it is for old versions. ours is ECC 5.0. Can anybody know the solution? If you guys need more information, please ask me.
Thanks,
Surya

Sreedhar,
Thanks for you quick response. Indexes were not created for VBPA table. basis people tested by creating indexes and gave a report that it is taking more time with indexes than regular query optimizer. this is happening in the funtion forward_ag_selection.
select vbeln lifnr from vbpa
     appending corresponding fields of table lt_select
     where     vbeln in ct_vbeln
     and     posnr eq posnr_initial
     and     parvw eq 'SP'
     and     lifnr in it_spdnr.
I don't see any issue with this query. I give more info later

Performance issue with BSEG

Hi,
          I am having serious performance issue due to BSEG table .I am having a change request in which I have to solve the performance issue with regard to BSEG. The situation was that previously they had used select * on both BKPF and BSEG. I removed the select * and selected only those fields which are required as shown below. I also tried using cursors. But the problem is happening in the TEST server where BSEG is having more than 1 crore entries. I have gone through some threads but still not able to understand how to solve this problem. Please help
select bukrs belnr gjahr bldat bstat from bkpf into table T_BKPF_p
                                                WHERE BUKRS IN sd_bukrs AND
                                                BLDAT < s_bldat-low
                                                and BSTAT = ' ' .
select bukrs belnr gjahr shkzg dmbtr hkont from bseg into table T_BSEG_C
                                        FOR ALL ENTRIES IN t_BKPF_p
                                        WHERE BUKRS = T_bkpf_p-bukrs
                                        AND   BELNR = T_bkpf_p-belnr
                                        AND   GJAHR = T_bkpf_p-gjahr
                                        AND   HKONT = SKB1-SAKNR.

Hi Kunal,
Here is my take on your issue.
In your select statement on BKPF you are selecting every BKPF record for a specified company code and blank document status that was created before a specified date. If your company has implemented SAP 10 years ago, and your user enters todays date and leaves the company code field blank you will effectively be retrieving almost all the records from BKPF (excluding the ones created today or those with non-blank document status). This would effectively be a huge amount of data. After that you are looking for the corresponding BSEG records for all the records that you have selected in BKPF.
My question to you is why do you need to look at all the records before a given date? Why not ask the user to enter a smaller date range and make the document date and the company code a mandatory entry? You do not have to look at 10 years worth of data especially if you are running this online (as opposed to in the background).
Your BSEG select looks correct. There is very little that you can do except for adding BUZEI to the field list. If you use for all entries and do not include the entire primary key you could lose data.
TABLES: bkpf,
        skb1.
SELECT-OPTIONS: s_bldat FOR bkpf-bldat OBLIGATORY,
                sd_bukrs FOR bkpf-bukrs OBLIGATORY.
TYPES: BEGIN OF ty_bkpf,
        bukrs TYPE bkpf-bukrs,
        belnr TYPE bkpf-belnr,
        gjahr TYPE bkpf-gjahr,
        bldat TYPE bkpf-bldat,
        bstat TYPE bkpf-bstat,
      END OF ty_bkpf,
      BEGIN OF ty_bseg,
        bukrs TYPE bseg-bukrs,
        belnr TYPE bseg-belnr,
        gjahr TYPE bseg-gjahr,
        buzei TYPE bseg-buzei,
        shkzg TYPE bseg-shkzg,
        dmbtr TYPE bseg-dmbtr,
        hkont TYPE bseg-hkont,
      END OF ty_bseg.
DATA: t_bkpf_p TYPE TABLE OF ty_bkpf,
      t_bseg_c TYPE TABLE OF ty_bseg.
SELECT bukrs
       belnr
       gjahr
       bldat
       bstat
FROM bkpf
INTO TABLE t_bkpf_p
WHERE bukrs IN sd_bukrs
AND   bldat IN s_bldat
AND   bstat EQ space .
IF NOT t_bkpf_p[] IS INITIAL.
SELECT bukrs
         belnr
         gjahr
         buzei
         shkzg
         dmbtr
         hkont
    FROM bseg
    INTO TABLE t_bseg_c
    FOR ALL ENTRIES IN t_bkpf_p
    WHERE bukrs EQ t_bkpf_p-bukrs
    AND   belnr EQ t_bkpf_p-belnr
    AND   gjahr EQ t_bkpf_p-gjahr
    AND   hkont EQ skb1-saknr.
ENDIF.

Performance Issue with RF Scanners after SAP Enhancement Pack 5 Upgrade

We are on component version SAP ECC 6.0, and recently upgraded to Enhancement Pack 5. I believe we are on Net Weaver 7.10, and using RF scanners in one plant that is Warehouse Managed. Evidentially when we moved to EHP5, the Web SAP Console went away and we are left with ITS Mobile. This has created several issues and continues to be a performance barrier for the forklift drivers in the warehouse. We see there is a high use of java script, and the processors canu2019t handle this. When we login to tcode LM00, on a laptop or desktop computer, there are no performance issues. When we login to tcode LM00, with the RF scanners, the system is very slow. It might take 30 seconds to confirm one item on a WM Transfer Order.
1.) Can we revert back to Web SAP Console, after we have upgraded to EHP5?
2.) What is creating the performance issues with the RF Scanners now that we switched over to SAP ITS mobile?
Our RF Scanners are made by Intermec, but I donu2019t think that is where the solution lies. One person in our IT Operations has spent a good deal of time configuring SAPITS to get it to work, but still it isnu2019t performing.

Tom,
I am sorry I did not see this earlier.
I'm currently working on a very similar project with ITS mobile and the problem is to accurately determine the root cause of the problem in the least amount of time. The tool that works is found here: http://www.connectrf.com/index.php/mcm/managed-diagnostics/
Isolating the network from the application and the device is a time consuming process unless you have a piece of software that can trace the HTTP transaction between host and device on both wired and wireless side of the network. Once that is achieved (as with Connect's tool) you can then you can begin to solve the problem.
What I found in my project is that the amount of data traffic generated by ITS mobile can be reduced drastically, which speeds the response time of the mobile devices, especially with large number of devices in distribution centers.
Let me know if I can answer more questions related to this topic.
Cheers,
Shari

Serious performance issues with no solution in sight

Similar Messages

Maybe you are looking for