Viewing 15 replies - 76 through 90 (of 94 total)
  • We fixed this our end.

    Check your PHP fpm.log file and see what errors show, like:
    WARNING: [pool www] server reached max_children setting (4)

    Basically the php processes were maxing out so we bumped up the PHP to allow 8 processes at 256MB.

    I’m wondering if anyone has found a fix for this on 4.3.1? We’re currently having the same issues everyone else described. It appears to be just in the backend as well. The frontend seems fine (usually anywhere from 1 second to 2 seconds to load a page). The backend though can take anywhere from 30 seconds on up to load.

    The worst I’ve noticed is while removing discontinued items from our website, I received a 503 error mentioning resources have been expended. We have 320M for our memory limit and 10000000 as the max_execution_time so for us to receive that error seems crazy. I haven’t had any issues prior to 4.1 and below. It seems to have only started happening since 4.2 and on up.

    I encourage everyone looking for a fix to take a look at the link I posted above (https://core.trac.www.ads-software.com/ticket/24498#comment:35). I did a deep dive to figure out why this happened and concluded that there is a bug that causes indices to be ignored when the meta_key is utf8mb4.

    I have found that this issue can be resolved if you change the meta_key field back to utf8. The link has the full story.

    For those looking for a temporary fix, I would investigate changing the meta_key charset to utf8.

    We’ve filed a ticket with MariaDB regarding the indexing issue. If you could upvote it, it might get more attention: https://mariadb.atlassian.net/browse/MDEV-8872.

    @zack I just tried your temporary fix and while it did help speed up the back end, it eventually lead to a 503 error forcing me to revert it back.

    Following your suggestion, I went into our database and went into the wp_postmeta table > meta_key column. I changed it from utf8mb4_unicode_ci to utf8_unicode_ci, seeing as that is the closest option for UTF8 via the panel.

    After working awhile in the backend, it became stuck and while monitoring our sever via SSH, multiple processes began running at 100% CPU and eventually ran our server dry.

    For anyone else experiencing this issue as well, it seems like following @frosy advice seems to have helped on our end. We use a plugin that adds more features into Woocommerce that when multiple people were crawling on our website, it ate away at our server. Be sure to check through your error logs as well to see if something else might be causing any issues. Using a plugin like Query Monitor helped me do some investigating on to what might really be causing issues on our end.

    I bumped our “FcgidMaxProcesses” from 20 to 100 and it seems to have helped ease the flow of CPU over usage and other errors. For those still looking for any help, we use a NGIX VPS server and it can be found in “/etc/httpd/conf.d”. There you would just change the “fcgid.conf” file and change the number for “FcgidMaxProcesses”.

    This helped us and I do advice only doing this if you know what you’re doing and how to revert back incase anything happens.

    So as someone not from an IT background I still see the slow backend.

    I am concerned about editing any code.

    Has a fix been launched. Site updates are not practical s its so slow.

    Update: It seems like even bumping up the processes was only a temporary fix before once again running into issues. Where we’re noticing a lot of slow load times and issues in the back end is anytime we update a product. For whatever reason it takes a significant amount of time to update a product.

    8erotic

    (@8erotic)

    This issue is still occuring. As someone with NO IT background and learning this as we go, we don’t know what to do. It’s only the Edit screen doing this. Quick edit is fine. Can someone please tell us how to work around this? I’ve read this entire thread and I don’t know how to implement the suggested changes. Any assistance would be wwonderful.

    Do any devs have any more information on this? This issue is still occurring. I received a 503 error code earlier today mentioning our servers ran dry while trying to update one of our products (which has little to no data attached to it). Never ran into these issues prior to 4.2 and earlier.

    I feel like reverting back will only cause more issues as well. If I remember right, I believe I read a dev mentioning there were no issues with slowness on the backend. This thread, 3 pages long now, begs to differ. If there is someone on the woo team who would like to replicate any of these issues, I am more than willing to send you a copy of our database with all plugins we are currently using. I shouldn’t be receiving a 503 (over capacity) error from just simply updating a product.

    I still have the same issues – backend only. I don’t have the technical knowledge to clear it up.

    We discovered that the attributes was slowing things down. In the last update we did, it loaded thousands of choices for an attribute i.e. L, XL, M, S, to EVERY product and we have over 10 thousand. We manually went in and deleted the attribute category and while things aren’t as fast as we would like them, they are faster.

    Hello, sorry to ask here but I am looking for essential plugins or information to speed a Woocommerce shop, could you tell me what I should do when after installing a shop I find it quite slow (but other shops CMS load well on the same hosting company). Thank you.

    In wp-admin/includes/template.php comment the following (line 613 in WP 4.4.2):
    $keys = $wpdb->get_col( $wpdb->prepare( $sql, $wpdb->esc_like( ‘_’ ) . ‘%’, $limit ) );

    The above will remove all functionality in the default WP custom fields section in WP Admin for any post type (page, post, CPT). Any API calls to postmeta functions will continue to execute properly. I use ACF for custom fields and I don’t see the need for the default WP custom fields section for WooCommerce orders.

    You will need to make the modification above when you upgrade/downgrade WP. I could not find a hook to remove the above query.

    Has there been any further progress on this issue?
    I only have 57 products (book titles and photos) entered into Woocommerce and I have many more to go. It is too slow to work with right now. I was able to flush out the transients without much improvement.

    I am reluctant to make any changes in the core as that is not where my expertise is.

    Thanks,

    Bit of an update on our end: After some more issues with loading times, I had a buddy take a look at our site and he zeroed in on the issue which was our host. We use to use Media Temple’s VPS and the way it was set it would run a single process 3 to 4 more times than it needed to, essentially killing the server.

    Since identifying the issue, we’ve swapped to Amazon’s Web Service and set up a new server there and it is a night and difference. Even with our heavy processes, pages take a max of 3 seconds to load. Most seem to take only 1 to 2 seconds to load. The backend is tremendously quick.

    Originally I thought it was WP or WooCommerce because of the way it was being processed. I recommend anyone who is still having issues to take a look into their host or even have someone help set up a AWS set up. AWS has been, so far, the best host set up we’ve had.

    Edit: Since swapping hosts, it is most DEFINITELY not WP or WooCommerce. WooCommerce and WP is blazing quick now. I’ve done the same testing since swapping hosts and the processes that were slow are almost non-existent now since they’re not being repeated multiple times.

Viewing 15 replies - 76 through 90 (of 94 total)
  • The topic ‘WooCommerce extremely slow after WordPress 4.2 update’ is closed to new replies.