Forum Activity for @brian

Analytics Comparison

Using Jamroom


This is correct - with JR it is who's been active in the last 15 minutes, whereas with GA it is closer to "real time".

FoxyCart / Subscription Welcome Email

Installation and Configuration

Unfortunately the FoxyCart module does not support this at this time - sorry!

Disk space calculation

Jamroom Developers


No plans - there's just no way to even get close to accurate when measuring bandwidth usage at the JR level (PHP). The problem is that when someone clicks to stream an audio file (for example), that file is sent to the web server's buffer in like 2 seconds, so even if the "listener" only streams 20k of the file, all 20mb will be counted as "bandwidth".

Something would have to be created custom at the network level to monitor individual profile bandwidth, and I'm not sure how that would even be done.

Sorry!
updated by @brian: 03/15/17 07:07:22PM

Load balancing multiple servers

Using Jamroom

You're not going to see JR move in the micro services direction - in my opinion microservices just add more overhead, complexity and creates a slower more error prone system (since now your flow overwhelmingly requires network, which is the most prone to problems).

I believe microservices make sense when you have different teams running different parts of infrastructure and you want to "black box" as much stuff as possible, but it makes very little sense for most sites to even move in that direction. I've read a lot on microservices and found this blog post to be one I agree with:

http://basho.com/posts/technical/microservices-please-dont/

The direction we are moving with JRC 2.0 is to make even a large JR cluster easy to admin and run even for a solo site owner. This means less cloud modules and more "it just works". This means running a lot of things as "services" internally, but the site owner just does not need to care. Our goal is that when you feel you need more CPU power you just spin up a new app server, add it to your cluster, and you're done.
updated by @brian: 03/11/17 10:15:18AM

Site Builder Backups

Design and Skin Customization

Not at this time - currently it just backs up your settings every 24 hours.

Load balancing multiple servers

Using Jamroom

Yes - for now.

Note that Jamroom Cloud 2.0 is in active development right now and is getting fairly close to it's first release. We've been doing A LOT of work to make running a JR cloud much, much easier by simplifying many aspects of the system. JRC 2.0 will also run much better when distributed across multiple front ends.

Upgrading from JRC 1 will be pretty straightforward and will mainly involve turning off some of the modules that are no longer used.

More details will be coming in the next few weeks.

Thanks!

Proxima on a different host

Installation and Configuration

To be honest I would not worry about Proxima's load - it is much, much lower than regular Jamroom. The big contributor to JR load is Smarty templates, and since Proxima is all JSON you don't have to worry about it.

However you could install Proxima on a separate server and just have it point to the same DB.

Documenting API

Installation and Configuration

Proxima is built using Jamroom. There's no documentation API at this time.

Sorry!

Database table type

Installation and Configuration

Hi Dave -

Funny that you bring this up - this is something I've been actually working on on and off over the last couple months - basically migrating MyISAM tables to InnoDB. Our goal is to be 100% InnoDB, but it's not as simple as just switching table types, so don't do that.

The reason Jamroom uses MyISAM for some tables, is that for those tables we need to be able to get a very fast TOTAL row count from the table, which is something MyISAM supports by reading directly from the table meta data (since it keeps track of total row counts in it's meta data). This is something that InnoDB does not do (nor is really possible to do so in a table type that supports transactions), so we have to design an alternate "counter" mechanism that keeps track of counts in the table.

So a few things:

1) We're still using MyISAM tables - I'm not sure when that will change so we are 100% InnoDB. For now you need to stay on MyISAM for the tables that are MyISAM. Since I know this is affecting you, I will make this a bit higher priority than it has been (i.e. I've just been doing testing when I am working on something else related to the table). Our goal is to be able to run JR on Galera Cluster or MySQL NDB, which requires all tables to be InnoDB.

2) It's not always true that MyISAM uses more RAM - in fact it can be the opposite, since InnoDB stores a copy of it's Primary Key in all secondary indexes, which means it can use a larger amount of RAM than a similar MyISAM table.

3) While it's true that you can guarantee a snapshot of a InnoDB table, you can actually do the same with MyISAM by locking the table before your dump. However in practice I don't think you'll have any issues by not locking. mysqldump will always give you a "current" snapshot of the table - i.e. you're not going to get any partial entries, however any queries "in flight" may not be dumped if they have not committed. This is a problem in theory - in practice I've never seen an issue with this, and have managed hundreds and hundreds of MySQL servers. I'd recommend having your provider check out Percona's xTraBackup:

https://www.percona.com/software/mysql-database/percona-xtrabackup

It does "hot" dumps of InnoDB tables which nice.

So for now you'll need to stay with MyISAM, so hopefully that does not cause you too much issues. If it does and you need to consider alternate hosting let me know

Hope this helps!

New Module - (Electronic Press Kit) - idea

Suggestions

Like Paul said - we had an EPK module for JR4 that was used very, very minimally - in this day and age when almost every artists has a WEBSITE, an EPK offers minimal value.