tag pages are getting slow

[jywarren]

http://publiclab.org/tag/spectrometer

[btbonval]

I haven't checked this out yet, but gut reaction is to wonder about the
image loading.

If the slowness is database related, we can determine that from rails
console or in the mysql client.

On Thu, Apr 10, 2014 at 9:42 AM, Jeffrey Warren notifications@github.comwrote:

http://publiclab.org/tag/spectrometer

Reply to this email directly or view it on GitHubhttps://github.com//issues/30
.

[jywarren]

or from the production log, which ought to show load time and a breakdown
of db vs. views etc. Yeah.

On Thu, Apr 10, 2014 at 1:32 PM, Bryan Bonvallet
notifications@github.comwrote:

I haven't checked this out yet, but gut reaction is to wonder about the
image loading.

If the slowness is database related, we can determine that from rails
console or in the mysql client.

On Thu, Apr 10, 2014 at 9:42 AM, Jeffrey Warren <notifications@github.com

wrote:

http://publiclab.org/tag/spectrometer

Reply to this email directly or view it on GitHub<
https://github.com/publiclab/plots2/issues/30>
.

Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-40114076
.

[btbonval]

Oh yeah, I keep forgetting you have some way of looking at the log that is
useful. Whenever I crack it open I can never find what I'm looking for. I
should get better at using the rails log file. ;)

On Thu, Apr 10, 2014 at 1:34 PM, Jeffrey Warren notifications@github.comwrote:

or from the production log, which ought to show load time and a breakdown
of db vs. views etc. Yeah.

On Thu, Apr 10, 2014 at 1:32 PM, Bryan Bonvallet
notifications@github.comwrote:

I haven't checked this out yet, but gut reaction is to wonder about the
image loading.

If the slowness is database related, we can determine that from rails
console or in the mysql client.

On Thu, Apr 10, 2014 at 9:42 AM, Jeffrey Warren <
notifications@github.com

wrote:

http://publiclab.org/tag/spectrometer

Reply to this email directly or view it on GitHub<
https://github.com/publiclab/plots2/issues/30>
.

Reply to this email directly or view it on GitHub<
https://github.com/publiclab/plots2/issues/30#issuecomment-40114076>

.

Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-40114271
.

[jywarren]

Example:

Started GET "/profile/gate8llama" for xx.xx.xx.xx Processing by UsersController#profile as HTML Parameters: {"id"=>"gate8llama"} Rendered sidebar/_related.html.erb (235.4ms) Rendered like/_like.html.erb (42.8ms) Rendered sidebar/_related.html.erb (406.6ms) Rendered tag/_tagging.html.erb (4.0ms) Rendered home/_social.html.erb (0.3ms) Rendered wiki/show.html.erb within layouts/application (347.6ms) Rendered notes/_notes.html.erb (1.5ms) Rendered like/_like.html.erb (28.0ms) Read fragment views/tool-place-menu-4657172 (0.3ms) Rendered layouts/_alerts.html.erb (0.2ms) Completed 200 OK in 697ms (Views: 447.7ms | ActiveRecord: 94.2ms)

yeah it's pretty nice!

[btbonval]

697ms is not great, but 447 of that is Views not ActiveRecord. So if I'm
reading it right, the database is fine, the image serve time isn't a factor
in this metric (that'd be static serve), and there are 9-10 snippets being
read which create the delay. Obviously wiki show is taking the cake on this
one.

Wait, why is wiki show loading slow if you're loading a user profile?

That log file snippet is super useful, isn't it?

On Thu, Apr 10, 2014 at 1:42 PM, Jeffrey Warren notifications@github.comwrote:

Example:

Started GET "/profile/gate8llama" for xx.xx.xx.xx
Processing by UsersController#profile as HTML
Parameters: {"id"=>"gate8llama"}
Rendered sidebar/_related.html.erb (235.4ms)
Rendered like/_like.html.erb (42.8ms)
Rendered sidebar/_related.html.erb (406.6ms)
Rendered tag/_tagging.html.erb (4.0ms)
Rendered home/_social.html.erb (0.3ms)
Rendered wiki/show.html.erb within layouts/application (347.6ms)
Rendered notes/_notes.html.erb (1.5ms)
Rendered like/_like.html.erb (28.0ms)
Read fragment views/tool-place-menu-4657172 (0.3ms)
Rendered layouts/_alerts.html.erb (0.2ms)
Completed 200 OK in 697ms (Views: 447.7ms | ActiveRecord: 94.2ms)

yeah it's pretty nice!

Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-40115002
.

[jywarren]

oh sorry i was rushing, that's not actually for a tag page

On Thu, Apr 10, 2014 at 1:54 PM, Bryan Bonvallet
notifications@github.comwrote:

697ms is not great, but 447 of that is Views not ActiveRecord. So if I'm
reading it right, the database is fine, the image serve time isn't a factor
in this metric (that'd be static serve), and there are 9-10 snippets being
read which create the delay. Obviously wiki show is taking the cake on this
one.

Wait, why is wiki show loading slow if you're loading a user profile?

That log file snippet is super useful, isn't it?

On Thu, Apr 10, 2014 at 1:42 PM, Jeffrey Warren <notifications@github.com

wrote:

Example:

Started GET "/profile/gate8llama" for xx.xx.xx.xx
Processing by UsersController#profile as HTML
Parameters: {"id"=>"gate8llama"}
Rendered sidebar/_related.html.erb (235.4ms)
Rendered like/_like.html.erb (42.8ms)
Rendered sidebar/_related.html.erb (406.6ms)
Rendered tag/_tagging.html.erb (4.0ms)
Rendered home/_social.html.erb (0.3ms)
Rendered wiki/show.html.erb within layouts/application (347.6ms)
Rendered notes/_notes.html.erb (1.5ms)
Rendered like/_like.html.erb (28.0ms)
Read fragment views/tool-place-menu-4657172 (0.3ms)
Rendered layouts/_alerts.html.erb (0.2ms)
Completed 200 OK in 697ms (Views: 447.7ms | ActiveRecord: 94.2ms)

yeah it's pretty nice!

Reply to this email directly or view it on GitHub<
https://github.com/publiclab/plots2/issues/30#issuecomment-40115002>

.

Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-40116820
.

[btbonval]

Well we might want a new ticket because that page has a crazy long load
time.

Btw I banned the user in the pasted log. username was of the form
[noun][number][noun], classic spam user. Checking the profile, I saw link
poisoning.

On Thu, Apr 10, 2014 at 1:57 PM, Jeffrey Warren notifications@github.comwrote:

oh sorry i was rushing, that's not actually for a tag page

On Thu, Apr 10, 2014 at 1:54 PM, Bryan Bonvallet
notifications@github.comwrote:

697ms is not great, but 447 of that is Views not ActiveRecord. So if I'm
reading it right, the database is fine, the image serve time isn't a
factor
in this metric (that'd be static serve), and there are 9-10 snippets
being
read which create the delay. Obviously wiki show is taking the cake on
this
one.

Wait, why is wiki show loading slow if you're loading a user profile?

That log file snippet is super useful, isn't it?

On Thu, Apr 10, 2014 at 1:42 PM, Jeffrey Warren <
notifications@github.com

wrote:

Example:

Started GET "/profile/gate8llama" for xx.xx.xx.xx
Processing by UsersController#profile as HTML
Parameters: {"id"=>"gate8llama"}
Rendered sidebar/_related.html.erb (235.4ms)
Rendered like/_like.html.erb (42.8ms)
Rendered sidebar/_related.html.erb (406.6ms)
Rendered tag/_tagging.html.erb (4.0ms)
Rendered home/_social.html.erb (0.3ms)
Rendered wiki/show.html.erb within layouts/application (347.6ms)
Rendered notes/_notes.html.erb (1.5ms)
Rendered like/_like.html.erb (28.0ms)
Read fragment views/tool-place-menu-4657172 (0.3ms)
Rendered layouts/_alerts.html.erb (0.2ms)
Completed 200 OK in 697ms (Views: 447.7ms | ActiveRecord: 94.2ms)

yeah it's pretty nice!

Reply to this email directly or view it on GitHub<
https://github.com/publiclab/plots2/issues/30#issuecomment-40115002>

.

Reply to this email directly or view it on GitHub<
https://github.com/publiclab/plots2/issues/30#issuecomment-40116820>

.

Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-40117289
.

[jywarren]

Well, 0.4 seconds is a lot better than the 24 seconds the /maps page is taking, thanks to using powertags for location storage. boo. see #33

[btbonval]

Yeah I was just seeing log results for my work rails project which were in
the same range (~400ms) for views, although this was on my tiny
underpowered netbook.

Is there a debug mode that we can turn on and off? Turning it off might
speed up performance but make it harder to see what's going on when there
are problems. It doesn't seem completely necessary at the moment, I'm
mostly curious.

On Fri, Apr 11, 2014 at 8:53 AM, Jeffrey Warren notifications@github.comwrote:

Well, 0.4 seconds is a lot better than the 24 seconds the /maps page is
taking, thanks to using powertags for location storage. boo. see #33#33

Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-40219240
.

[jywarren]

you can run it in production or development mode; locally, the default is
development, which is much less optimized, on the server, it's production,
and the logs are less verbose and there's more caching.

On Fri, Apr 11, 2014 at 1:13 PM, Bryan Bonvallet
notifications@github.comwrote:

Yeah I was just seeing log results for my work rails project which were in
the same range (~400ms) for views, although this was on my tiny
underpowered netbook.

Is there a debug mode that we can turn on and off? Turning it off might
speed up performance but make it harder to see what's going on when there
are problems. It doesn't seem completely necessary at the moment, I'm
mostly curious.

On Fri, Apr 11, 2014 at 8:53 AM, Jeffrey Warren <notifications@github.com

wrote:

Well, 0.4 seconds is a lot better than the 24 seconds the /maps page is
taking, thanks to using powertags for location storage. boo. see #33<
https://github.com/publiclab/plots2/issues/33>

Reply to this email directly or view it on GitHub<
https://github.com/publiclab/plots2/issues/30#issuecomment-40219240>

.

Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-40227059
.

[jywarren]

these are now optimized using a nice join. whew!

[btbonval]

wooooooo

On Fri, May 2, 2014 at 12:35 PM, Jeffrey Warren notifications@github.comwrote:

these are now optimized using a nice join. whew!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-42051253
.