RFH Database Asp.net apps sluggish

[RFH Reseller: spire128]

Hi

Does anyone else feel that RFH is slower than it used to be, I have a a copy of Nop commerce running in a sub domain on RFH and it is o so slugish even after it has been woken up so to speak (asp.net), in fact I can run it quicker on my on development sever in my garage, and my server is 10 years old and is running 8 virtual machines on it and my web apps load quicker than when on RFH.

[RFH Reseller: anti-theatre]

I hadn't noticed anything, and haven't had anything reported to me. But not sure I am using the same DB as you. What DB are you using?

[Staff: Warren Ashcroft]

We are aware of a problem with performance when backup routines are running in the background, we're still investigating this issue/fix however feel free to raise a support ticket so it can be updated.

[RFH Reseller: neogic]

Interesting - it's a tricky situation, as on-demand backups are pretty vital (e.g., I often take one before I'm about to make major changes, so delaying until off-peak hours isn't ideal), yet presumably site + DB backups are extremely taxing on resources (DB processing, disk IO, memory to compile GB ZIP files, etc).

Any ideas for a fix strategy? Warren - can the backup process be assigned a relatively low processing priority? That's what I've seen elsewhere, along with low priority for stats processing etc.

Given that a single backup is only allowed every 24 hours, perhaps the answer is some sort of more structured automated backups system? E.g., automatic backup jobs can be scheduled for every X days, with rotation after X backups (defined per job). The advantage being that these automatic backups can then be scheduled for off-peak hours, and there'll be less demand for manual backups?

Ideal would be if automated backups could potentially be saved to a central SAN, FTP server or similar (with suitable redundancy), instead of the local HD. We'd considering a modest add-on fee for this sort of service - automated redundant backups that don't use up space from our main allocation.

Just ideas - reducing the priority of the backup processing is an easier stop-gap, if it's technically viable.

Cheers, Ben