openflagr/flagr

Flagr post endpoints does not work well with concurrent requests

AngieAngieLiu opened this issue · 3 comments

Flagr does not work well when there are concurrent post requests. Our service needs to create multiple constraints at the same time and flagr's response time for each request increases for each request. See screenshot. Response time went from 1s to 5s for each of the post constraint request.
Screen Shot 2022-10-17 at 12 19 57 PM

We are using WebClient to make the requests.

public Mono<Condition> createConstraint(
      final long flagId, final long segmentId, final Condition constraint) {
    return http.post()
        .uri(
            host,
            u ->
                u.path("/api/v1/flags/{flagID}/segments/{segmentID}/constraints")
                    .build(flagId, segmentId))
        .bodyValue(constraint)
        .retrieve()
        .bodyToMono(Condition.class);

Expected Behavior

For concurrent requests, the total time take to create all the constraints should not be longer than creating one constraint.

Current Behavior

For concurrent requests, the total time take to create all the constraints takes longer as number of request increase.

Possible Solution

  1. Batch create contraint/segment endpoints in flagr.
  2. Handle concurrent requests.
  3. Are there any suggestions to update how we make requests to alleviate this issue?

Steps to Reproduce (for bugs)

Context

This is causing the constraints creation time to delay when there are a lot of constraints to create and eventually our server timeout.

Your Environment

  • Version used (flagr version): 1.1.13
  • Server type and version:
  • Operating System and version (uname -a):
  • Link to your project:

our docker file:

ARG DOCKER_REPO

FROM checkr/flagr as flagr
FROM $DOCKER_REPO/alpine:3.12.1-master

# checkr/flagr go image is built with CGO enabled (CGO_ENABLED=1) which produces a binary with some dynamic linking,
# in this case to glibc. Since our base alpine image does not have glibc installed, we need to install it in our docker
# image so that checkr/flagr can run as expected.
USER 0
RUN apk --no-cache add ca-certificates wget
RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.28-r0/glibc-2.28-r0.apk
RUN apk add glibc-2.28-r0.apk

COPY . /opt/flagr
WORKDIR /opt/flagr

COPY --from=flagr --chown=narvar:narvar /go/src/github.com/checkr/flagr /go/src/github.com/checkr/flagr
COPY --chown=narvar:narvar ./flagr-start.sh /opt/flagr/flagr-start.sh
COPY --chown=narvar:narvar ./startup.sh /opt/flagr/startup.sh
RUN chmod +x /opt/flagr/startup.sh
RUN chmod +x /opt/flagr/flagr-start.sh

ENV HOST=0.0.0.0
ENV PORT=18000

CMD ["sh", "-c","/opt/flagr/flagr-start.sh & /opt/flagr/startup.sh"]

@AngieAngieLiu I'm not sure Flagr was designed for this use case, I could be wrong. I've only just started looking into it myself. From what I can tell and would make sense in a feature flag service is its designed for high readability but not writability. Anticipating a handful of create requests with many many reads.

How many constrains do you need to make and how frequently?

Stale issue message

@AngieAngieLiu I'm not sure Flagr was designed for this use case, I could be wrong. I've only just started looking into it myself. From what I can tell and would make sense in a feature flag service is its designed for high readability but not writability. Anticipating a handful of create requests with many many reads.

How many constrains do you need to make and how frequently?

The request for batch update is not frequent, a few times a day at most. But each time these requests are made we need to create about 60 segments and for each segment 3-4 constraints need to be created.