2

I'm using charlotte-ruby/impressionist to track impressions within my rails app.

I have a very simple implementation, similar to what's shown in the quick start guide. Effectively: - Controller: impressionist actions: [:show, :index] - View: @post.impressionist_count - Model: is_impressionable

I ran into some DB queuing issues today, and found the following when checking out my expensive queries within Heroku Postgres: enter image description here

I immediately removed impressionist from my controllers/views (at 14:30), and you can see how it impacted performance: enter image description here

Has anyone run into a similar issue with the impressionist gem? Any ideas of why it's so expensive from a DB perspective?

EDIT:

Here are the indexes that were added:

  add_index "impressions", ["controller_name", "action_name", "ip_address"], name: "controlleraction_ip_index", using: :btree
  add_index "impressions", ["controller_name", "action_name", "request_hash"], name: "controlleraction_request_index", using: :btree
  add_index "impressions", ["controller_name", "action_name", "session_hash"], name: "controlleraction_session_index", using: :btree
  add_index "impressions", ["impressionable_type", "impressionable_id", "ip_address"], name: "poly_ip_index", using: :btree
  add_index "impressions", ["impressionable_type", "impressionable_id", "request_hash"], name: "poly_request_index", using: :btree
  add_index "impressions", ["impressionable_type", "impressionable_id", "session_hash"], name: "poly_session_index", using: :btree
  add_index "impressions", ["impressionable_type", "message", "impressionable_id"], name: "impressionable_type_message_index", using: :btree
  add_index "impressions", ["user_id"], name: "index_impressions_on_user_id", using: :btree
dmt2989
  • 1,610
  • 3
  • 17
  • 30
  • 1
    The thing I noticed when I installed the `impressionist` gem is the immense amount of indexes it creates in the DB. I got rid of them all since I don't see the need for indexes in tables you very rarely use. Maybe that is what causing this for you. – Eyeslandic Sep 02 '14 at 22:14
  • Hard to draw firm conclusions from the data posted (other than the high level one you came to that the *impressionist* gem was a likely cause)... Were there any indexes in the db for the `impressions` table that would've fit those `where` clause conditions? Were there a bunch of those `select`s bunched up for a given page load? – khampson Sep 03 '14 at 02:12
  • Added the indexes to the question. Not too familiar with this. Anything look out of order? – dmt2989 Sep 03 '14 at 02:35
  • 1
    From the indexes abstracted out into a Ruby DSL, it's hard to tell one way or the other... did the indexes help performance at all? The most telling thing would be to get the query plans for the long-running `SELECT` queries and see if there are missing indexes. – khampson Sep 03 '14 at 23:02
  • @Iceman See http://stackoverflow.com/questions/27862701/how-do-i-determine-if-i-can-delete-some-indexes-from-the-impressions-table. Did you have any advice? – gitb Jan 09 '15 at 14:31

2 Answers2

1

@Ken Hampson - thanks for the recommendation. Looking for the long running SELECT queries identified yet another index that was needed. Once added, POOF, all was better. Very odd that this issue just showed up after having the site live for a few months. Impressions must have hit a size that broke the camel's back. Appreciate the help!

For anyone that runs into similar issues with degrading performance due to DB queries (on Heroku), going to https://postgres.heroku.com/databases/your-database-name and looking at the "Expensive Queries" table is a great way to figure out where you may have missed an index.

dmt2989
  • 1,610
  • 3
  • 17
  • 30
  • Awesome to find this. Had a very similar experience yesterday.... steady response times for months and BOOM, 20000 ms + – Kathan Mar 27 '16 at 06:17
0

The best solution for a large project (thousands/millions of users) is punching bag gem , go through the doc for integration : punching_bag

The major problem arises when with each request a new record is created which puts huge load on database. Gem Impressionist fails here. Punching bag too creates records but it has a rake task which comes to rescue :

Schedule a cron job to this rake task once a month/week to decrease (groups the records) the number of records without affecting the count of page views which can be found by simply - @post.hits . Here is the rake task : rake punching_bag:combine[by_hour_after,by_day_after,by_month_after,by_year_after]

Gunjan
  • 21
  • 3