Hey all,
Just wondering if anyone here has gone down this road of deploying multiple websites, as well as an Interop server to help increase CPS performance and if you have, how was/is your experience with doing so? Our sites are growing larger and larger, with what seems like more concurrent users every day. We keep taking other locations under our belt, and we're to the point now that things are growing at a very alarming rate and I'm trying to be proactive and prepare our environment for a transition. Right now, our environment consists of right at ~485 concurrent users, which is close the the recommended action of using 2 JBOSS (GUI) + 1 Interop config per GE's spec list.
I'm just trying to figure out if moving from a single GUI server and Interop setup will be worth it for our users, and if it's as easy as uninstalling JBOSS on the single server, pointing Server Configurator to have a "multi-site" option and have it classify two GUI servers (the original JBOSS, along with the new one), along with our current Interop in the mix as well. We run fat clients at our locations, so I'm trying to avoid having to reinstall CPS and going through a bunch of hoops to get things working correctly.
My ultimate goal is to increase performance for my users, while also not creating more of a hassle for my team by having to reinstall and re-point our users. I realize that if I deploy a secondary GUI, that I will be manually load balancing, which is fine because I have an idea of which locations I want to migrate to the second server and divert their traffic. If we go this route, we will be manually re-pointing the users to the secondary GUI server via the CPS link.
Any input/feedback from users that have done this would be helpful and much appreciated. Thanks.
How does your CPU usage look during the day on your App server?
I was somewhat surprised when I found that we were only at 10% cpu all day until CQR starts running at night with ~300 users.
When you're on the Console itself viewing the performance tab, it ranges from around 5% to 75% at random intervals. Java is most notably the performance hog here, which isn't surprising by any stretch (RAM that is..). GUI is consistently consuming around 75% of RAM throughout a normal day as well. Generating both real-time and "1 day summary" reports from VSphere show that CPU still ranges from high to low usage throughout the day. We used to see very high utilization at night before we deployed the Interop server a while back, but has been significantly cut down since those operations have been shifted to an entirely different server. Since we don't have users at night, our daily EMR users don't get to see much benefit of our current configuration, so the reports of slowness are at a steady stream from all locations.
I would expect the amount of memory used to be fairly consistent as Java reserves HEAP memory when it starts the app IIRC.
Have you graphed the CPU utilization over the course of the day? If you could correlate speed complaints with average CPU during a time of day perhaps you could narrow down whether or not the App server is a bottleneck.
We are still on a single server but we were looking at deploying a second but since CQR is 100% at night now (when we are closed) the only advantage of adding the interop server would be to offload a few of our qvera interfaces which run off of JBOSS (processing CCDA files in/out).I was contemplating if adding a second APP server would help with any speed issues but at this point I think adding resources to the DB server would be a better use of money.
Are you on SSD drives for your db?
In terms of mapping the performance utilization, it's been more of a "glance" rather than a full deep dive analysis. I believe the bottleneck may lie in the DB itself, but we're limited on what we can currently do to change that because of software conflicts (see below).
We are not currently using SSD drives on the DB. We currently access our network SAN, which is relatively fast, but when comparing price/performance, SSD's are more than likely always going to come out on top depending on the make/model and deals you can pick up.
We did have an implementation specialist from GE recently come in an evaluate what he thought our environment could benefit from in order to better the performance of CPS in general and upgrading the resources on the DB end was one of the first things pegged on the list. Currently we are running 2008 R2, which is one thing that we are shifting focus on relatively quickly to bump up to 2012 R2 (which is still finicky with our testing on CPS). Are you guys running SQL enterprise? We are currently not...which is definitely a limiting factor, because that would require us to buy the license, use two additional CAL's to spin up a new server to use it on, shift the resources from our blade pool and pour in the recommended specs just to accommodate the transition and then basically reconfigure the entire CPS environment and do manual re-installs.
We are by no means a giant when compared to other locations, but I just don't trust the recommendations completely, especially when you're putting the numbers down on paper.
I run Cacti to monitor server CPU usage over time using SNMP. It was a bit of a beast to get setup initially but it give me nice graphs to watch trends in usage. There is other software out there, such as PRTG, that is probably easier to setup.
We are currently 100% on SSD drives (local to the server) on our DB server. Keep in mind that a single SSD drive, from what I have read, has about the same IOPS as around +10x 15k rpm drives. Our DB server runs off of 7 SSD's so that would take ~70 spindles in your SAN to match the performance. Our test environment runs on spinning disks and it is considerably slower despite the fact that it is on newer hardware.
We are running C-EMR which is Oracle based so the rest of your questions do not relate to your scenario. FYI, your profile says you run C-EMR (oracle) and CPS.
Not sure why I have my profile set like that, but we are definitely CPS only, so thanks for the heads up there. As far as migrating to SSD for DB purposes, was the switch painful? I wouldn't think that this transition would be too terribly difficult and I'm sure we'd see a huge boost in performance.