3 ms·

I see that you have 4220 members that are subscription holders. I'm supposing that you have more that are active users but not Member/Patron status. What's aver

I see that you have 4220 members that are subscription holders. I'm supposing that you have more that are active users but not Member/Patron status. What's average sessions? Is there anything you can do with the AWS allocation (ie. AWS configurations or infra swapping)? From my vantage point of what I perceives as your Service model, I'm not readily seeing any component of it that would be CPU intensive, but I'm just another guy on the Internet. I'm happy to continue my prodding in an another channel. And yes, PayPal fees are taking money from your children.

busterbenson 7y ago
I get about 30-40K unique sessions per month, so a little over 10% are paying users. We gave all accounts that signed up prior to going paid free lifetime accounts, and many of them still use the site... so it's a weird mix. There's definitely stuff I can do to make AWS cheaper. Starting with just remembering to pre-pay for my instances ahead of time. One of my least favorite things to do is to log into the AWS console, so I try to do it as little as possible. The CPU intensive part is due to autosave. When a lot of people are writing concurrently (even on the order of hundreds), that was usually what would take down the site in the old days. The site is weird in the sense that there are 10x more writes than reads, and then doing all of the linguistic analysis, badge granting, stats generating cause spikes when they happen as well. I'm @buster on Twitter if you want to continue the discussion there.
- weaksauce 7y ago
  obviously i have no idea what your backend looks like but have you explored if you could get away with sending those writes to a job queue and batch the inserts for more performance? or even something like a plaintext file that gets created and put into a folder that gets read from by a background worker and then written to the db.

busterbenson 7y ago

I get about 30-40K unique sessions per month, so a little over 10% are paying users. We gave all accounts that signed up prior to going paid free lifetime accounts, and many of them still use the site... so it's a weird mix. There's definitely stuff I can do to make AWS cheaper. Starting with just remembering to pre-pay for my instances ahead of time. One of my least favorite things to do is to log into the AWS console, so I try to do it as little as possible. The CPU intensive part is due to autosave. When a lot of people are writing concurrently (even on the order of hundreds), that was usually what would take down the site in the old days. The site is weird in the sense that there are 10x more writes than reads, and then doing all of the linguistic analysis, badge granting, stats generating cause spikes when they happen as well. I'm @buster on Twitter if you want to continue the discussion there.

weaksauce 7y ago
obviously i have no idea what your backend looks like but have you explored if you could get away with sending those writes to a job queue and batch the inserts for more performance? or even something like a plaintext file that gets created and put into a folder that gets read from by a background worker and then written to the db.