In an effort to get some short-term performance boosts, we identified a few customers who were running resource-intensive scripts that were exacerbating the file system issues. We helped our customers reschedule these scripts and saw a marked improvement in performance.
We scrambled to identify the problem again, and discovered multiple possible causes, including:
- Sites with over 250,000 files stored (!), which was causing backups to take longer. In a number of cases, the site owners did not need all these files, and so we were able to eliminate over 1,000,000 files from the file system, which helped a little.
- Customers with complex scripts set up to run every 60 seconds -- if these scripts moved files or otherwise manipulated the file system, we coordinated scheduling changes to mitigate the effect. This helped a little.
- Customers with daily backup and data-import scripts that ran at the same time as our global system backups, or during peak utilization periods. We coordinated scheduling changes with these customers to run these daily scripts in the evening, after traffic loads have subsided but prior to midnight when our backups begin. This helped a little.
Additionally, we made some server configuration changes which proved fruitful. While system loads remained high, the effect of the high load on hosting performance was reduced. So, performance has been much better but still not where we want it to be.
The good news is that we are making excellent progress on our storage architecture re-engineering project. We expect this change to have a major impact on performance and scalability of the Modwest shared system. We'll keep you posted as we have more to announce.
P.S., In the meantime, a note for technical site owners: Given our current situation, minimizing your site's reliance on the file system could help performance. One way to do this is to move your PHP sessions from files in the /tmp directory to your database. We just launched a new FAQ on this topic.