3

In my system there are different kind of request having different range in terms of memory cost and time cost.

That is, if there are types of requests R1, R2.....R100, the amount of RAM required to process the request and the response time of these request types varies a lot, even by a margin of 10 to 100 times.

Should round-robin be the right method for such scenario or does round-robin will eventually cover up most scenarios in this situation?

If round-robin is not the right choice, then are there more customizing options available on apache?

gurvinder372
  • 66,980
  • 10
  • 72
  • 94

3 Answers3

3

Normally I would say once you're dealing with sufficiently large # of requests, plus factoring in stickyness, it's just not worth worrying about because it will tend to even out.

But if some requests are 1 or two orders of magnitude more expensive for the backends, you might consider "bybusyness" or "bytraffic" if those expensive requests happen to take longer to process or generate large responses. Under lower loads, this will give you better chances for not having 1 backend get unlucky and handle too many expensive requests in parallel (stickyness aside).

covener
  • 17,402
  • 2
  • 31
  • 45
  • bytraffic doesn't seem to be a good option since the get request size will be of similar size, only response will be bigger. bybusyness seems like a better option but is there any source of best practices using bybusyness or analysis of how it weighs against byrequests? – gurvinder372 Dec 22 '15 at 04:51
  • By traffic is response bytes, no? – covener Dec 22 '15 at 05:35
  • Nope. It is by request bytes. How can apache know the response size in advance and do routing accordingly? – gurvinder372 Dec 22 '15 at 07:16
  • You don't need to know in advance. You can count bytes written on all previous responses and choose who has written the least over some time interval to. Never realized what the available one did – covener Dec 22 '15 at 15:52
  • how do I do that on apache? – gurvinder372 Dec 23 '15 at 05:29
  • 1
    bytraffic includes response size: "Then we mean that we want b to process twice the amount of bytes than a or c should. It does not necessarily mean that b would handle twice as many requests, but it would process twice the I/O. Thus, the size of the request and response are applied to the weighting and selection algorithm. – covener Dec 23 '15 at 05:57
  • I am awarding you the bounty since you have shown the interest in this question, though I have selected my answer since that seems to be the right one. Thanks for your interest. – gurvinder372 Dec 28 '15 at 05:54
1

Should round-robin be the right method for such scenario or does round-robin will eventually cover up most scenarios in this situation?

We did a 36 hour run (duration stress test) and 4 hour run (peak stress test) with full volume data for 50 concurrent users, 100 concurrent users and finally 350 concurrent users. There wasn't any difference in the CPU and RAM utilization among the different VMs which we were trying to do load distribute.

We did multiple such runs and the difference between CPU and RAM utilizations were not significant enough.

So, I think it will be fair to conclude that round-robin does cover a lot of scenarios including this one and is the right method to use for load distribution in this scenario.

gurvinder372
  • 66,980
  • 10
  • 72
  • 94
0

Round robin algorithm sends requests among nodes in the order that requests are received. Here is a simple example. Let’s say you have 3 nodes: node-A, node-B, and node-C.

• First request is sent to node-A.

• Second request is sent to node-B.

• Third request is sent to node-C.

The load balancer continues sending requests to servers based on this order. It makes to sound that traffic would get equally distributed among the nodes. But that isn’t true.

Read more here to know in detail: What is the problem with Round robin algorithm?

Jim T
  • 101
  • 4