graphql-engine/server/src-test/Control/Concurrent/ExtendedSpec.hs
Brandon Simmons 9a96e7d165 server: parallelize buildGQLContext to improve replace_metadata perfo…
…rmance

It makes sense to try to utilize multiple threads for metadata
operations since we expect them to come one at a time (and likely at
lower load periods anyway).

As noted, although we build roles in parallel now, the admin role is
still a bottleneck. For replace_metadata on huge_schema, on my machine
I get:

  BEFORE: 22.7 sec
   AFTER: 13.5 sec

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3911
GitOrigin-RevId: 4d4ee6ac8b5506603e70e4fc666a3aacc054d493
2022-03-09 02:27:42 +00:00

22 lines
688 B
Haskell

module Control.Concurrent.ExtendedSpec
( spec,
)
where
import Control.Concurrent.Extended qualified as C
import Hasura.Prelude
import Test.Hspec
spec :: Spec
spec = do
describe "forConcurrentlyEIO" $ do
it "chunks correctly" $ do
for_ [1, 2, 3, 4, 5] $ \chunkSize -> do
out <- runExceptT $ C.forConcurrentlyEIO chunkSize [pure 1, pure 2, pure 3, pure 4] id
out `shouldBe` (Right [1, 2, 3, 4] :: Either Int [Int])
it "behaves like ExceptT" $ do
for_ [1, 2, 3, 4, 5] $ \chunkSize -> do
out <- runExceptT $ C.forConcurrentlyEIO chunkSize [pure 1, throwError 2, throwError 3, pure 4] id
out `shouldBe` (Left 2 :: Either Int [Int])