Hi

I've posted an issue on the boost queue about the troubles I've been having with boost's asynchronous caching while moving a D6 site to a new Barracuda server (squeeze, php-fpm 5.3).
#1544040: Problems with Asynchronous operation on Barracuda / Nginx platform

I'm not sure if its related to the set up in Barracuda, but I wanted to post here to see if you have experience using async mode in boost, and if so whether it normally works or if there is a known issue.

I have switched back to the normal mode for now, but it took me the best part my afternoon and evening to locate the problem (anonymous pages just wouldn't complete loading) so it would be nice to find a way to fix it if possible.

So, if you can shed any light on this issue from your perspective i'd be very grateful

Thanks

Ben

CommentFileSizeAuthor
#4 boost_async_debug_nginx.txt50.44 KBsmoothify

Comments

omega8cc’s picture

omega8cc commented

I have never tried this so not sure if this is something to fix on our side or rather in the Boost itself. Maybe it fails because we use secure limits for the number of requests allowed from the same IP, but it is pure guessing. If you can try to debug it further by checking also Nginx logs, it would be great.

smoothify’s picture

smoothify commented

Thanks for the reply. I did try commenting out the connection limit in the vhost, but that didn't change any behaviour.

There is nothing in the nginx error log, but in the access log I get a 304 response followed by a malformed 400 response.

"IP" domain.com [23/Apr/2012:19:36:05 +0200] "GET /whats-new HTTP/1.1" 304 0 712 278 "" "Mozilla/5.0..."
"IP" _ [23/Apr/2012:19:36:19 +0200] "-" 400 0 0 0 "-" "-" 0.000 "-"

Where as a regular response should be much large in size:

"IP" domain.com [23/Apr/2012:19:36:01 +0200] "GET /whats-new HTTP/1.1" 200 7416 711 7799 "" "Mozilla/5.0..."
omega8cc’s picture

omega8cc commented

Changing error reporting in the main nginx config from default crit to info or debug will show the real reason behind error 400 (in the error log), which happens when Nginx receives wrongly formatted request - like URI without leading forward slash or without Host header etc. This will help to debug it further, but it already looks like a bug in the Boost.

smoothify’s picture

smoothify commented
StatusFileSize
new boost_async_debug_nginx.txt50.44 KB

This is in the error log when using info error reporting:

2012/04/24 12:43:16 [info] 17806#0: *19007 client prematurely closed connection while sending request to upstream, client: 1.1.1.1, server: domain.com, request: "GET /mali HTTP/1.1", upstream: "fastcgi://127.0.0.1:9090", host: "domain.com", referrer: "http://domain.com/journeys"

I've attached the relevant parts when using debug error reporting.

omega8cc’s picture

omega8cc commented

The error client prematurely closed connection while sending request to upstream is "normal" and happens also when you stop page loading in the browser before server will complete page generation - for example on some busy URI like /admin/build/modules etc. But maybe it is related, not sure.

There are also errors like recv() not ready (11: Resource temporarily unavailable), so it would be better to disable Speed Booster while testing Boost, as it may cause confusion in debugging. To disable Speed Booster on the fly you could use the ubercart/README.txt control file, as ?nocache=1 would disable also Boost.

There must be some other reason for those error 400 results.

omega8cc’s picture

omega8cc commented
Status: Active » Closed (cannot reproduce)

Closing because there was no feedback for a long time.