Skip to first unread message
leonardo...@gmail.com
Apr 3, 2020, 10:55:53 AM4/3/20
to AtoM Users
Dan Gillean
Apr 3, 2020, 11:42:42 AM4/3/20
to ICA-AtoM Users
Hi Leonardo,
How many, approximately, is "many more"? How often do you expect these users to all be working in AtoM at the same time? What version of AtoM do you have installed, and what hardware specifications do you currently have?
In general I would suggest the following:
1) Upgrade to the latest version if you haven't already. With each recent release we are including not only many bug fixes, but also in the major releases some important performance improvements. 2.6 will see even more scalability and performance enhancements, but since it will still be a while before 2.6 is ready, we are currently preparing a 2.5.4 release where we have selected some of the most important performance improvements that can be applied without requiring major dependency changes, so our community doesn't have to wait as long for these. I have started adding some details on our wiki here:
We hope to have 2.5.4 ready for public release in the next month or so - stay tuned!
2) If possible, increase your hardware resources. Making sure your server has enough CPU, disk space, and memory can help with performance. We recommend at least 2 vCPU, 7GB RAM, and 50GB disk space for most production websites, but if you are able to increase beyond these, it will likely help.
Another possibility is installing some components in their own separate VMs or servers - such as the database, and/or the Elasticsearch index. This can allow for tuning the performance of each server differently. I can't provide a lot of details on exactly how to implement this (I'm not a developer or a systems administrator), but it is a common deployment practice for large web applications, so you should be able to find general resources. There is one previous forum thread I can think of that might be helpful:
3) Increase PHP execution limits if you run into timeout issues. See:
4) Try to keep user / group permissions as simple as possible. With many users, there is a temptation to add a lot of custom group permissions, and to try to configure AtoM so that no user can view or edit the work of another user. However, AtoM's permissions module is one of the areas most in need of major development for performance improvements, and trying to apply many custom restrictions can lead to timeouts currently. I've previously written about this in the forum here:
5) Consider a 2-site deployment model. Another way to increase end-user performance in AtoM is to deploy two sites - one as an internal read-write edit site for your users, and the other as a read-only site for public access. You can then use a replication script to copy data from the internal site to the public site as needed, with no downtime for your public users.
Artefactual offers this as part of our Premium+ hosting plan, and we make the replication script we use for this service publicly available, here:
We have some slides that explain the concept and how to configure the script available here as well:
I hope this helps!
Cheers,
he / him
On Fri, Apr 3, 2020 at 10:55 AM <leonardo...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/151ac915-44b4-4170-90c9-6723edbe6ca6%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages