Speed up response times

[benmelz]

Every now and then the schedule file will take a little bit to send.

Observations:

• We're using file based caching in production right now, which could be an IO bottleneck
• We only have one puma worker, which also could be a bottleneck
• Sometimes the client seems to request the schedule file multiple times, which is odd (especially on chrome)

[benmelz]

Sometimes the client seems to request the schedule file multiple times, which is odd (especially on chrome)

I think I figured this out. When the server doesn't immediately respond, the gtfs react hooks will go into a sort of "retry mode" (since the normal timers can be as long as 1 day). That timer is currently set to 1 second and doesn't wait for an explicit 500 or anything:

https://github.com/umts/gtfs-react-hooks/blob/93e9b93f4a8f4392c3a6d26b5752bbaa87061721/lib/useGtfsSchedule.js#L7

https://github.com/umts/gtfs-react-hooks/blob/93e9b93f4a8f4392c3a6d26b5752bbaa87061721/lib/useRefresh.js#L13-L18

I don't think that would be relevant to the performance issues though.

[werebus]

I don't think that would be relevant to the performance issues though.

Yeah, I think the big issue here is actually #99, but of course making more requests makes it worse. My React knowledge is super lacking, but does the "retry" cancel the previous request?

[benmelz]

My React knowledge is super lacking, but does the "retry" cancel the previous request?

They aren't cancelled but they do fully leverage async-ness. That is, even if we trigger multiple requests, the first one that terminates will trigger a state update/render in react. I believe any performance hits would only be the result of having multiple requests going at the same time on the system network stack which shouldn't be horrible?

[benmelz]

After #98 I'm observing response times in the 200-600ms range. In about a minute of spam refreshing I got exactly one response time that was >1s (1.2, specifically).

I'm inclined to say it didn't have a huge impact... although I also had trouble getting a >2s request like @sherson yesterday as well. Might be good for him to do some smoke testing?

[sherson]

It's zippy for me today

[sherson]

Did a little more testing:

Location	Connection	Common	Occasional	Rare
UMass	EDUROAM	< 100 ms	1-2 s
UMass	T-Mobile 5G	1-2 s	3-5 s
Belchertown	T-Mobile Home Internet (5G - wifi)	2-3 s	3-5 s	10-30 s
Belchertown	T-Mobile 5G	2-3 s	3-5 s	5-10 s

Notes:

• Above times are how long the PVTA messages page is blank.
• Have not noticed patterns by time of day.
• Extreme load times seem rare... may take 10+ seconds once or twice, then 1-2 sec repeatedly.
• Other UMass sites/pages (Spire, umasstransit, etc) load reasonably quickly for me from on or off campus (even if loading after clearing the cache or for the first time).
• When loading (in newly installed browser or after clearing cache) https://www.umass.edu/transportation/ or https://www.umass.edu/transportation/transit or https://www.umass.edu/transportation/transit/pvta-routes-and-schedules, other content on those pages typically takes 1 to 2 seconds to load from off campus while the embedded pvta messages take an additional 1 to 3 seconds (so the PVTA UMass Bus Alerts section is blank while everything else has loaded).

My T-Mobile connections being somewhat slow seems to be a contributing factor, however, the last two bullets make me wonder if something else going on (and the screenshots below for the 18 second and 28 second load times have a lot of gtfs fetches).

blank for 28 seconds this morning 5:52 am:

blank for 4 seconds this morning 5:54 am:

blank for 2 seconds this morning 5:55 am:

blank for 18 seconds this morning 5:57 am:

(did another couple dozen page loads from home this morning that were all in the 1-5 second range)

[benmelz]

@sherson Pushed one more possible optimization this morning. I'm not too optimistic though - your results do kind of point the finger at your network connection.

[sherson]

@benmelz yeah, I suspect the extreme/rare load times are primarily due to connectivity issues.

However, since multiple users have reported sluggishness, and it can be laggy even discounting those rare load times, I wonder if it's worth breaking out routes.txt and changing things such that public-message-board downloads only it.

(while it doesn't matter if departure-board takes extra time to load the entire gtfs file)