VERY slow page loading when using S2 to protect posts

Hi, I have 4000 posts that I need to protect. they are accessed from a page that has an advanced search panel on it, search results are returned to the same page.

I originally set S2 to protect all posts but the page took nearly 2 minutes to load. I tried categories and this was better but still slow.

The best option for speed was to simply restrict access to the search page this made no impact to the speed (Great) but left me with 2 issues:

  1. the menu item for that pages also disappeared and also google can index the posts giving users direct access without paying.

My Ideal solution:

  1. Protect all posts (only show excerpt from title to non members)
  2. Don’t slow down page load too much
  3. Allow Non members to see the search page and the number of posts available, and even to use the search feature BUT to only see an excerpt of the titles of the results.
  4. Maybe have the posts indexed by the search engines but for non members not to see the whole posts

Can I do this/how? Any ideas gratefully received

I am in the process of basically doing a similar thing but on a much smaller scale. My findings are that on shared hosts s2Member is slow, not because of programming but the quires it takes when it looks up something in the database. I am not sure how your site works, the flow seems confusing to me but if you want a lighting fast server and search function I’d suggest what I am about to do. I am going to install the front end wordpress with the minimal plugins. Then have a member area where I again link all my static pages to the membership pages. I am going to keep everything on an ssl in the same domain so the browser doesn’t see a change and will keep the user logged in. To hunt for content they will be on the fast front end and then link the content back to the members area for protected items. The the user, everything will be snappy until they go to actually download the content or see the protected stuff.

I am having speed issues and I have been on 4 servers so far, all from different hosts. Unless you go with a expensive server your site will be slow will calling to the database. This was just my way to achieve good Google rankings for my site speed on the public end.

If you do some testing you will most likely see when your db is called there is a huge delay or wait time. I can’t seem to get rid of this unless I move to two installs.

Hope this helps,
Ross

The issue here isn’t s2Member’s protections. It’s an inherent and well-known issue with the WordPress search function. Among other things, this makes customizations and integrations with other plugins very problematic. (Just ask the developer of the Relevanssi plugin!!)

You could try mitigating this with a live search plugin. But if you have a very large site, the only way you’ll ever really overcome this is to use an entirely different search tool. Something like ElasticSearch, for example, will just zip along. But it’s not straightforward to configure.

Moving /tmp off disk into memory (/etc/fstab entry using tmpfs) may resolve your problem.

This tends to be one of my first steps when setting up a new machine or LXD container for my hosting clients.

/tmp gets targeted for two heavy weight activities.

  1. MariaDB/MySQL temp tables are written/read using /tmp.

These tables get created whenever a complex SQL SELECT exceeds memory buffers.

  1. PHP session data, to ACL pages can be written here, depending on how all code on your site implements session handling.

When a page transition occurs on your site (moving from one page to the next), the validity of the transition must be determined. This process can involve reading + writing session data many times.

Way better for these activities to run at memory speed, than disk speed.

Also, be sure you’re running…

  1. The latest stable Linux Kernel - 4.10 as of today.

  2. Your /var/lib/mysql file system is ext4 with mount options of noatime,dioread_nolock.

  3. Latest version of MariaDB -10.2.6 as of today. Simply deinstalling MySQL + installing MariaDB fixes many performance problems.

  4. Goes without saying you’re best served to be running latest Apache + HTTP2 + SSL - 2.4.26 as of today.

  5. And latest PHP - 7.1.6 as of today.

Having your entire LAMP Stack up to date + tuned makes a huge difference.

By tuned, run mysqltuner + mysql-tuning-primer on a regular basis + change whatever’s reported.

Also ensure PHP Opcache memory is sufficient, by tracking this on a regular basis. I usually start with 1G for complex sites.

Also enable you slow query log + track it. Recently I took on a new client who had written custom SQL code which was reading a data table with no indexes, so was reading nearly 1,000,000 rows repeatedly with 0 rows returned.

Both slow query log + the WordPress Query Monitor plugin (which I run on all my client’s production sites) will report areas of slow down.

After you’ve implemented all the LAMP refinements mentioned above, then use Query Monitor to pin point other areas of code which require refactoring/rewriting.

2 Likes