FOR THE SERVER:
On XP I always do a batch file to shutdown -r -f -t 05
and schedule it to run once a month in the middle of the night, at a time that doesnt affect autosequences.
I have 30 terminals and it seems like every week they are starting to slow down or lag on Saturday nights. They are trying to tell me its because its not rebooted enough. It a new system less than 4 months old
OK then, so thats a few terminals, that makes you pretty big. I am surprised they didnt suggest Simphony / 9700. There is an upper recommended limit of 25 clients. At your level Micros would recommend quite a few Win32 (XP-pro) clients, on platforms such as the 2010 to take some of the load off the server. Your server would also be running Server 2003 as the OS, and ideally 4-8 GB ram. RES4 does not utilise multiple cores / processors affectively, so quad core etc would not give you any significant performance increase.
In your case I would schedule a monthly shutdown / restart of the server, just for peace of mind, to see how that affects performance.
The next thing to look at would be printing etc, and how I came to that decision. If you look at their IDN printing concept, the controller for the printer becomes the workstation that controls the printer. Say I have a waiter till that has a local IDN printer (IDN1 say) and also the larder printer (IDN2 say), an order goes:
Ordering Station > Server > printer controlling station > IDN1 > IDN2
So you can see the station someone else is using, can get a slow terminal. My rule is for ALL order devices to be ethernet, so the SERVER can send the print job to that device directly. Besides performance benefits, the terminals can now be moved around if there are break downs somewhere.
Another consideration would be network speed, traffic and capacity. Micros WS have 10/100 MBS network connections and if you have a gigabit network switch, there may be VOIP and other network traffic. I would have a separate switch for my POS system and an uplink to the rest of the network (if on it). You could even go so far as to put POS on a separate network mask.
Lastly would be to consider other apps that may be running on the server, check your antivirus and see if there is something with a better performance or to stop it checking your Micros folders. Are people running reports, etc. Is the server also being used as a file server by the office... Keep POS purely for POS.
Yeah its a pretty big system 24 ws5a , 6 tablets, a hostess terminal running on a pc, 18 Kds screens and 7 runner printers. Have a pair of hp servers running 2003. We went 3700 to get all the addons, mymicros,mylabor etc. it's on it own vlan and all of the workstations, Kds and servers are on the same 48 port gigabit switch. Not using the server for anything but micros
I'm beginning to think its all the addons bogging it down. We have had to shut off my labor a couple weekends for doing a database refresh every 15 minutes at all the workstations.
I guess for now I'll have to start rebooting it every Friday
At this point it sounds like pure tweaking and massaging of the system is needed. I think you will find the problem comes back to all the WinCE client, especially if all the KDS units are the standard Micros CE boxes. They are impressive, about the size of 4 packs if cigarettes, but they are WinCE 6. WinCE is an RTOS.
I think the solution would be more XP clients, as they recommend. My largest client has 18 workstations, 12 * WS5s and 6 * 2010, no KDS. No backup server, just an HP ML350 gen 6, works seamlessly.
You might find the secret is to start replacing the CE clients / controllers with 32bit XP clients. There is no reason a KDS controller cant be XP, and will take processing load off the server.
DrZogg would running the server checkout reports on a win32 terminal help our slow/freezing when the 50-60 server all cash out at the same time around 10pm when our night club is starting just slam the system also?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.