DonationCoder.com Software > N.A.N.Y. 2011
NANY 2011 Release: JottiQ
mouser:
Well im not sure i buy the logic.
You are right that 500 people using JottiQ can result in 500 uploads to the service at a time, which if Jotti is not prepared for, could result in a heavy load on the server.
Now a pre-check for server status and a delay of N seconds before uploading when server is busy will definitely help.
BUT, even without checking the server status, the point is that it will make a HUGE additional difference in load if you delay between multiple file uploads, since most people using JottiQ will be queuing more than one file.
So it's all fine and well to say that adding a delay won't 100% solve every problem -- it is the case that delays will have a HUGE effect on lowering the load on the server.
I suggest a delay of something like max(uploads/2,10)*(0.5+serverload) (where serverload is from 0 to 1 based on server's reported serverload)
Adding the delay is something you have control over and could add really easily, and it would eliminate most of the problem and abuse.
worstje:
Anything the delay can do is something Jotti can already do, and probably already does. JottiQ needs to get a token from the server in order to do anything for a particular 'file'. Said throttling is the delay you are aiming at that Jotti has FULL control over. If JottiQ doesn't get that token, it can do nothing.
I intend to add stuff to somehow involve the general server load, but again the ideal way is for the throttling to come from Jotti's side where possible. He has most control and insight into those things. His service can be at 100% load and not need to deny anyone. It is his internal queue of files people have uploaded that need scanning that is growing waay out of its intended capacity to the point where even the relatively quiet moments aren't providing enough space for him to minimize said internal queue to managable levels.
mouser:
fair enough, jotti COULD ask your program to delay if he writes that code -- but if he can't get himself to write that in time, it still might be something you could do now to solve the problem.
worstje:
JottiQ v1.0.2 is finally out. It is not the sort of release I would have preferred to make, but it is a necessity. :)
* JottiQ v1.0.2 Installer
* JottiQ v1.0.2 .7z archive
Changes in this version:
v1.0.2 (2011-01-06)
JottiQ-got-too-popular-for-its-own-good release. At the highest point
before Jotti's malware scan was forced to cease servicing JottiQ, the old
all-time record for its scanning load had been beaten by over 500%.
Added: Update check. It should have been implemented pre v1.0.0, but a
lot of issues came up and it simply didn't happen. Have a look inside
the 'About JottiQ' dialog. Future versions might add automation for
this sort of checking. This supports the DCUpdater application.
Added: A very heavy-handed approach to try and lighten the load on the
servers. If the server passes a certain point, all non-cached files
will not be uploaded and throw up an error. This way Jotti will
hopefully no longer be forced to cease servicing JottiQ. In future
versions, once JottiQ loses its spotlight, I will look into merely
saving the actual file uploads for last in the case Jotti's malware
scan is overloaded so one will not have to reset items to get stuff
to scan once it quiets down a bit.
Added: An actual link to the website and the discussion thread on
DonationCoder. Forgetting to link to your own site is a bit of a
stupid mistake to make.
Added: Internet shortcuts. (Rather too many links than too little!)
Added: Detection for withdrawn service from Jotti, and possible actions
the user can take to alleviate the issue.
Changed: Upgrading versions will require the 'Privacy Agreement' to be
accepted once more.
Changed: Users that put an unreasonably high load on Jotti's servers will
from now on be reminded they are quite the inconsiderate users.
I would rather not start truly limiting users as it will hurt the
intended use-cases of the application as well, but if in the versions
and months to come such soft reminders prove to not be enough, I will
have to resort to limiting functionality in all sorts of ways.
Changed: The older changelog (version history) entries have been split
off into their own Changelog.txt file. This way the Readme will be a
bit more accessible to users again.
mouser:
it might be nice to show in the status or result window when a file cache was used instead of having to upload the whole file.
could be interesting to user and also useful in explaining why a file was so fast to be scanned.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version