Recommended Hardware

midder wrote on Wednesday, August 17, 2011:

Hello

I would like to get some feedback on what the recommended hardware configuration might be for running OpenEMR on a local server. I have setup OpenEMR on a Windows machine, but the performance is questionable, especially the calendar. I will try next on an Ubuntu machine, to see what the difference is.

Any feedback on hardware specs would be great. I will be running the entire LAMP stack on one machine. We have about 15 providers that may show up on the calendar, so the performance of the calendar is key in this instance.

Thanks.
Brian

cverk wrote on Wednesday, August 17, 2011:

Before giving up on your windows server, try this trick.  Through control panel go to network and internet/internet connection. Highlight your connection and select advanced/advanced settings.  From there uncheck and turn off IPV6 for greatly enhanced performance. You do not have to do this on any of your workstations, just the server. I think this is because of the older xampp version used for openemr doesn’t play too well with IPV6 protocol. But then again, I am a doc  and not a programmer.

midder wrote on Wednesday, August 17, 2011:

Thanks for the reply.

I don’t think that the issue on the Windows machine is network-based. It’s CPU-based. When I spin up the OpenEMR calendar through XAMPP, the Apache HTTP Server and mysqld processes basically max out the CPU and it takes a noticeably increased amount of time for it to return. I am not using a packaged version of OEMR. I have installed/configured it inside of XAMPP on my own. I’ve actually done it outside of XAMPP and the performance is basically the same.

Most (all?) other pages/processes are fine. But the calendar is unacceptable. Since this is what is used most by the front-office staff, and since the front-office staff is the most vocal about it, the issue gets lots of attention.

For what it’s worth, I am currently hosting this on a VPS where the performance has been acceptable. We just wanted to move it in-house for various reasons - mostly security, latency issues, reliability. When I made the proposal and showed the demo on my laptop, there were obvious concerns with the speed. So I need to come back with a solid proposal for hardware and an ultimate cost for the move (including backup, etc.).

yehster wrote on Wednesday, August 17, 2011:

Spec out any desktop class machine with an i7 2600 8GB+ of RAM and an SSD instead of a mechanical hard drive.  I think you can get such a machine for ~$1000.  Consider getting 2 SSDs and run it as RAID 1.  Desktop machines are so cheap these days you should pretty much just get top of the line everything except skimp on the video card.
I’ll bet that a $400-500 i3 machine with mechanical drives would be sufficient, but the extra money for future proofing would be worth it IMHO.

FWIW, I remember programming my first computer with 4K of RAM.  My have times changes.

midder wrote on Wednesday, August 17, 2011:

Thanks for the feedback. I was thinking of doing pretty much exactly that, but was curious what others are doing. Are there people out there successfully running OpenEMR on Windows with acceptable performance?

What about offsite backups? I was thinking incremental MySQL backups every 6 hours to some cloud storage and then full backup every weekend.

cverk wrote on Wednesday, August 17, 2011:

After turning off IPV6, I am running 6 workstations, one of which is just a windows 7 netbook, without any visible lag on a window 7 pro machine with a quad core processor, 4GB of ram, and raid 1 hard drives. It was only about $650. I am backing up for free as included with qwest dsl service online encryted backup and usb thumb drives. My guess is that my setup is the absolute bare bones for a solo doc, so you probably need a full blown multiple CPU server for 15 providers. Hopefully some bigger practices will give you some input here.

yehster wrote on Wednesday, August 17, 2011:

I wonder if using eAccelerator or another PHP accelerator like APC or memcache would impact your performance in any significant way. 

midder wrote on Wednesday, August 17, 2011:

I think that the calendar would benefit in a huge way from some sort of caching mechanism. In my experience it is by far the most CPU-intensive part of the app. That would be a tricky implementation, as the data on the calendar is very dynamic.

anonymous wrote on Wednesday, August 17, 2011:

You really need to have run some performance benchmarking to figure what is causing those delays. You can’t just guess CPU or network or solid state hard drives. First, pinpoint the cause of the problem or the affected hardware then deal with it. Reading about Performance Monitor for Windows will help you troubleshoot your issues. Also, be aware that a VPS is using server-class hardware as opposed to your desktop computer. Also, the load that a system can handle is not measured by the number of providers using the system. It will be more about what OpenEMR is doing and how much of it is running at the same time. For example, SQL searches like reports and encounters will spin the CPU/memory/drive.

JP

yehster wrote on Wednesday, August 17, 2011:

Configuring eAccelerator is a matter of tweaking your php.ini file after googling about it.  Shouldn’t be that tricky to try and see.  Under linux, memcache or apc are easy to use. 

Profiling the offending calendar code and truly identifying the bottleneck would be a good “to do.”   Is your “calendar performance” an issue even with a relatively empty schedule?

OpenEMR really isn’t/shouldn’t be that intensive of an application. Yes, there are bottlenecks, but any issues are fundamentally about poor software/coding practices (like trying to return all encounters in one batch or not properly indexing the database.) 

I disagree with the notion that “server-class” versus “desktop-class” is really a significant factor for OpenEMR.  The VPS may be using better underlying hardware, but there is an overhead for virtualization, and they are sharing that virtual server with other users. 

None of us have numbers to back up our statements, but the calendar code is based on work that is at least 9 years old. (The postcalendar README is dated 2002).  If desktop class hardware isn’t fast enough compared to server class hardware from back then to handle 20 simultaneous users, then we’ve got some really bad PHP code.

minus7 wrote on Wednesday, January 21, 2015:

Hi
I note that this thread is from 2011.
Have requested help with an appropriate computer from local IT source to use as an onsite server “Going forward” in 2015. We are e-mailing this link to him and will appreciate current thinking in this connection.
Thanks
Scotthttps://sourceforge.net/p/openemr/discussion/202504/thread/c48161d4/#

fsgl wrote on Sunday, February 01, 2015:

If the practice in question is solo, pretty much anything you get will be fine; provided that the main server is a desktop while the other auxiliary devices can be netbooks.

By the time you run out of disk space, it will be time to get a new set anyways.