web response is slow, is the network is too slow?
suzheng
PROOP

9 months ago

Our web app is a FastAPI + React Next.js web app, we deployed it into Railway (https://railway.com/project/aa35baa2-15a4-4062-9b82-2ddd969cc922), but the page response is very slow. We are trying to find out why it is slow.

So we created a mock delay api, it did nothing, only sleep for one second.

Below is the code:

@router.get("/mock-delay", operation_id="mock_delay")

@time_function

async def mock_delay():

"""

Mock API endpoint that simply waits for 1 second and returns.

This endpoint is used to test network latency without any database or processing overhead.

"""

# Sleep for 1 second

await asyncio.sleep(1)

# Return a simple response

return {

"message": "This response was delayed by 1 second",

"status": "success"

}

We also have a decorate in the fastAPI backend to record the time running the api, and it show:

"Function mock_delay completed in decorator 1.000s"

And then we created a very simple page in the React frontend, basically, the page just do

const startTime = performance.now();

await usersApi.mockDelay();

const endTime = performance.now();

then get the Total time: ${(endTime - startTime).toFixed(2)}ms

and the page show:

"Total time: 1894.60ms"

And in your HTTP Logs:

We got:

requestId:

"sM6wgPp6SDCJdvawKxCz9w_3176973899"

timestamp:

"2025-03-06T09:45:27.936970860Z"

method:

"OPTIONS"

path:

"/api/v1/users/mock-delay"

host:

"backend-fastapi-web-production.up.railway.app"

httpStatus:

200

upstreamProto:

"HTTP/1.1"

downstreamProto:

"HTTP/2.0"

responseDetails:

""

totalDuration:

181

upstreamAddress:

"http://[fd12:f94d:27c0:0:2000:40:ba2a:9538]:8000"

clientUa:

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36"

upstreamRqDuration:

180

txBytes:

2

rxBytes:

694

srcIp:

"49.180.45.204"

edgeRegion:

"asia-southeast1"

and

requestId:

"Oi5E96MdQcGn3NNYHQXw5g_3176973899"

timestamp:

"2025-03-06T09:45:29.358347741Z"

method:

"GET"

path:

"/api/v1/users/mock-delay"

host:

"backend-fastapi-web-production.up.railway.app"

httpStatus:

200

upstreamProto:

"HTTP/1.1"

downstreamProto:

"HTTP/2.0"

responseDetails:

""

totalDuration:

1182

upstreamAddress:

"http://[fd12:f94d:27c0:0:2000:40:ba2a:9538]:8000"

clientUa:

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36"

upstreamRqDuration:

1182

txBytes:

70

rxBytes:

971

srcIp:

"49.180.45.204"

edgeRegion:

"asia-southeast1"

Our frontend and backend is in the same project (https://railway.com/project/aa35baa2-15a4-4062-9b82-2ddd969cc922). We are using Public Networking for backend and frontend communication.

As the Private Networking never worked for us. Will need your help with this, but we will create another ticket for the private network setting issue.

In this ticket, I was wondering, why our React need 1894ms to finish a 1000ms api call, and why your HTTP logs show 1182ms for GET, and 181ms for OPTIONS.

How much time is spent on the transfer over network. is it normal, how should we optimize and make it faster.

5 Replies

Hello,

We feel that the issue is likely to do with the fact that you are using our Asia proxies which have a known issue where we would route the network hop to US-East. Can you run a traceroute to 66.33.22.11 to confirm.

The other half here is that you aren’t packaging your FastAPI service for production but I know once we solve the network issues, we can tackle the latter half of your issue.

-Angelo


Status changed to Awaiting User Response Railway 9 months ago


suzheng
PROOP

9 months ago

sure, thanks.

$ traceroute 66.33.22.11

traceroute to 66.33.22.11 (66.33.22.11), 64 hops max, 40 byte packets

1 172.20.10.1 (172.20.10.1) 7.391 ms 3.196 ms 2.583 ms

2 10.111.13.188 (10.111.13.188) 13.209 ms

10.111.13.189 (10.111.13.189) 13.876 ms

10.111.13.188 (10.111.13.188) 15.265 ms

3 172.24.126.3 (172.24.126.3) 150.580 ms

172.24.126.1 (172.24.126.1) 180.158 ms 13.816 ms

4 10.194.122.213 (10.194.122.213) 21.972 ms 16.186 ms 15.670 ms

5 * * *

6 mas2-hu0-4-0.ig.optusnet.com.au (198.142.249.250) 34.433 ms 14.628 ms

mas2-hu0-5-0.ig.optusnet.com.au (198.142.249.254) 14.921 ms

regarding "packaging FastAPI service for production", should I do it from our end, or you will do it from your end?


Status changed to Awaiting Railway Response Railway 9 months ago


suzheng
PROOP

9 months ago

regarding this "issue is likely to do with the fact that you are using our Asia proxies which have a known issue where we would route the network hop to US-East", will it be solved if I can use private network instead of public network for the communcation between my FastAPI and React?


jake
EMPLOYEE

9 months ago

Unfortunately we don't have the cycles to be able to diagnose performance issues with users applications


Status changed to Awaiting User Response Railway 9 months ago


suzheng
PROOP

9 months ago

regarding "packaging FastAPI service for production", should I do it from our end, or you will do it from your end?
regarding this "issue is likely to do with the fact that you are using our Asia proxies which have a known issue where we would route the network hop to US-East", will it be solved if I can use private network instead of public network for the communcation between my FastAPI and React?


Loading...