Conversation
Notices
-
See, this is why the whole "load a new page to get every single notice because that's how realtime works" thing won't cut it on RDN. The server would fall over and die in minutes.
Sunday, 16-Sep-12 22:42:30 UTC from web-
@redenchilada Actually, it's less load than the refreshers. :/
Sunday, 16-Sep-12 22:42:59 UTC from web -
@redenchilada Also RDN Refresh does *exactly that*
Sunday, 16-Sep-12 22:43:12 UTC from web-
@minti I thought RDN Refresh loaded the timeline once and got all the notices from there. It usually loads a few notices at a time, so it's not like it's as big of a load as "every time a notice is posted, let everyone else know so they can all request the page for a single notice" and I dunno. It just seems like it'd make more sense to do as much of that processing in the initial push as possible, and handle the rest client-side.
Sunday, 16-Sep-12 22:47:04 UTC from web-
@redenchilada It's still the same thing, cause rather than fetching data for 1 notice every refresh fetches 10.
Sunday, 16-Sep-12 22:48:28 UTC from web-
@minti Thus, realtime is ten times the load on the server? Probably not that bad, but still worse than if you could avoid having to send another request for every notice.
Sunday, 16-Sep-12 22:49:43 UTC from web-
@redenchilada No, RDFRefresh is actually about 10x the load on the server. Plus, Realtime fetches when ever there is a new notice, not every x seconds.
Sunday, 16-Sep-12 22:51:20 UTC from web-
@minti RDFREFRESH
Sunday, 16-Sep-12 22:52:02 UTC from web-
Sunday, 16-Sep-12 22:53:15 UTC from web
-
-
@minti It just seems unnecessary to push something to the user, have them relay a request back based on that, and then send it back to them. I dunno. Maybe I'm just being silly, too.
Sunday, 16-Sep-12 22:53:53 UTC from web-
@redenchilada Yeah, it is stupid. I agree, but we tried to fix that and have it render the notice and send it with the push and yeah it broke and exploded cause wtf statusnet.
Sunday, 16-Sep-12 22:54:35 UTC from web-
@minti I'm still not seeing the big issue with sending a JSON object with all the info needed to let the client reconstruct the notice.
Sunday, 16-Sep-12 22:56:18 UTC from web-
@redenchilada Mainly collecting that information. Like I said, there's quite a bit missing from the API itself. :/
Sunday, 16-Sep-12 22:58:27 UTC from web-
@minti So is it not possible to just make some new database calls to collect that missing information? :s
Sunday, 16-Sep-12 22:59:32 UTC from web-
@redenchilada Yeah, probbaly. But knowing SN it'll probably take like 7 queries just to get the in-context link. 7 queries using SN's database API and Memcache objects and oh god
Sunday, 16-Sep-12 23:01:53 UTC from web-
@minti Well, as long as the server doesn't start exploding suddenly once it happens.
Sunday, 16-Sep-12 23:06:52 UTC from web
-
-
-
-
-
-
-
-
-
-
-
-
@redenchilada @minti When I enabled the early build of RDN plus, it increased load by about 40% over normal.
Sunday, 16-Sep-12 22:43:55 UTC from web-
@ceruleanspark I still have no clue why it did that. RDN Plus doesn't even HANDLE refreshing.
Sunday, 16-Sep-12 22:44:34 UTC from web-
@minti I think it was probably actually meteor flipping out.
Sunday, 16-Sep-12 22:45:08 UTC from web-
@ceruleanspark Well it seemed to be just RDNPlus causing a memory leak or something. So I have no clue. @_@ Widget never actually restored the server-sided settings version of it..
Sunday, 16-Sep-12 22:46:13 UTC from web-
@minti Probably some conflict arising from Mysql being slow and meteor being fast. With a queue daemon it'd probably work OK.
Sunday, 16-Sep-12 22:50:08 UTC from web
-
-
-
-
-
Sunday, 16-Sep-12 23:01:37 UTC from web
-
@widget Oh true, forgot that it's not unique on a per user basis.
Sunday, 16-Sep-12 23:03:34 UTC from web -
@widget WEBSOCKETS, MAN.
Sunday, 16-Sep-12 23:04:01 UTC from web
-
