Log in

No account? Create an account
Does anyone know why the checkfriends interval being sent back is… - LiveJournal Client Discussions — LiveJournal [entries|archive|friends|userinfo]
LiveJournal Client Discussions

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Mar. 4th, 2005|04:45 pm]
LiveJournal Client Discussions


[mood |confusedconfused]
[music |Sukilove (You Kill Me): Girl On The Moon]

Does anyone know why the checkfriends interval being sent back is 36,000 seconds (aka 10 hours)?

Is it possible they switched to microseconds and didn't tell anyone, or do they not want clients using the checkfriends protocol anymore?

[User Picture]From: marksmith
2005-03-07 06:53 pm (UTC)
Nah. Bandwidth isn't really the issue. Database load is, and checkfriends is about the heaviest part of the whole process. With millions of free users, it was bogging down the system quite a bit, so now it's a paid user feature.

It wouldn't have been a problem if clients were implemented properly, but most clients just check as fast as the server allows -- even if the user hasn't acknowledged the last notice. So, overnight, the client is checking every 2 or 3 minutes, every hour, even though the user isn't at their computer. Quite inefficient.

So the decision was made to limit it to paid accounts. We can't change the clients, but we can change the server to make things work out anyway. :)
(Reply) (Parent) (Thread)
From: piman
2005-03-07 08:54 pm (UTC)
Until paid users use broken clients.

Block the clients that cause problems, not the users trying to solve them.
(Reply) (Parent) (Thread)
[User Picture]From: theorb
2005-03-07 09:06 pm (UTC)
Better, track the average interval between checkfriends requests for a given user, and do not let it become less then some minimum.
(Reply) (Parent) (Thread)
[User Picture]From: marksmith
2005-03-07 09:23 pm (UTC)
Nah, paid users use broken clients all the time. But they're paying, so we're not going to disable access unless there's a dire problem.

Same logic for putting free users read-only at times on Filet Mignon, yet the paid users never get put read-only. If you reduce the load on 95% of the userbase, then the 5%, even if they're doing something broken, aren't going to really affect things.
(Reply) (Parent) (Thread)
[User Picture]From: mcfnord
2005-03-08 04:31 am (UTC)
You could take a pro-active approach to the quality of client data practices by publishing client load stats and then encouraging people to keep their app resource usage down. This lets you communicate your values, influence client development efforts, and ultimately provide additional room for new tools within the resource pool.
(Reply) (Parent) (Thread)