# 'Standard' vapor website drops 1.5% of requests, even at concurrency of 100! **URL:** \ **Category:** Server\ **Tags:** benchmarks\ **Created:** [May 2, 2024, 3:25pm UTC](https://forums.swift.org/t/standard-vapor-website-drops-1-5-of-requests-even-at-concurrency-of-100/71583 "2024-05-02T15:25:36Z")\ **Posts on this page:** 1\ **Showing post:** 42
**Author:** ![lorentey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lorentey/32/1299_2.png) [@lorentey](https://forums.swift.org/u/lorentey)\ **Post date:** [May 3, 2024, 7:52pm UTC](https://forums.swift.org/t/standard-vapor-website-drops-1-5-of-requests-even-at-concurrency-of-100/71583/42 "2024-05-03T19:52:02Z")
> [@johannesweiss](#): > > CC @lorentey, any suggestions regarding `BigInt` performance? Seems to be using [GitHub - attaswift/BigInt: Arbitrary-precision arithmetic in pure Swift](https://github.com/attaswift/BigInt) `BigInt.+` isn't doing anything particularly expensive. It has cost that's linear in the size of its input, and for values beyond 2^128 it includes an allocation to hold its result. I'd expect it to be generally in the ballpark of other big integer implementations. (It doesn't do anything special, though -- it includes no clever SIMD tricks: it boils down to a boring loop of `addingReportingOverflow`s.) Given that this benchmark is quite deliberately using big integer additions as a way to generate load, I'm not surprised that it would dominate the performance analysis. How confident are we that BigInt.+ is actually meaningfully slower than, say, Java's BigInteger.+? There may be an unexpected stdlib regression lurking there. `swift-numerics` is our official home for numerics solutions outside the stdlib. It has a [feature branch for `BigInt` development](https://github.com/apple/swift-numerics/tree/biginteger/Sources); it has been in the works for over four years now. --- _[View the full topic](https://forums.swift.org/t/standard-vapor-website-drops-1-5-of-requests-even-at-concurrency-of-100/71583)._