CiviCRM Community Forums (archive)

Hi,

IMO stable enough to migrate. As for bugs, they will be some in the 3.4.1, as they are still on 3.3.6.  But a bit of a chicken and egg problem: if you don't migrate, you won't hit the bugs that might be specific on your config, so it won't be fixed.

I'd migrate on your test environment and see if it works on your case. For what I've seen the 3.4 bugs are not bigger than any 3.3.x migration.

X+

Hi,

Then use your own computer as a test, backup your database and install on your computer, install civicrm 3.4 and to the migration there. At least if you got a big issue after the migration, you are only having this problem on your own test version.

X+

Thoughts? Firstly your RAM usage in Apache or PHP should not be connected to whether you run multiple sites or one multi-site. It should be a function of how many concurrent processes you have and that's it.

Secondly, yes, you should use two DBs for a test site.

Third, yes, it's definitely recommended to have a dev site. If your VPS can't handle it, I would even consider finding another host just to host the dev site--needs for that should be simpler because only a few staff members (I presume) will need to access and test it.

I think your understanding of RAM usage is not quite complete. Installing 10 sites on your VPS and 20 databases won't actually affect the RAM usage.

Various Linux processes must run and those take up RAM. Beyond that, the only way YOU can use more RAM is to request a page from the VPS. So if you have one site and 10 people request a page (in their browser) at the same time, then you have 10 PHP processes running and each can use from 20 to 200 MB RAM. But that's more or less the same whether it's 10 sites and one page on each or 1 site and 10 requests on that site.

So if you install 10 sites but your usage (i.e. how many pages are being requested) it shouldn't really affect your RAM usage.

In my mind, more sites and DB's surly meant more memory utilization.

All right hershel and xavier, I shall set up my test copy of prod on the prod VPS and test the upgrade to 3.4.1 Thank you.

I successfully completed a test copy of production Drupal / CiviCRM / UBB.threads last evening. Thankfully not much of a spike in memory utilization.

In the .htaccess I have the test subdomain locked down to only accept connections from my IP address, thus preventing use of the test site.

Soon to pull a full backup of the newly created test copy, then dig into the Civi upgrade to the 3.4.x series! 

I keep them separate. One reason is for portability--it's easy to move just one or the other when required. And I do sometimes do that. Also for major upgrades like D6 - D7, when problems can easily occur, it's far easier to be able to upgrade one at a time and not have to worry about synchronizing them.

Also if a CiviCRM upgrade causes a problem and the client doesn't notice it for 3 days, and then he decides he does want to rollback his CiviCRM, you can then rollback just that data and not his Drupal data.

Those are a few reasons why I always use two databases.