Simply Testable Updates #109: Ignoring resource:// URLs, Performance Changes Underway
October 1, 2014
|This is the online archive for the Simply Testable weekly behind-the-scenes newsletter.
Subscribe to get weekly updates on the latest changes and the newest planned features.
This is the 109th of weekly progress updates on the development of Simply Testable, your professional automated web frontend testing service providing one-click testing for your entire site.
This week I fixed a bug discovered when testing pages containing links to resource:// URLs and started work on further performance improvements.
Ignoring resource:// URLs
I noticed last week that JS static analysis testing was failing for a specific URL.
Upon investigation, I noticed that the page contained a rather odd <script> element:
Notice that the URL starts with 'resource://' and does not contain an address to a resource addressable over the Internet. It was with this URL that our JS static analysis tester was having trouble. It was trying to retrieve the resource at the given URL and was failing.
I've encountered some odd URLs in my time but wasn't familiar with 'resource://' URLs nor could I find any useful information regarding the purpose of such URLs.
I needed to know if such URLs should be ignored or whether the JS static analysis tester needed to do something special with them. I posted a question on StackOverflow and discovered that these special 'resource://' URLs can be safely ignored.
You can now safely test pages that contain <script> elements that use 'resource://' URLs. Yay!
Further performance improvements
Last week's change to a different background task processing system resulted in some performance improvements. I've continued along this line of improvements with changes to how test tasks are farmed out to workers.
Quick recap: our core application is the brains of the operation. It figures out what needs testing when a new test is started and farms out each specific test to our pool of workers. After receiving a task, a worker will carry out the specified test and will report the results back to the core application.
The core application periodically selects the next set of test tasks to be carried out and farms them out to workers. This process works but is not particularly efficient. It worked fine when originally created, continues to work but can be better.
The core application knows nothing of the workload of each worker. Although tasks are selected to be farmed out quite frequently, there will be a period between when a worker reports results and before the worker has new test tasks to work on.
Workers spend a fair amount of time twiddling their thumbs and waiting for something to bring meaning into their lives. Workers can easily spend more time waiting than working. They're workers, not waiters.
This needs to change!
I've been working on changes to bring about improvements in these areas. Each worker will soon be able to ask that the core application gives it more tasks to carry out. This should greatly increase the amount of time each worker is actually carrying out work instead of staring blankly into space.
Hopefully these changes will be in place in time for next week's newsletter.
Podcast ads started airing yesterday (woo!). I'll be keeping a close eye on things when that happens. I'll also be completing the above-mentioned changes to speed things up a bit (hopefully a lot).
As always, if you'd like to see web testing you find boring handled automatically for you, add a suggestion or vote up those that interest you. This really helps.
Feedback, thoughts or ideas: email firstname.lastname@example.org, follow @simplytestable or keep an eye on the Simply Testable blog.