Memory-Problems with my wordpress-installation

Ok, so after I expanded my memory limit via LiveConfig to 1024MB I get the following results:

WP Memory Limit: 40M
PHP Memory Limit: 1024M

Of course, I would love to have a higher WP-Limit :wink: - but I don't know, how, as entering any define-WP-(MAX-)-Memory in wp-config.php (whatever the value is) results in whitescreen. - Michael is on it

Oddly enough in my footer is shown:

Memory usage "30/256 MB" - where these 256 come from I don't know :slight_frown:

  • Michael Bissett

    Hi @Matthias, just jumping in here quick. :slight_smile:

    I'm not sure what was causing the white screen issues before, but I was able to enter this:

    define( 'WP_MAX_MEMORY_LIMIT', '1024M' );

    Into your wp-config.php. If you were to look at this section:

    /**
     * For developers: WordPress debugging mode.
     *
     * Change this to true to enable the display of notices during development.
     * It is strongly recommended that plugin and theme developers use WP_DEBUG
     * in their development environments.
     */
    define('WP_DEBUG', false);
    define( 'AUTOSAVE_INTERVAL', 300 ); // Seconds

    I just inserted that define in between those two defines there:

    define('WP_DEBUG', false);
    define( 'WP_MAX_MEMORY_LIMIT', '1024M' );
    define( 'AUTOSAVE_INTERVAL', 300 ); // Seconds

    I can confirm on my end that the WordPress memory limit is now 1024M, both in the "System Info" tab inside of WPMU DEV -> Support, as well as the "Memory usage" text that shows up at the bottom of the admin pages (generated by the TPC Memory Usage plugin).

    Could you confirm on your end that it's showing up properly please? :slight_smile:

    Kind Regards,
    Michael

  • Matthias

    So @Michael, here we go - after we talked in chat I did two performance checks with the P3 plugin performance tester. Once with Custom Sidebars activated - result being:

    WordPress Plugin Profile Report
    ===========================================
    Report date: 9. Dezember 2014
    Theme name:
    Pages browsed: 23
    Avg. load time: 70.6172 sec
    Number of plugins: 51
    Plugin impact: 97.92% of load time
    Avg. plugin time: 69.1496 sec
    Avg. core time: 0.3005 sec
    Avg. theme time: 0.1337 sec
    Avg. mem usage: 112.58 MB
    Avg. ticks: 175,969
    Avg. db queries : 224.52
    Margin of error : 1.0334 sec

    Plugin list:
    ===========================================
    P3 (Plugin Performance Profiler) - 0.0389 sec - 0.06%
    Adminimize - 0.1553 sec - 0.22%
    Capability Manager Enhanced - 0.0062 sec - 0.01%
    Codeschnipsel - 0.0059 sec - 0.01%
    A5 Custom Login Page - 0.0483 sec - 0.07%
    Custom Sidebars - 63.9532 sec - 92.49%
    Custompress - 0.0329 sec - 0.05%
    Dynamic Menu Manager - 0.0024 sec - 0.00%
    Editorial Access Manager - 0.0123 sec - 0.02%
    EG-Anhänge - 0.0156 sec - 0.02%
    EventON - 0.0415 sec - 0.06%
    EventON - Daily View - 0.0050 sec - 0.01%
    Excerpt Tools - 0.0015 sec - 0.00%
    Flipbook Plugin - 0.0128 sec - 0.02%
    Speisen- und Getränke Karte - 0.0412 sec - 0.06%
    iframe - 0.0022 sec - 0.00%
    Support System - 0.0291 sec - 0.04%
    Insert Pages - 0.0007 sec - 0.00%
    Intense WordPress Plugin - 0.4709 sec - 0.68%
    Lock Posts - 0.0064 sec - 0.01%
    Maintenance - 0.0100 sec - 0.01%
    Media Tags - 0.0199 sec - 0.03%
    Nextgen Gallery - 0.8797 sec - 1.27%
    Photoswipe For Nextgen Gallery - 0.0113 sec - 0.02%
    Plugin Organizer - 0.1680 sec - 0.24%
    Post Expirator - 0.0020 sec - 0.00%
    Post Tags And Categories For Pages - 0.0037 sec - 0.01%
    Posts in Sidebar - 0.0072 sec - 0.01%
    Private Messages For Wordpress - 0.0070 sec - 0.01%
    Ps Disable Auto Formatting - 0.0026 sec - 0.00%
    Quick Cache - 0.0124 sec - 0.02%
    Regenerate Thumbnails - 0.0015 sec - 0.00%
    Restaurant Reservations - 0.0155 sec - 0.02%
    Reveal IDs - 0.0112 sec - 0.02%
    Scheduled Content - 0.0041 sec - 0.01%
    Sidebar Manager Light - 0.0145 sec - 0.02%
    Simple Custom CSS - 0.0122 sec - 0.02%
    Simple Image Widget - 0.0057 sec - 0.01%
    Sitepress Multilingual Cms - 1.6203 sec - 2.34%
    TinyMCE Advanced - 0.0010 sec - 0.00%
    TinyMCE Color Picker - 0.0025 sec - 0.00%
    TinyMCE Templates - 0.0015 sec - 0.00%
    Ultimate Branding - 0.0655 sec - 0.09%
    User Role Editor - 0.0163 sec - 0.02%
    User Switching - 0.0220 sec - 0.03%
    WP-DBManager - 0.0059 sec - 0.01%
    Wp Smush Pro - 0.0321 sec - 0.05%
    WP-Benutzer-Avatar - 0.0254 sec - 0.04%
    Clef - 0.0223 sec - 0.03%
    Wpml String Translation - 1.2350 sec - 1.79%
    Wpmudev Updates - 0.0293 sec - 0.04%

    Then without, with the following result:

    WordPress Plugin Profile Report
    ===========================================
    Report date: 9. Dezember 2014
    Theme name:
    Pages browsed: 23
    Avg. load time: 12.7712 sec
    Number of plugins: 51
    Plugin impact: 76.00% of load time
    Avg. plugin time: 9.7067 sec
    Avg. core time: 0.6647 sec
    Avg. theme time: 0.4609 sec
    Avg. mem usage: 132.43 MB
    Avg. ticks: 207,649
    Avg. db queries : 276.83
    Margin of error : 1.9390 sec

    Plugin list:
    ===========================================
    P3 (Plugin Performance Profiler) - 0.0745 sec - 0.77%
    Adminimize - 0.4159 sec - 4.28%
    Capability Manager Enhanced - 0.0114 sec - 0.12%
    Codeschnipsel - 0.0156 sec - 0.16%
    A5 Custom Login Page - 0.0847 sec - 0.87%
    Custompress - 0.0534 sec - 0.55%
    Dynamic Menu Manager - 0.0050 sec - 0.05%
    Editorial Access Manager - 0.0134 sec - 0.14%
    EG-Anhänge - 0.0293 sec - 0.30%
    EventON - 0.0904 sec - 0.93%
    EventON - Daily View - 0.0083 sec - 0.09%
    Excerpt Tools - 0.0034 sec - 0.03%
    Flipbook Plugin - 0.0191 sec - 0.20%
    Speisen- und Getränke Karte - 0.0968 sec - 1.00%
    iframe - 0.0030 sec - 0.03%
    Support System - 0.0547 sec - 0.56%
    Insert Pages - 0.0010 sec - 0.01%
    Intense WordPress Plugin - 0.8115 sec - 8.36%
    Lock Posts - 0.0070 sec - 0.07%
    Maintenance - 0.0182 sec - 0.19%
    Media Tags - 0.0325 sec - 0.33%
    Nextgen Gallery - 1.9579 sec - 20.17%
    Photoswipe For Nextgen Gallery - 0.0229 sec - 0.24%
    Plugin Organizer - 0.2196 sec - 2.26%
    Post Expirator - 0.0041 sec - 0.04%
    Post Tags And Categories For Pages - 0.0070 sec - 0.07%
    Posts in Sidebar - 0.0129 sec - 0.13%
    Private Messages For Wordpress - 0.0126 sec - 0.13%
    Ps Disable Auto Formatting - 0.0044 sec - 0.05%
    Quick Cache - 0.0238 sec - 0.25%
    Regenerate Thumbnails - 0.0027 sec - 0.03%
    Restaurant Reservations - 0.0328 sec - 0.34%
    Reveal IDs - 0.0111 sec - 0.11%
    Scheduled Content - 0.0088 sec - 0.09%
    Sidebar Manager Light - 0.0312 sec - 0.32%
    Simple Custom CSS - 0.0064 sec - 0.07%
    Simple Image Widget - 0.0104 sec - 0.11%
    Sitepress Multilingual Cms - 2.5831 sec - 26.61%
    TinyMCE Advanced - 0.0014 sec - 0.01%
    TinyMCE Color Picker - 0.0040 sec - 0.04%
    TinyMCE Templates - 0.0019 sec - 0.02%
    Tpc Memory Usage - 0.0214 sec - 0.22%
    Ultimate Branding - 0.1068 sec - 1.10%
    User Role Editor - 0.0344 sec - 0.35%
    User Switching - 0.0263 sec - 0.27%
    WP-DBManager - 0.0120 sec - 0.12%
    Wp Smush Pro - 0.0920 sec - 0.95%
    WP-Benutzer-Avatar - 0.0477 sec - 0.49%
    Clef - 0.0537 sec - 0.55%
    Wpml String Translation - 2.4318 sec - 25.05%
    Wpmudev Updates - 0.0728 sec - 0.75%

    Only that I did not really "feel" any bigger performance advantage (in backend) when the Custom Sidebars-Plugin was disabled...

    Next problem being that - according to that test - 50% of the remaining load time is due to WPML - which I simply can't deactivate...

  • Ash

    Hello @Matthias

    I hope you are well today.

    WPML is a huge plugin, so is Custom sidebar pro and this is normal that those will need much memory. But 63.9532 sec for custom sidebar is really unusual.

    I am tagging the developer @Philipp Stracker for his valuable opinion on this.

    Meantime , please let me know something.

    1. Is it a multisite?
    2. Is it a shared hosting? Who is your host?
    3. How's about disabling all plugins and enable one by one and check which one is causing more slowness?
    4. Find if you have any custom script in /wp-content/mu-plugins folder (they are important, don't delete but just move to another folder and check)
    5. Does the speed improve if you enable default theme?

    Please let us know.

    Cheers
    Ash

  • Matthias

    Hey Ash,

    thanks for your reply. Just FYI - I do not see 70s page load time when loading a page myself AND I do not "feel" any notable speed advantage when deactivating Custom Sidebars.

    About (a part) of your questions:

    1.) No, it is not a multisite
    2.) it is a virtual server, 500GB, 16GB RAM, our host is net-spacy.com, considered to be the fastest in all Germany
    3.) I might check that (in parts) later - I just hope to find the time as I have to prepare the "Go-Live" of that page, too (will be within the next 4 days)
    4.) I will check and get back to you
    5.) see 4.)

    • Matthias

      Hey @Ash,

      so I tried the deactivating stuff - no real result. That being said, I must add that the installation originally was VERY fast. After it got slowed down extensively I already had done the "nuke option" to completely re-install - but I did not get the fast performance back.
      Only after I created a new database in LiveConfig and assigned the new database to the re-installation it became fast again. So I suppose that whatever is causing that problem does not "deactivate properly".

      The Memory Limit has been at 1024 already and it's shown, too (I could extend that up to 16 GB, however as the extension from 256 to 1024 didn't do anything I don't see a point in doing even more than the suggested 1024 - let me know, if you think otherwise, please)

      About the mu_plugin... In that folder I do have two php from plugin organizer and from plugin profiler, both of which I installed after I encountered those huge speed problems, so they cannot be the reason, right?

      Hope you can help me here as 15 seconds plus x waiting time to load a "page edit" or "post duplicate" in backend are no fun at all...

  • Ash

    Hello @Matthias

    I am tagging an available developer from second level support line in this thread for his valuable opinion on this issue. Please note that, developer response might be slower than usual staff response, so we appreciate your patience on this.

    Meantime would you please send your admin and ftp login?

    To send me details, please use our contact form: https://premium.wpmudev.org/contact/

    Select: I have a different question
    Subject: Attn-Ash
    Details: Send all required details (admin info and/or ftp details) with a link of this thread, so that I can track.
    Also post a note here once you send the info.

    I will be happy to take a look :slight_smile:

    Cheers
    Ash

  • Jose

    Hi there Matthias,

    Hope you are doing great today :slight_smile:

    Is the performance issue affecting only the backend? or is it also affeecting the front end?

    As per what I can see in you DB report, you have quite a good amount of records and your overhead is huge. It's likely to be the culprit of the bad performance.

    Did you try running a DB optimization? Did it make any difference?

    Could you check with your hosting if they have some automated clean up process in placce for the DB overhead?

    Please advise.

    Cheers,
    Jose

  • Matthias

    Hey Jose,

    thank you for your answer. So: It first and foremost affects the backend - the frontend is ok while not great but may get better when finding the best caching-plugin-option.

    About the overhead - the strange thing on that is that my plugin tells me that each of the tables features exactly 23 MiB overhead - except for four (from your support-plugin, they are at 0 overhead - however, this plugin so far is only installed but not used yet)

    Using the mentioned plugin WP-DB-Manager I made "repair DB" and "optimize DB" - without any result here.

    ABout the cleaning process - here is where the trouble started: Using LiveConfig I used their wizard to install phpMyAdmin. Sadly the result was that instead of the homepage I now found a phpMyAdmin-Login on my site's URL. So I de-installed phpMyAdmin via LiveConfig again - naively believing that that will undo whatever the installation did - only to see that ever since then I have "this domain is not available" to be found at http://1466.customer.net-spacy.com - featuring a "LiveConfig"-image.

    So I hope my hoster will find the problem - as all data still is there as you can see when logging in via http://ftp...

  • Jose

    Hey @Matthias,

    Even when I'm not a DBA, I think I can translate the Mandarin for you. :wink:

    It says basically the following:
    - the optimization will not reduce the overhead due to how innoDB stores the information by default.
    - you need to make a backup of your DBs (.sql dump export).
    - delete all your DBs. Except the default ones (mysql and information_schema)
    - change several config parameters in order to change how innoDB stores the information.
    - restart mysql server
    - restore your DBs by importing the .sql dump created previously.

    In theory, with the new configuration the table optimization will work and your DB will run faster.

    I can not guarantee if the information is accurate, I never tried this on my own server. It sounds rasonable though.

    In order to achieve this, you willl need SSH root access to your VPS.

    Are you willing to try this by your own?
    I believe it would be a goog idea to contact your hosting support and ask them if there is any limitation on your VPS config that would prevent this to work.

    Let me know your thoughts.

    Cheers,
    Jose

    • Matthias

      Thank you for translating, Jose.

      In general I am willing to do a lot on my own - in this particular case I doubt that this would bring a result. As I read a lot about innoDB - and somewhere (sadly I lost the link) I did read that this overhead in fact is not there, it is only wrongly shown by WP-Database, as InnoDB has kind of a "common overhead" for all tables.

      If that were true, any defragmenting would lead to nothing, right?

      It would mean that my real overhead is 39 MiB - which is not THAT big - only that my WPDB-manager adds the 39MiB 64 times and comes to a huge result.

      That would explain two things:

      - Each table shows the exact same amount of overhead - with the exception of the wp_support, tables which are NOT innoDB but myslam
      - When testing to change one of those tables to myslam it had 0 MB overhead afterwards - changing it back to innodb brought it to the exact amount all tables had

      So please advise whether or not I should pursue this "line of investigation" in order to find the reason for the speed bump or whether we should look (hopefully together) otherwise.

  • Jose

    Hey Matthias,

    Well, I assumed that the problem was in the DB, it might be a wrong assumption according to what you read.

    Let's try to figure out where is the bottle neck.

    If we confirm that the problem are the DB queries taking too long, I would give it a try to the optimization described above.

    I took a look in your site loading traffic, and I found a couple of things.
    - The admin side is taking aproximately 15 second to showup for me.
    - The main page is taking aprox. 5 seconds to load. (see image 1)
    - There is a broken image link pointing to http://6 that is taking some time to laod and then failing. (see image 2)
    - The ajax heart-beat calls are taking also 5 seconds average to load. (see image 3).

    For the broken image, you will need to fix the img tag src.

    For the other two points, it may be related to a slow SQL query, or simply to the fact that you have quite a good amount of plugins activated (54).

    In order to know if there is a specific query failing, I will ask you to install the following plugin:
    https://github.com/topdown/WP-Benchmark

    It is not in WP repo for some reason, but I just installed it in my own site and it looks promising.

    Please let me know what do you find with this tool.

    Cheers,
    Jose

  • Jose

    Matthias,

    I changed the settings for the benchmark plugin on your site. The following options should be checked:

    -Show in Admin Footer
    -Show WP Queries
    -Show WP Database Query Errors

    These are the overall results of the admin page Posts->All Posts for my site:
    63 Queries Load Time: 1.566 seconds.Memory Usage: 43.59 MiBPeak Memory Usage: 45.316483 MiBIncluded Files: 200Hooks: 521

    This is the same page in your site:
    319 Queries Load Time: 5,528 seconds.Memory Usage: 29.27 MiBPeak Memory Usage: 32.278717 MiBIncluded Files: 813Hooks: 1613

    Looking into each query execution time, I don't see any issue. The response time is normal. So, we can discard a problem with your DB.

    I believe that the problem is the amount of queries being loaded.
    One specific query that catch my attention is this:
    DELETE FROM wp_options WHERE option_name = 'rewrite_rules'

    There is some plugin or custom code in your site that is calling the function WP_Rewrite->flush_rules several times on each page load.
    This is a very expensive routine, and it should be run only in plugin activation/deactivation.

    The methods calling the flush seems to be de_room_register() and de_Gallery_register().

    Could you run a search into the source code of your project to find which plugin is implementing those functions?
    I would like to see how much does it improves deactivating it.

    Cheers,
    Jose

  • Jose

    Hey Matthias,

    I made a comprehensive debugging on your site.

    It seems that I was misled by the benchmarking plugin. (I was a bit in China too).
    The 'Load Time' parameter ir referred to the whole main page. At first, I read it as the total time for the queries excecution. :disappointed:

    After adding some customization to the bencjmark plugin, I found that even with the rewrite_flush calls, the 300-400 queries are taking up to 1.3 seconds max. Which is a ver good performance for the DB.

    Once I got this information, I started to look somewhere else. I deactivated all the plugins (except those two that you mentioned) and the site loaded in a blink.

    Then, I added each plugin one by one checking the load time increment.
    There wasn't anything unexpected:
    You have 54 active plugins. Most of them are 'heavy' plugins and most of their features are enabled.

    Nevertheless, there are two plugins adding a noticeable overhead:
    - WPML and wpml-string-translation addon.
    - Ultimate Branding.

    Both plugins are expected to add this overhead due to the nature of their features. If you really need to have those plugins enabled, then you need to take a deeper look into the settings and make sure that you have only the neccesary features enabled.

    For the rest of the plugins, I would advice you to go through the whole list and keep only those indispensable.

    As a side note, there is a huge difference loading the page by clicking the menu item vs clicking the reload page button in the browser. The reload button will request all the assets again (instead of using browser cache) and it will almost duplicate the loading time some times.

    To sumarize, there is nothing wrong in your server and nothing broken in your site. The loading time is totally normal given the plugins that you are running.

    Please try deactivating UB and WPML and let me know your results.

    Cheers,
    Jose

    • Matthias

      Hi Jose,

      thanks a lot for checking. About "Ultimate Branding" - that surprises me A LOT - as I had that plugin installed as one of the first - and the site still was as fast as a Ferrari afterwards.

      For WPML - I would love to be able to kill "string translation" - only that it would make my site only partially multilingual (for whatever reason I can enter some things in a .po-file as often as I want to - but only after I "string translate" the exact same entry it shows up multilingual in frontend) - example: the "room facilities" on any given room description. (single_room.php is the template) - any advise?

      WPML itself - well, here deactivating simply is not an option as there is no other way to run this site in five languages to my knowledge.

      EDIT: But coming back to the string translation - if I trust P3 plugin profiler, a kill of that alone would improve my speed by 20-25%...

  • Jose

    Hey Matthias,

    I tried a good amount of times loading the admin page with and without UB activated, and it added aproximately 20% of time. There is a small chance that my tests are affected by my connection. I tried several times activating and deactivating to reduce the connection factor.
    The results were consistent, but of course there are a lot of factors that can mislead. (i.e. some times it takes more time to load because some scheduled task in wp_cron is excecuted only in that particular load).

    Also, you should consider that a plugin might be very fast if you have only a few posts and users, and become slow as the post and user count grows.
    This is because most of the plugins will run some routines looping through pages/posts/comments/user/settings.

    Regarding the translation issue, I can say at a first glance that you have a misspelled word in your template that can be the cause of the issue:
    __('Room Facilites:','Vierra');
    (Facilites should be Facilities).

    Overall, I think that there is not a speed bump here. Even if you deactivate WPML, you still have a slow backend. (10-15 seconds on my end, it might be faster for you maybe).

    There is a quick way to test your plugin without waiting for your admin plugin page to load:
    Create a new folder inside /wp-content/ called 'plugins2' or whatever you like.
    Then, via FTP, move all your plugins from /plugins to /plugins2. (do not access the plugin admin page during this test).
    Once you moved all your plugins you can start testing the load time of your admin, and move back the plugins to the original folder one by one to see how they affect the performance.

    Hope this helps. :slight_smile:

    Cheers,
    Jose

  • Matthias

    WordPress Plugin Profile Report
    ===========================================
    Report date: 17. Dezember 2014
    Theme name:
    Pages browsed: 30
    Avg. load time: 38.7483 sec
    Number of plugins: 53
    Plugin impact: 96.43% of load time
    Avg. plugin time: 37.3635 sec
    Avg. core time: 0.4496 sec
    Avg. theme time: 0.1068 sec
    Avg. mem usage: 100.72 MB
    Avg. ticks: 133,452
    Avg. db queries : 137.23
    Margin of error : 0.8283 sec

    Plugin list:
    ===========================================
    P3 (Plugin Performance Profiler) - 0.0385 sec - 0.10%
    Adminer - 0.0073 sec - 0.02%
    Adminimize - 0.1260 sec - 0.34%
    Codeschnipsel - 0.0050 sec - 0.01%
    Contact Form 7 - 0.0541 sec - 0.14%
    A5 Custom Login Page - 0.4427 sec - 1.18%
    Custom Sidebars - 31.7366 sec - 84.94%
    Custompress - 0.0376 sec - 0.10%
    Dynamic Menu Manager - 0.0024 sec - 0.01%
    Editorial Access Manager - 0.0144 sec - 0.04%
    EG-Anhänge - 0.0155 sec - 0.04%
    EventON - 0.4273 sec - 1.14%
    EventON - Daily View - 0.0281 sec - 0.08%
    Excerpt Tools - 0.0013 sec - 0.00%
    Flipbook Plugin - 0.0118 sec - 0.03%
    Speisen- und Getränke Karte - 0.0390 sec - 0.10%
    iframe - 0.0011 sec - 0.00%
    Imsanity - 0.0065 sec - 0.02%
    Support System - 0.0286 sec - 0.08%
    Insert Pages - 0.0007 sec - 0.00%
    Intense WordPress Plugin - 0.5280 sec - 1.41%
    Lock Posts - 0.0078 sec - 0.02%
    Maintenance - 0.0148 sec - 0.04%
    Media Tags - 0.0202 sec - 0.05%
    Nextgen Gallery - 0.8963 sec - 2.40%
    Photoswipe For Nextgen Gallery - 0.0123 sec - 0.03%
    Plugin Organizer - 0.4331 sec - 1.16%
    Post Expirator - 0.0022 sec - 0.01%
    Post Tags And Categories For Pages - 0.0037 sec - 0.01%
    Posts in Sidebar - 0.0075 sec - 0.02%
    Private Messages For Wordpress - 0.0071 sec - 0.02%
    Ps Disable Auto Formatting - 0.0040 sec - 0.01%
    Regenerate Thumbnails - 0.0007 sec - 0.00%
    Required Phone Number addon for Restaurant Reservations - 0.0013 sec - 0.00%
    Restaurant Reservations - 0.0157 sec - 0.04%
    Reveal IDs - 0.0043 sec - 0.01%
    Custom Late Bookings Options for Restaurant Reservations - 0.0016 sec - 0.00%
    Scheduled Content - 0.0039 sec - 0.01%
    Simple Custom CSS - 0.0051 sec - 0.01%
    Simple Image Widget - 0.0055 sec - 0.01%
    Sitepress Multilingual Cms - 1.9586 sec - 5.24%
    TinyMCE Advanced - 0.0010 sec - 0.00%
    TinyMCE Color Picker - 0.0027 sec - 0.01%
    TinyMCE Templates - 0.0015 sec - 0.00%
    Ultimate Branding - 0.0349 sec - 0.09%
    User Role Editor - 0.0173 sec - 0.05%
    Benutzerwechsel - 0.0377 sec - 0.10%
    Wordfence Security - 0.1730 sec - 0.46%
    WP-DBManager - 0.0144 sec - 0.04%
    Wp Smush Pro - 0.0262 sec - 0.07%
    WP-Benutzer-Avatar - 0.0302 sec - 0.08%
    Clef - 0.0306 sec - 0.08%
    Wpmudev Updates - 0.0360 sec - 0.10%

    after deactivating and deleting "string translation" - the interesting part here for me is that "custom sidebars" now loads apparently twice as fast as during the test above - are there any known issues Custom Sidebars vs WPML?

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.