LS retail is dead slow

fahd

Dear Experts,
I've been using Nav for the last 6 months version 5.01. But In my outlets, LS retail is dead slow.When My Sales guys scan the item it takes almost 3 to 4 seconds to bring the item visible.

I thought it might be RAM problem.I have upgraded the RAM to 2GB but still there is no difference in the speed.

One transaction is taking almost 5 minutes to process this is really annoying & it's happening to all the outlets. I have tried to go to FILE>DATABASE>INFORMATION. selected all and clicked Optimized, it took sometime & finished.


Kindly let me know as how can i speed up this.IT is taking 1 whole minute to post the transaction and to print.

PLZ PLZ let me know. ](*,) .

kulwant

You can use Client Monitor(Tools->Client Monitor) to know the bottleneck.

Belias

@fahd: from what you said in your post, i guess that you're probably not a developer, but a customer who tries to solve the problems alone. This is a good thing when you know what you're doing, but don't try to find a solution to such a difficult problem. Talk with your solution center and they will ask a ton of question about how many users you have, how big is your db, what is your hardware etc etc...as you can see, there are many variables that can slow your system; client monitor can probably evidence the bottleneck, but you have to be able to use it.

in the end, my suggestion is: ask a solution center, before damaging your system

rmpatel22

@fahd,

Belias's suggestion is absolutely right. May be your implimentation partner would have done some customization and because of it its slow, so they can rectify problem easily. Default LS retail (without any customization) is working fast on POS with low configuration also.

fahd

Dear Kulwant/Belias,
First of all Thanks alot for the replies.

@Belias, im in UAE. The implementation guys were outsourced. And i've told them that this is what's been happening but they told me to search it in the internet. They are not giving me any proper answer for this.

And yes im not a programmer as well.
I am facing this problem for a long now.

@Kulwant, I will check the client monitor.

Thanks alot guys please try to find the solution for me.

Will be very great full!!

Belias

fahd wrote:

@Belias, im in UAE. The implementation guys were outsourced. And i've told them that this is what's been happening but they told me to search it in the internet. They are not giving me any proper answer for this.

:shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock:
why in the hell a partner don't give you assistance?!?!?!
if you're paying them, they MUST give you assistance, if they can't, just change the partner!!

Now, do some math: mastering the usage of the client monitor will take you some days (let's say 2); finding the bottleneck (if you can find it with client monitor) will take you just a pair of hours, BUT: after finding the bottleneck, you have to know C/AL to correct the code in the correct way and/or you have to be able to add some keys or dropping some other...
mastering C/AL will take you some years.
If you're not lucky, you won't be able to find the bottleneck through client monitor; the problem can then be related to hardware configuration, SQLserver configuration, network speed...mastering all of this will take you some other years

Oh yes, you must have a developer license to change the code...
Morale: after some years you will solve your problem OR you can find a better partner to solve your problem

rhpnt

Are all your outlets connecting to the same DB? Is that DB on a SQL Server or a native one? What is the connection type (via VPN-RDP, VPN-TCP/IP,...)?

Such symptoms are typical for installations where remote locations connect to the same DB directly that means via (or not) some VPN connection using the TCP/IP protocol. If that's the case the speed of NAV depends on the speed of the Internet (WAN) connection which in many cases is to slow to handle the data traffic. For such installations an exclusive WAN connection (no web surfing, mailing, chatting or downloading) with a bandwidth of 10/10MBit min. is needed to provide a decent ERP behaviour.

Hope this brings you further...

fahd

Hi rhpnt,
Well all the outlets are having their own local DB. and im just replicating the data. not only this when i click on LS backoffice and click on retail Item list it takes tooooooooooo much time to display the items.

it says searching the item the scanning of items is taking too much time which freaks me out.

Thanks,
Fahdp

Belias

if it says "searching item", some key is probably missing in the item table: if so with client monitor you should be able to find what key(s) is missing...
moreover, you didn't say if it's sql or native db...

fahd

It is native....

rhpnt

How many retail/POS systems are located in one outlet? Does every POS system have its own DB or is the DB on a separate server machine located at the outlet? What kind of replication are you talking about - how is it done?

How many entries are there in the Item table? On which field in the Item table does the POS scan search? Is there any particular sort order when you open the Item form? How many keys are enabled in the Item table?

Regards-RH

Belias

i think that someone forgot some "SETCURRENTKEY" here and there before setting the filters. this causes a lot of performance issues in native db, because the best (or at least a good) key is not automatically selected...
client monitor, at all costs!

kapamarou

fahd wrote:

The implementation guys were outsourced. And i've told them that this is what's been happening but they told me to search it in the internet.

:-#

I think you should get some professional help for this.
As Belias said, the dialog you see is most likely caused by a forgotten SETCURRENTKEY.

But you need to investigate the exact cause of the problem. Before you make any changes you need to make sure that by changing the sort order, for example, you don't change the logic and produce wrong data.

Belias wrote:

find a better partner to solve your problem

That's the best advice.

jannestig

I have worked on a few LS retail installs and generally it works quite well,

Generally when setting up the POS machine database LS will install a classic DB for replication and transaction processing due to some performance issues with SQL express.

I would imagine what the outsourcing partner has done is taken a copy a POS database and changed the name and replication setup for each new outlet replication location and each pos itself.

If you have have set store replication for sales lines to be automatic IE every transaction must go to POS DB and then back office you are causing double the transaction bulk.

This should be changed to once and hour or preferably once a day depending upon your transaction bulk.

If the scanning of items processing is your main concern espically if customers have many items to each transaction you should get an LS Retail partner to review your pos hardware setup and check correct driver are ready EG do you have XP POS ready as your OS?

Either way avoid a normal NAV reseller, and i imagine you got an idian outsourcing partner to do it, they are usually jokes and you end up with situation. Contact LS retail directly and ask them to recommend you a partner. I know the AIrports in the UAE where we installed LS retail have no such issues.

rhpnt

I agree with my fellow repliers that your story points to a NAV/LSR low budget implementation which in such combination is not compatible. I doubt that you (even with our help) will be able to solve the problem. You should ASAP find a company which is MS Certified and has a NAV/LSR competency with good implementation references. Such companies are expensive but they are worth the money once troubles hit the road.

rmpatel22

You can contact Landstainer Dubai (http://www.landsteinardubai.com), we have support contract with them.

fahd

Dear All,
Thanks alot for so much support i will contact the team here for the this problem.

GOD BLESS YOU!

kashif27

Are you doing data Archiving in your POS Database.

rsoobhany

Hello Fahd,

Have you found the solution to the slow performance of LS Retails POS. I am facing the same situation, where (whether with local or remote database, though the problem is more acute with remote database), that when an item is scanned, it take 3-4 seconds to appear on the screen and if we scan more than 50 items, then the performance degrades much more (10-15 seconds for the item to appear on the screen).

richie

A responsible for 25 stores (native db) and aprox 450 POS (replication method).
I don't know if you solved your problem but here are a few thinks you can do to speed up the searching on POS based on my personal experience.
1.Under Tools,Options you can add some KB to the object cache and DBMS cache (respectively to the POS ram).
I always put 32000 for object and 8000/16000 for the DBMS. Try to find your configuration.
2.Delete non moving items, old barcodes, variants not in use and even old retail prices to reduse the size of the item/barcode/sales price/variant tables.
These are some of the things you can do without being a developer. There are a lot to do from a developers site and it is recomended to get in touch with one for further investigation.

kriki

richie wrote:

A responsible for 25 stores (native db) and aprox 450 POS (replication method).
I don't know if you solved your problem but here are a few thinks you can do to speed up the searching on POS based on my personal experience.
1.Under Tools,Options you can add some KB to the object cache and DBMS cache (respectively to the POS ram).
I always put 32000 for object and 8000/16000 for the DBMS. Try to find your configuration.
2.Delete non moving items, old barcodes, variants not in use and even old retail prices to reduse the size of the item/barcode/sales price/variant tables.
These are some of the things you can do without being a developer. There are a lot to do from a developers site and it is recomended to get in touch with one for further investigation.

DBMS cache should be as high as possible. 8000/16000 is WWWWWAAAAAAYYYYYYY to low. Try something like 800MB (and also use commitcache). But do not set it too high so that your server starts swapping to disk.