Reply To: Suggestions for scaling ACF

• John Huebner

• August 26, 2016 at 4:27 am

Witt the optimization built into MySQL and the WP tables (all having proper indexes) for performing the queries that are done, there really should be little effect on the speed of a site based on the database size. I’m not sure where you heard that it would. I have some sites with huge databases and as many as 100 fields on some post types using flexible content fields and repeaters with no performance issues on the front end. On one site there is a repeater field and each of these repeaters can have up to 7 WYSIWYG editors and associated fields for a total of about 70 fields per repeater and there is not limit to the repeaters. There are as many as 20 of these repeaters on some posts for a possible total of over 1000 fields. Like I said, I don’t see any performance issues on the front end. If there is any performance loss then it is undetectable.

On the other hand, a search using the standard WP search that does a %LIKE% query for every word in a search request on 100K+ posts…. that’s going to die, and this has nothing to do with ACF. There is no index on “Content” fields in the database. I would suggest that you look for a different way to do site searches on a site this size.

If you do a searches and do some research on it you will find that MySQL does not see performance issues on large databases when the tables are indexed properly.

The back end is a different story entirely, and this really doesn’t have anything to do with ACF, but with the way that WP handles updating the post meta values…. one at a time. ACF simply uses what WP makes available. You would see the same problem whether you use ACF or custom build the custom fields yourself. Because of this, too many fields being submitted on a single admin page will likely cause you issues. That site I mentioned above with the more than 1000 fields on a post, those posts time out when hitting update, why, because WP does more than 3000 queries to update those fields (agian, WP, not ACF), and that does not include the field_key queries. Like I said, nothing to do with ACF. If I had built all these fields myself the result would be the same. That site was built a while ago and since that one I am extremely careful about how many fields I build into a single admin page. When I see that the number will be high I find an alternate way to do so, for example, creating multiple edit pages. I could have, for example, instead of using a repeater field in this case I could have created a hierarchical post type where the “Repeaters” were actually child pages. Although this would have more of an effect on front end performance because it would mean querying for those child pages.

Hope that helps.