{"action":"created","issue":{"url":"https://api.github.com/repos/jcuga/golongpoll/issues/15","repository_url":"https://api.github.com/repos/jcuga/golongpoll","labels_url":"https://api.github.com/repos/jcuga/golongpoll/issues/15/labels{/name}","comments_url":"https://api.github.com/repos/jcuga/golongpoll/issues/15/comments","events_url":"https://api.github.com/repos/jcuga/golongpoll/issues/15/events","html_url":"https://github.com/jcuga/golongpoll/issues/15","id":321892646,"number":15,"title":"High CPU load?","user":{"login":"andig","id":184815,"avatar_url":"https://avatars1.githubusercontent.com/u/184815?v=4","gravatar_id":"","url":"https://api.github.com/users/andig","html_url":"https://github.com/andig","followers_url":"https://api.github.com/users/andig/followers","following_url":"https://api.github.com/users/andig/following{/other_user}","gists_url":"https://api.github.com/users/andig/gists{/gist_id}","starred_url":"https://api.github.com/users/andig/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/andig/subscriptions","organizations_url":"https://api.github.com/users/andig/orgs","repos_url":"https://api.github.com/users/andig/repos","events_url":"https://api.github.com/users/andig/events{/privacy}","received_events_url":"https://api.github.com/users/andig/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-05-10T11:00:33Z","updated_at":"2018-05-15T23:41:29Z","closed_at":null,"author_association":"NONE","body":"I'm using this library for publishing events of multiple connected meters (constantly being polled at 9600 baud). I've noticed that just publishing those events longpoll manager- even without connected clients- raises CPU load to > 50% on Raspi3:\r\n\r\n    func (f *Firehose) Run() {\r\n        for {\r\n            select {\r\n            case snip := <-f.in:\r\n                f.lpManager.Publish(\"meterupdate\", snip)\r\n            case statupdate := <-f.statstream:\r\n                f.lpManager.Publish(\"statusupdate\", statupdate)\r\n            }\r\n        }\r\n    }\r\n    ...\r\n    go firehose.Run()\r\n\r\nDoes this behaviour make sense to you or should a low CPU load be expected when publishing without clients attached?"},"comment":{"url":"https://api.github.com/repos/jcuga/golongpoll/issues/comments/389348536","html_url":"https://github.com/jcuga/golongpoll/issues/15#issuecomment-389348536","issue_url":"https://api.github.com/repos/jcuga/golongpoll/issues/15","id":389348536,"user":{"login":"jcuga","id":8991827,"avatar_url":"https://avatars1.githubusercontent.com/u/8991827?v=4","gravatar_id":"","url":"https://api.github.com/users/jcuga","html_url":"https://github.com/jcuga","followers_url":"https://api.github.com/users/jcuga/followers","following_url":"https://api.github.com/users/jcuga/following{/other_user}","gists_url":"https://api.github.com/users/jcuga/gists{/gist_id}","starred_url":"https://api.github.com/users/jcuga/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jcuga/subscriptions","organizations_url":"https://api.github.com/users/jcuga/orgs","repos_url":"https://api.github.com/users/jcuga/repos","events_url":"https://api.github.com/users/jcuga/events{/privacy}","received_events_url":"https://api.github.com/users/jcuga/received_events","type":"User","site_admin":false},"created_at":"2018-05-15T23:41:29Z","updated_at":"2018-05-15T23:41:29Z","author_association":"OWNER","body":"The CPU load not going down when there are no clients subscribed is not surprising, as the longpollManager will buffer events for each category when Publish() is called--with the precise behaviour dictated by the configuration.  So the default config has a buffer of 250 events and an event expire of \"forever.\"  So essentially it will always buffer the latest 250 events for each category.  This is done even when no clients are connected.  This buffering is done via a priority queue / tree per category organized by publish time. \r\n\r\nIf clients are not interested in old events, I could add an option where it doesn't start buffering events for a given category unless there has been a client subscribed to the given category within the last N (milli)seconds.  Currently it will always buffer even without an active subscription.  The erring on the side of buffering is mainly motivated by the following scenario:\r\n\r\nA client subscribes (http GET the subscription handler), gets a response back with data.  Client does a GET again to continue getting more events.  But there is a small amount of time between when the first events request was returned and before the client completes the second subscription request that events may have occurred.  So in this case the buffering would catch these events and the client would get them on the second GET.  But if there has never been a client subscribed to a category, or at least not for quite some time, then this buffering is not preventing any gaps in data that the above scenario was concerned about.\r\n\r\nSo my question would be:  do you have periods of time where there are no client subscriptions where an option like this would prevent wasting as much CPU?  Or will you always have clients subscribed?\r\n\r\nEither way, I can look into adding this option and seeing if it helps.  While I'm in there I can see if there are any other inefficiencies that can be improved in the case where clients will be subscribed and we can't take advantage of this new option.  I will likely have time to work on this in 1-2 weeks.\r\n"}}
{"actor":{"display_login":"jcuga"}}