Maybe just show stations from the last 24 hours and have links to other timeframes. This may speed up the page load. I don't remember if the count statistic is being calculated on the fly or not; if it is, don't do that.
Maybe just show stations from the last 24 hours and have links to other timeframes. This may speed up the page load. I don't remember if the count statistic is being calculated on the fly or not; if it is, don't do that.
W1CDN
added the bug label 2024-09-12 11:47:58 -05:00
Still taking like 7 seconds to load the page though. I wonder if a cache table could be made (looks like I mentioned this earlier).
Limited to 10 by default now: c8f8f28a4ac86dde5bd9d6c25dbc4760b17f6b08
Still taking like 7 seconds to load the page though. I wonder if a cache table could be made (looks like I mentioned this earlier).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Maybe just show stations from the last 24 hours and have links to other timeframes. This may speed up the page load. I don't remember if the count statistic is being calculated on the fly or not; if it is, don't do that.
Well, it's not doing it with
?n=20, so need to check on what query parameters I built in.Limited to 10 by default now:
c8f8f28a4aStill taking like 7 seconds to load the page though. I wonder if a cache table could be made (looks like I mentioned this earlier).
Individually, /stations is much faster than /packets, even limited to default 10. Is that because the table is much larger or the query more complex?
select_frames()now orders byid(index) rather thancreatedand it is much faster now.a5978c2289