Forums | Users |
Search | Signup | Login

Acceptable Server Load

Subscribe to Acceptable Server Load 7 post(s), 2 voice(s)

 
Avatar samreid 17 post(s)

I’ve started writing an automated task that makes calls on the Unfuddle API as a cron job. Since I want the results of this task to be immediately available to all my coworkers, I’d like the cron job to run once every 30 seconds or so. The main query will be asking a few of the most recent changes, and more calls will be made on the API based on those changes (if any).

Is this an acceptable load on the Unfuddle server?

 
Avatar Joshua Frappier Administrator 241 post(s)

Sam,

Thanks for taking the time to ask this question. It is an important one.

Up until now, our “official” policy regarding polling has been something along the lines of: “Please be nice to our servers…we’re nice to yours.” And for the most part, this policy has been sufficient. There are a few exceptions that we have had to deal with on a one-to-one basis. In general, this policy translates to just using common sense when it comes to banging against the API (or repositories).

To be honest, I would seriously question most business functions that would require a resolution of 30 seconds. I mean, email is essential to so many of us, but do you check your email that often? A 30 second poll would equate to something like 2,880 (times the number of requests per poll) hits per day! I am sure that you can agree that this is certainly less than optimal.

However, this question does bring up an excellent point. With Subversion repositories, we are actually working on a callback feature that will post to a URL of your choosing upon a successful commit. It is possible that we should consider implementing the same kind of callback based on certain account activity. In many cases, this would essentially eliminate the need for polling at all.

If we were to implement this kind of callback, for which events should this callback be triggered? For instance, are the entries that appear in /api/v1/account/activity sufficient for your needs?

Thanks again for your sensitivity to this issue.

 
Avatar samreid 17 post(s)

I think callbacks rather than polling would be an elegant solution to this problem.

In addition to posting to a URL, please consider adding the option of sending an email to a specified email address to make it easier for those of us without servers.

The /api/v1/account/activity style entries would be sufficient for our needs, and I imagine for others solving similar problems.

Please keep me posted on your estimated timeline and API for this new feature.

Thanks for your help,
Sam Reid

 
Avatar samreid 17 post(s)

My team is considering further development of our custom email notifier; before we started work, I wanted to check on the status of callbacks described above. Can you let me know if you have made any decisions/progress toward implementing callbacks?

Thanks,
Sam Reid

 
Avatar Joshua Frappier Administrator 241 post(s)

Sam,

As you know, we have been working on a major rehaul to repositories that we are rolling out later this month. Part of this release is the ability to specify a callback URL to be pinged whenever a commit happens on a repository.

However, while we still intend to provide a more generic callback facility, we have not yet solidified a firm release date for this feature.

Thanks,
Josh

 
Avatar samreid 17 post(s)

I see that Unfuddle has implemented callbacks for SVN commits, can you provide any additional information about the possibility for callbacks for ticket changes as well?

Thanks,
Sam Reid

 
Avatar Joshua Frappier Administrator 241 post(s)

Sam,

That’s correct. Unfuddle now supports the ability to post back to a URL of your choosing to eliminate the need for SVN/Git polling. This was by far the most pertinent use case and we will be watching to see how this new implementation fares as more people begin to use it.

We are still hoping to integrate a similar functionality for other parts of the Unfuddle API, however, we do not yet have a release date for such an update. Our first priority was to deal with repository callbacks.