[Resolved] Can't get LSCache working for guests on my vBulletin forum without affecting members

Status
Not open for further replies.

asabet

Active Member
#1
Hello, I am moving this discussion here from another thread because that one had some other concerns re: Varnish, etc.

Here's my situation:

I have a vBulletin 4.2.2 PL4 forum at
Code:
www.photographerslounge.org
My forum is installed at at $DOCUMENT_ROOT not at $DOCUMENT_ROOT/forum
I am not using vBSEO.

I use Litespeed 2-core version and have been trying to get LSCache to work for guests on my forum, but no matter what I do members are experiencing weird issues with appearing logged out on seemingly random pages as well as sometimes experiencing random changes in forum style applied.

Here's what I've done:

1) Created litespeed_cache.xml from the code on this page and imported it as a product through my vBulletin Admin CP with allow overwrite enabled.

2) Ran the following from SSH as root:
Code:
# mkdir /dev/shm/diskcache
# chown nobody:nobody /dev/shm/diskcache
# chmod 700 /dev/shm/diskcache
# crontab -e
Added the following to the cron list and then wrote out and closed:
Code:
*/10 * * * * root find /dev/shm/diskcache -type f -mmin +8 -delete 2>/dev/null
# /etc/init.d/crond restart
3) Went to LS admin console under Cache and set the following settings:
Code:
Storage path: /dev/shm/diskcache
Enable Cache: No
Cache Expire Time (seconds): Not Set
Cache Request with Query String: Yes
Cache Request with Cookie: Yes
Cache Response with Cookie: Yes
Ignore Request Cache-Control: Yes
Ignore Response Cache-Control: Yes
Enable Private Cache: No
Private Cache Expire Time (seconds): Not Set
Do-Not-Cache URL(s): Not Set
4) Added the following to .htaccess in the domain root:
Code:
RewriteEngine On

## Forward non-www to www
RewriteCond %{HTTP_HOST} ^photographerslounge.org
RewriteRule (.*) http://www.photographerslounge.org/$1 [R=301,L]

## Forward index.php to root directory
RewriteCond %{THE_REQUEST} ^.*/index\.php
RewriteRule ^(.*)index.php$ /$1 [R=301,L]

## Forward vBSEO to non-vBSEO URLs after uninstalling vBSEO
RewriteRule [^/]+/[^/]+-([0-9]+)/ http://www.photographerslounge.org/showthread.php?t=$1 [L,R=301]
RewriteRule ^f([0-9]+)/$ http://www.photographerslounge.org/forumdisplay.php?f=$1 [L,R=301]
RewriteRule ^members/(.+)/ http://www.photographerslounge.org/member.php?username=$1 [L,R=301]

## select which pages to cache
RewriteCond %{HTTP_COOKIE} !bbimloggedin=yes
RewriteCond %{HTTP_COOKIE} !bbuserid=
RewriteCond %{HTTP_COOKIE} !bbpassword=
RewriteCond %{REQUEST_METHOD} ^HEAD|GET$
RewriteCond %{QUERY_STRING} !s=[a-fA-F0-9]{32}
RewriteCond %{QUERY_STRING} !product=vbnexus
RewriteCond %{REQUEST_URI} !^/(login|register|usercp|private|profile|cron|image)\.php$
RewriteCond %{REQUEST_URI} !^/admincp
RewriteRule ^(.*\.php)?$ - [E=Cache-Control:max-age=120]
After doing all that, my guest pages are being cached by Litespeed Cache. “X-LiteSpeed-Cache: hit” response header is verified, and guest browsing is lightning fast. However right away my members start to complain about the login issues, etc. Would greatly appreciate some guidance.

Thanks,
Amin
 
Last edited by a moderator:

asabet

Active Member
#2
Eureka! The problem was that I don't follow directions well :rolleyes:.

IN particular it was this part that I didn't follow:

b. For imported Apache vhost:

There is no need to use mod_cache directive to control cache. You do not need to do anything for the vhost cache policy. It will assume the same default settings as the above natively configured vhost.
All I had to do to get this working properly was to revert these settings:
Code:
Enable Cache: No
Cache Expire Time (seconds): Not Set
Cache Request with Query String: Yes
Cache Request with Cookie: Yes
Cache Response with Cookie: Yes
Ignore Request Cache-Control: Yes
Ignore Response Cache-Control: Yes
Enable Private Cache: No
Private Cache Expire Time (seconds): Not Set
Do-Not-Cache URL(s): Not Set
I set them all back to "Not Set", restarted LSWS, and I am now in business :).
---------------------------------

Update: I spoke too soon. Still getting all the login and style change weirdness. Have no idea what to do next to get this to work :(.
 
Last edited by a moderator:

asabet

Active Member
#4
as I replied in another thread, please rename the cookie name, see if it fixes the issue.
Thank you!

I think it's working now. Just to clarify, I left all the following as "Not Set" because I never configured any virtual hosts in the LS WebAdmin GUI:
Code:
Enable Cache: Not Set
Cache Expire Time (seconds): Not Set
Cache Request with Query String: Not Set
Cache Request with Cookie: Not Set
Cache Response with Cookie: Not Set
Ignore Request Cache-Control: Not Set
Ignore Response Cache-Control: Not Set
Enable Private Cache: Not Set
Private Cache Expire Time (seconds): Not Set
Do-Not-Cache URL(s): Not Set
I didn't touch my Apache httpd.conf either. All I did was change the .htaccess files in my domain root.

When I check a page response headers, I get:
Code:
Status: HTTP/1.1 200 OK
Date: Thu, 29 Jan 2015 10:20:09 GMT
Server: LiteSpeed
Connection: close
Transfer-Encoding: chunked
Vary: User-Agent
X-LiteSpeed-Cache: hit
X-Powered-By: PHP/5.4.36
Cache-Control: private
Pragma: private
Content-Type: text/html; charset=ISO-8859-1
So am I all set? I wasn't sure about the cache-control being "private".

The weirdness for my logged in users seems to be gone now using the correct cookie prefix as you suggested.
 
Last edited by a moderator:

NiteWave

Administrator
#5
>I left all the following as "Not Set" because I never configured any virtual hosts in the LS WebAdmin GUI
no. server level cache policy still need, please follow the guide in our blog.
 

asabet

Active Member
#6
>I left all the following as "Not Set" because I never configured any virtual hosts in the LS WebAdmin GUI
no. server level cache policy still need, please follow the guide in our blog.
I've read that blog post 100 times, but I still don't understand what the bolded part below means:

"There is no need to use mod_cache directive to control cache. You do not need to do anything for the vhost cache policy. It will assume the same default settings as the above natively configured vhost. However, you do need to set the server level Cache storage from the Litespeed web admin console stated in step 2; and put rewrite rules in the .htaccess file as in step 4."

I thought it meant that I should follow step 2 and fill in Cache Storage Settings->Storage Path which I have done as follows:
Code:
Storage path: /dev/shm/diskcache
Is there more to do than that? Do I need to set these:
Code:
Enable Cache: No
Cache Expire Time (seconds): Not Set
Cache Request with Query String: Yes
Cache Request with Cookie: Yes
Cache Response with Cookie: Yes
Ignore Request Cache-Control: Yes
Ignore Response Cache-Control: Yes
Enable Private Cache: No
Private Cache Expire Time (seconds): Not Set
Do-Not-Cache URL(s): Not Set
 
Last edited by a moderator:

NiteWave

Administrator
#8
I mean follow the wiki: https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:cache:lscache
"LSWS Cache + vBulletin" which is a link to http://blog.litespeedtech.com/2011/01/28/speed-up-vbulletin-sites-through-litespeed-built-in-cache/ which you initially followed with.

>Should I put this in my .htaccess?
no need

I thought it meant that I should follow step 2 and fill in Cache Storage Settings->Storage Path which I have done as follows:

Storage path: /dev/shm/diskcache

Is there more to do than that? Do I need to set these:

Enable Cache: No
Cache Expire Time (seconds): Not Set
Cache Request with Query String: Yes
Cache Request with Cookie: Yes
Cache Response with Cookie: Yes
Ignore Request Cache-Control: Yes
Ignore Response Cache-Control: Yes
Enable Private Cache: No
Private Cache Expire Time (seconds): Not Set
Do-Not-Cache URL(s): Not Set
correct and yes you need set it (this is server level cache policy)
 

asabet

Active Member
#9
correct and yes you need set it (this is server level cache policy)
If you look at the blog post you linked, the Cache policy is under Step 3a, which is for "natively configured vhost" (not my situation)

Then under Step 3b, which is for "imported Apache vhost" (which is my situation), it says:

"You do not need to do anything for the vhost cache policy. It will assume the same default settings as the above natively configured vhost. However, you do need to set the server level Cache storage from the Litespeed web admin console stated in step 2; and put rewrite rules in the .htaccess file as in step 4."

Which suggests to me that those settings for Cache policy under Step 3a were not applicable.

So bottom line from what you're saying is that I should set the server level cache policy in the LiteSpeed admin console, correct? After doing so, my response headers still look like this:
Code:
Status: HTTP/1.1 200 OK
Date: Thu, 29 Jan 2015 11:49:11 GMT
Server: LiteSpeed
Connection: close
Transfer-Encoding: chunked
Vary: User-Agent
X-LiteSpeed-Cache: hit
X-Powered-By: PHP/5.4.36
Cache-Control: private
Pragma: private
Content-Type: text/html; charset=ISO-8859-1
Is that how it should look? Should cache-control be private?
 
Last edited by a moderator:
#10
I think we should update the blog per your feedback. Thanks.

following 2 headers should be generated by php code (vBulletin)
Code:
Cache-Control: private
Pragma: private
only
Code:
X-LiteSpeed-Cache: hit
is generated by litespeed.

those headers from php is completely ignored, and it's relating to the cache policy setting:
Code:
Ignore Response Cache-Control: Yes
 
Last edited by a moderator:

asabet

Active Member
#11
Thank you. If I may, would also suggest a few other changes for the blog post:

1) "bb" to "bb_" since "bb_" is the default for vBulletin

2) Making explicit what changes need to be made to the rewrite if vBulletin is installed in the forum root as opposed to /forum directory since both are very common choices

3) Stating that /dev/shm/diskcache is an option for cache storage (this is stated in the blog post for vBSEO users but not the main vBulletin blog post

4) Giving more details about how to add a cron service for clearing the cache (I'm still not 100% that I did this correctly)
 

asabet

Active Member
#14
Sadly, I had to disable LSCache despite the major benefits.

I am using a mod to recognize mobile users (phones, etc) and switch them automatically to a certain vBulletin style for mobile. What was happening with this LSCache implementation was that guest visitors were sometimes being sent to the mobile style even when visiting from a non-mobile device. That had a noticeable effect on ad revenue.

I'm sure that LSCache is a beautiful solution for busy vBulletin forums that don't use the particular mobile style kludge solution I came up with, but it's not going to work for me.
 

NiteWave

Administrator
#15
a solution is to cache 2 copies for a URL: one is for mobile device, another is for non-mobile.
the difficulty may be at how to detect a device is mobile. you can read the source code of mod for mobile user, if it detects that by user-agent.

if so, here's sample code to distinguish mobile-device and non-mobile:
just before
Code:
## select which pages to cache
adding following rules:
Code:
RewriteCond %{HTTP_USER_AGENT} "android|iphone" [NC]
RewriteRule ^(.*\.php)?$ $1?mobile_user=1 [QSA]
 
Last edited by a moderator:

asabet

Active Member
#16
Ultimately the simplest solution for my needs was to exclude mobile users from caching altogether because I want to let mobile guests switch to desktop view and vice versa. These are the rules I've been using, and they seem to work well:

Code:
## select which pages to cache
RewriteCond %{HTTP_USER_AGENT} "Windows|Mac|linux|os\s+[x9]|solaris|bsd|spider|crawl|slurp|bot"
RewriteCond %{HTTP_USER_AGENT} !"iPhone|iPad|Android|Mobile|Phone"
RewriteCond %{HTTP_COOKIE} !bb_imloggedin=yes
RewriteCond %{HTTP_COOKIE} !bb_userid=
RewriteCond %{HTTP_COOKIE} !bb_password=
RewriteCond %{REQUEST_METHOD} ^HEAD|GET$
RewriteCond %{QUERY_STRING} !s=[a-fA-F0-9]{32}
RewriteCond %{QUERY_STRING} !product=vbnexus
RewriteCond %{REQUEST_URI} !^/(login|register|usercp|private|profile|cron|image)\.php$
RewriteCond %{REQUEST_URI} !^/admincp
RewriteRule ^(.*\.php)?$ - [E=Cache-Control:max-age=600]
 

NiteWave

Administrator
#17
Thanks for the update!

if most of users are from mobile, can cache mobile pages only instead of caching desktop pages only.

from above rewrite rules, it looks possible to cache both mobile and desktop pages as well.
just FYI:
Code:
RewriteCond %{HTTP_USER_AGENT} "iPhone|iPad|Android|Mobile|Phone"
RewriteRule ^(.*\.php)?$  $1?mobile_view=1 [QSA]

RewriteCond %{HTTP_COOKIE} !bb_imloggedin=yes
RewriteCond %{HTTP_COOKIE} !bb_userid=
RewriteCond %{HTTP_COOKIE} !bb_password=
RewriteCond %{REQUEST_METHOD} ^HEAD|GET$
RewriteCond %{QUERY_STRING} !s=[a-fA-F0-9]{32}
RewriteCond %{QUERY_STRING} !product=vbnexus
RewriteCond %{REQUEST_URI} !^/(login|register|usercp|private|profile|cron|image)\.php$
RewriteCond %{REQUEST_URI} !^/admincp
RewriteRule ^(.*\.php)?$ - [E=Cache-Control:max-age=600]
 
Last edited by a moderator:

asabet

Active Member
#18
Most of my users are from desktop.

My concern is that if I use this:
Code:
RewriteCond %{HTTP_USER_AGENT} "iPhone|iPad|Android|Mobile|Phone"
RewriteRule ^(.*\.php)?$ $1?mobile_view=1 [QSA]
Then if a mobile user manually switches to desktop/full site view (still with mobile user agent), then the next mobile user could potentially be served that desktop view from cache.
 
Last edited by a moderator:

NiteWave

Administrator
#19
revisited your website.

when a mobile user select desktop view, the URL with "styleid=-1" added in querystring, and 2 cookies are set
Code:
bb_userstyleid=-1
bb_skipmobilestyle=1
change
Code:
RewriteCond %{HTTP_USER_AGENT} "iPhone|iPad|Android|Mobile|Phone"
RewriteRule ^(.*\.php)?$ $1?mobile_view=1 [QSA]
to
Code:
RewriteCond %{HTTP_USER_AGENT} "iPhone|iPad|Android|Mobile|Phone"
RewriteCond %{HTTP_COOKIE} !bb_skipmobilestyle=1
RewriteRule ^(.*\.php)?$ $1?mobile_view=1 [QSA]
may improve the cache.

>Then if a mobile user manually switches to desktop/full site view (still with mobile user agent), then the next mobile user could potentially be served that desktop view from cache.
==> this may not be a problem since the cache's URL will contain "styleid=57", does not match "next mobile user"'s request URL which don't contain "styleid=".
 
Last edited by a moderator:
Status
Not open for further replies.
Top