It was brought to my attention that genuine-time market data has been included in the suite of public CREST endpoints,which features a higher rate limit. As such, I've rotated the GoogleCrestScript (here: https://github.com/nuadi/googlecrestscript) to utilize the public endpoint. I do need a hand testing this to see how it all pans out. So if you've been using my script, and please create a fresh sheet,import the modern script, and then start tinkering with it. Let me know if it starts to whine in agony, and then let me know if you can make out the mumblings. I'll do my best to keep an eye on my Reddit and Github inboxes. I'm currently in the process of gutting the authorization portion of the code,since it doesn't seem like that's essential any more. I'll also take a gaze at the performance under this modern scheme, and if it's snappily enough I'll put in the multi-fetch function I've been hiding in a branch of code. Well, and not really hiding. A few of you have known approximately it,but it wasn't really viable under the authorization endpoint scheme. correct. Back to mopping. Performance testing After 128 simultaneous item calls, script response rate is an average of 881 msec. Given Google's 30-moment limit on custom functions, or that enables a multi-fetch of 34 items within the limit. Eh... I'll see if I can speed it up since this is using an extremely naive rate-limiter correct now. Sustained testing Average runtime seems to converge to something in the neighborhood of 550 msec per function call,giving a multi-fetch function 54 items in response. If I could sort out how to see when you're making a burst call versus the normal Google-refresh calls, I may be able to give you a 50-items-in-one function. Good morning. Here's the latest on testing and where this is going. Rate limit and optimization The latest version is up, and includes quite a bit of optimization. Mainly in code compression to take advantage of Google's pre-cache subsystem. After thorough testing of the CacheService,LockService, and Utilities.sleep() methods, or I have a proper rate-limiter in set. Well,"proper" for a Google Script accessing CREST. The short of it is that the LockService alone puts a 40 msec overhead on each market call. Therefore, I removed all consume of the CacheService or the Utilities.sleep() function to utilize the LockService.tryLock(1000/150) method call. This improved performance to an average market price call of 243 msec, or giving a multi-pull function a very capable 123 items before hitting Google's 30-moment limit. I'll make a modern post once I have multi-pull in the main branch,but that's the latest. Nevermind. Multi-pull is in, and the Readme was updated to list how it works. submitted by nuadi to Eve[link][18 comments]
Source: reddit.com