Why I hate WordPress - it's the update thing

@Jeffr2014 : That's fantastic! That's a good starting point for me. Thanks for taking the time to check those logs.

There is absolutely no problem with the plugin reputation. Please feel free to say it's good or useless, provided that there is the necessary reasoning or proof. All that worried me and made me somewhat suspicious was the fact that there was missing information (such as a version of the plugin that performed better than 2.6.7 in your environment) both in your OP in these forums and also in the post on the WordPress Support forums. It turns out this was not intentional, so everything is good.

Apart from all this, may I ask why don't you use a caching plugin, which would store static versions of your pages and serve them instead of generating each dynamic page on every HTTP request? This way you won't have to worry about the page generation time. An even better solution would be to add a caching reverse proxy in front of your web server or use a CDN service. By saying this, I do not mean to interfere in the way you work, but I just wanted to point out that you are possibly worried about the wrong things here.

 

We do and we love Wordfence Falcon caching. Yet, we have many pages that are highly dynamic or have AJAX based dynamic sections - these just cannot be cached in efficient manner. As for CDN service, we have some experts in-house who advise against using CDNs (sorry, this is not something I can discuss here).

 

That's exactly where the cloud comes in. Everything should be put on the cloud and maintained in the backend by IT professionals rather than being worried about by business men.

 

I see. Currently, it is impossible to avoid the overhead of Add-Meta-Tags generating the metadata on each HTTP request.

However, I can imagine of ways it could be avoided. For instance, the metadata could be made available as plain text from a custom URL, eg (/foobar/POST_ID/) and an option to stop autogenerating it on every request could be added. This way /foobar/POST_ID/ responses could be cached in memory and used by each respective page. Also, the plugin could make it possible to use custom code (through a filter maybe) to cache the generated metadata. Implementing a metadata caching mechanism within the plugin would also be possible, but I don't like the idea much. Also, varnish's ESI feature comes into my mind, but I've never used it before, so I am not sure if it can be a solution.

Anyway, currently there is not much that can be done. Time permitting, I'll investigate how it would be possible to avoid the metadata generation overhead on every request.

Kind Regards to everyone,
George

 

I spent several hours testing and benchmarking. The most reliable results can be achieved by benchmarking a server on the local network with all irrelevant services shut down using the ab tool (with concurrency set to 1). I was able to get a delay of 30-35ms sometimes 40ms (results are not consistent even in this setup) when Add-Meta-Tags was activated. I tried commenting out various features of the plugin in an attempt to determine if there is a specific feature that is more CPU intensive than the others. This was not the case. The delay is a result of all the enhancements of the plugin development during the last months. Also, sanitization functions (which are also cpu intensive) are used extensively throughout the code in order to make the plugin as secure as possible. This is not going to change.

As I've written earlier, let me know if making the metadata available as plain text or json data on a custom URL like /foobar/POST_ID/ makes your life easier with caching. This is doable, but it will take some weeks before I finally test and implement it. Currently there is absolutely no free time at all.

IMHO, if this is about public data which people access anonymously, then having to generate the page on every visit is not efficient at all and my suggestion would be to focus on caching.

If possible, please use the WordPress forums for further discussion.

Kind Regards,
George