-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
frontpage not using boost cache #21
Comments
Like you suggested in a another issue, i've added in nginx.conf
And commented out and added in drupal_boost.conf
With this setup frontpage is loaded from the boost cache for anonymous users, but only if index page exists in the cache folder. When i clear the cache, frontpage will not load, i get the drupal's "The requested page could not be found." error For logged in users the frontpage fails to load, except if i request the index.php directly (i.e. somewebsite.com/index.php) |
Hello, I'm working on a new version of the config that fixes that issue. I'll push it tomorrow morning (GMT). Wait just a little bit. That workaround is broken. |
Oh cool. Thanks for this wonderful config though, i tested my box with ab, and your config can handle 33 times more request than mine lol! |
I've pushed a new config and I tested the frontpage cache. Try it out and report back. |
It says i'm missing fastcgi_drupal.conf |
Oops fixed now. |
Weird behavior with this one. |
That's really strange I cannot reproduce it. I just logged in a boosted site using this config :( |
Did you remove the previous hack? The one about /index.php not being cached? |
Yeah, i cloned the whole thing again and reconfigured. I'm using pressflow distro could that be the problem? |
Oh. You're on D6. Then use the previous config, i.e. the |
I have a very ugly hack to make the front page caching work on D6.
|
I'm testing this. Stay tuned. |
Yes, i'm using D6 pressflow :) I can get the frontpage to load now with the drupal_boost6.conf |
Ok. I fixed one issue. There was a Nginx cache setting on the boost config (facepalm). It should work normally minus the frontpage not being served from Boost cache. I'm working on it. |
Ok. I pushed the fix. It was quite simple. But as usual simplicity is the most elusive of qualities. Try it out. |
It definitely works! :D Any ideas why i get 405 Not Allowed when trying to login with clean /user/login url? Other clean urls work just fine. |
Another issue while it worked initially, the index.php is now offered as a download file when visiting frontpage. |
It seems that Boost is caching the login page and somehow the POST is hitting the cache. I suspect of a Boost issue. I pushed a workaround. Is commented out. Basically I added an exact location for
|
That can only happen (download of index.php) if you have not enabled the FastCGI or proxying to an upstream that handles the PHP. e.g. (apache + mod_php). Check your PHP setup. |
I've got fastcgi running with php-fpm listening on a unix socket, not using apache at all for two weeks now. Not sure what is going on, socket is alive processes running... all i've done recently is fiddle with nginx configs and its obviously not an nginx config issue, since index.php is being downloded with the my old (slow) working one too |
I reinstalled your config again, and set it up only changing what is absolutely necessary for it to work on my setup. Changes i've made to the config are specific to my nginx server version recommended in the config. What i've got now is a working and boosted version for anonymous users. This is an issue specific to my setup and your config. If I reinstate my old config things are back to normal (contrary to what i've been claiming in my post above, sorry about that), I can login and pages are served from boost cache for anonymous users. Additionally I've noticed /var/cache/nginx/microcache is not being populated, but that I guess is not related (except if microcaching supposed to work for logged in users only?) |
Yes. The microcache is just populated if you're using the FCGI cache. The directory is created but no filesystem beneath it. The UNIX socket will work without any issues. However when on a high-traffic site up until 5.3.8 TCP sockets are, according to my experience, much more reliable. Glad you solved all issues. |
You've probably misread my post, I reverted to my old config just to double check if there is a problem with FastCGI (there isn't, old config works as expected). If you don't mind me asking, what is considered a high-traffic website? I'm getting about 10 pageviews/second (according to google analytics realtime stats) at peak times. |
Yeah that's sorted, anyway the issue is the same for either tcp or unix sockets.
some sections of the site work, like comments certain articles and whatnot, but the frontpage, and the logout page are getting downloaded :) Plus i'm getting logged out randomly on other sections of the website... so i'm kind of lost :) |
Paste the debug log somewhere so that I can help debug this out. |
There are no other debug messages apart from this in vhost log:
and this in nginx debug log
What happened here was I loaded up my old working nginx conf, cleared the boost cache, then loaded your config restarted server and tried to browse. At this point, I could not replicate the index.php download problem, but when it previously just happened out of the blue simply swapping your nginx config for mine, did not solve the problem. I had to clear my browser's cache completely and then reload my old nginx config. Now i'm OK with my config - it works, but it lacks sophistication, microcaching and is full of if's that check for cookies headers and stuff, to decide whether to load boost cache or not. |
This is not a debug log. A debug log is something like this. It traces pointer references and request processing at a low level. What you posted is not enough to proceed. Too vague :( |
I've got "debug" set for all error_logs occurrences. |
Ok. Very strange. Do you have microcaching enabled? Because it's trying to read a cache file but since there are permission problems the cache_loader bombs out and the all thing dies. I've checked and there's no microcache enabled in my config. You cannot have both microcaching and Boost. Choose one. I can help you set up one or the other but not the two. They're concurrent. They cannot be used simultaneously. You can use both, for example, microcaching for authenticated users and boost for anon users. But it's a more involved config. |
Yes I enabled microcache and the permission problem occurs only if running my config. |
In pressflow there are no cookies for anon users. Paste the full debug log. The one you posted above is too redacted. Just remove the IPs and hostnames. But leave everything else in place. Do this for the Boost config. It's the one I know and that I can trace the execution. |
05:46 is when I access /user By the way, I am able to access /user corretly, but I get 405 when I try to login.
|
And yes, I do have correct file permissions. |
It's something on the drupal_boost.conf file that is NOT present on drupal.conf, because I don't get 405 with drupal.conf. |
Try:
and report back please. Thanks, |
Did you mean:
??? |
@fidelix No. I mean remove |
Alright, but you did forget the try_files, right? |
@fidelix (facepalm) Yes :) Fixed. |
Well, now I get a 404 on all clean URL's. |
@fidelix I can't reproduce this issue. Your config has much more stuff as the debug log above shows. So as quick fix I propose you set up a map directive like this:
Reinstating the |
Thanks for the help. I hope this is something specific to my configuration. And good luck with the work you will do with the locations, let me know if you need any help testing. |
@fidelix I've updated the config and the README. Go grab it. Testing appreciated :) Thanks, |
@fidelix fixed and tested in latest version of config. |
For some reason i can't get the frontpage to load from boost cache. Other pages load from boost cache quite happily it's just the frontpage that doesn't.
The config is pretty much default.
The text was updated successfully, but these errors were encountered: