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
9 months ago
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
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
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?
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
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?