Best Ideas to Separate QPR Servers for Better Performance

7 posts 0 new
Log in or register to post comments.

Best Ideas to Separate QPR Servers for Better Performance

Hi,

I am using the QPR Metrics. I want to ask QPR developers and experts, what is the best idea to separate each QPR server on a single VM ?

Is there any advantage with deploying the Metrics server on an independent server to Web server and Foundation server? and if yes, what is the best suggestion to do this with the lowest cost of resources?

I appreciate your kind responses.

I've never seen the Metrics server been on different server than the Foundation server. The scenarios I know are the following:

  • everything in one server
  • server softwares in one sever + database server
  • Foundation server and QPR Metrics server in one server + Web application on its own server + database server

Maybe other know better.

Thanks for your reply.

As far as I understand, you suggest to have a machine for Foundation server + QPR Metrics server and another machine for web application server + database server. sounds good as we are using SQL Server as DBMS for QPR.

Let me know if I'm wrong.

Thanks.

 

Some ideas from my side:Do you have an idea, which component is causing the bad performance on your environment?If you have the DMBS and QPR installed on one machine, have a look to the memory usages of DBMS and the QPR components. (What has been configured with configuration manager?)

DBMS can perform heavy I/O on the machine next to memory usage and calculations, while the QPR components "normally" cause memory usage and CPU load.

If you split DBMS and QPR into two machines, bringing them physically near to each other (as few network hops as possible).This has a significant impact on the data exchange from DB to the application servers.

Hope this helps.

Good Idea Christoph!

Currently the DBMS eats almost the whole memory, causing the QPR components starve. Also I often run the Metrics Client from the same machine which QPR servers are installed and it gets worse. I agree with you about separating the DBMS from QPR because I believe it causes the performance issue. 

We schedule the "SQL Mass Imports" to start running and getting data every midnight, (there is lots of them) and the question is, while queries are running, which component is the most  resource consuming, DBMS or QPR components? there are some long lasting operations like running queries(DBMS), calculation(QPR), I/O(DBMS),  managing data(QPR) ,.... .  Having these side by side may cause serious performance issus. 

So I am going to install the 2015 version on a new server and leave the old server for the DBMS itself. 

Thanks for participating.

Here are some good practices for avoiding performance issues:

  • By default SQL Server is allowed to consume all available computer memory, causing problems to QPR components. In reality, SQL Server works perfectly for smaller amount of memory. Instructions for limiting SQL Server memory: https://technet.microsoft.com/en-us/library/ms191144(v=sql.105).aspx.
  • It's difficult to say what amount of memory is enough for SQL Server, but I think 0,5 - 1,5 gigabytes is enough if there is only QPR database in the server. If memory limit has been set too low, out of memory errors are thrown by SQL Server when running queries. In practice, QPR servers may crash, but the situation can be identified from QPR logs.
  • Never allow a situation where there are no available free memory for QPR components. QPR will start to function unreliably, and the cause may be impossible to analyze from QPR logs. If there are stability issues with QPR, available system memory is always the first thing to check.
  • There may be other resource consuming processes in the server, causing it hard to detect that there may be temporary situations when memory is running out. To be sure what's happening in the server when you are not watching, Windows Performance Monitor is the right tool. It can be used to record e.g. processor load and memory consumption so that they can be analyzed afterward. More information: https://technet.microsoft.com/en-us/library/cc749249.aspx.
  • In addition to memory, another bottleneck for system performance is processor speed. It has an impact especially on QPR service startup time and Metrics model calculation. Note that a single thread process may only use one processor core at a time, and that may explain why processes speed is a bottleneck although there is free processor capacity in the system. Still, processor speed is not so critical as memory, because slow processing performance hardly causes stability issues.

Thanks for your advice Olli, the tip for limiting SQL Server memory usage was very helpful.