Rewrite
Hi, how can i rewrite url in varnish like this: http://mydomain.com/([0-9]+)/([0-9]+)/([0-9]+)/([0-9]+)\.[0-9]+\.jpg => http://backend/$1/$2/$3/$4.jpg ?? ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strange browser hickups with varnish
Christian Wiese wrote: > The funny thing is that this seems to be a client thing. When I have a > browser hanging, I can fetch the same file with curl or wget just fine. > This could be due to Varnish having different versions in different encodings (gzip/deflate/etc). Take a look at the encoding and see if this is the cause of differences between browsers. As to the larger issue, I don't have much idea, but I think you should post more information, at least your varnishlog output. JT -- End Point Corporation http://www.endpoint.com ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Strange browser hickups with varnish
Hi Folks, we're currently evaluating varnish using it to cache all sorts of static content. It mostly works with minimal configuration, but we are experiencing really strange browser hangs. First, the site loads without problem. Then, after clicking a bit around, the browser (tested: firefox 1.5, 2.0, IE6) hangs while loading a small JavaScript file. This happens regardless if the script comes from the cache or not. Once the browser has been into this state, you can't get it out of it. No reload, no shift-reload, nothing. However, restarting it works. For a while... The funny thing is that this seems to be a client thing. When I have a browser hanging, I can fetch the same file with curl or wget just fine. Any idea what yould cause that? Thanks in advance for any suggestion. Cheers, Chris ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
Raising the number of threads will not significantly improve Varnish concurrency in most cases. I did a test a few months ago using 4 CPUs on RHEL 4.6 with very high request concurrency and a very low request-per-connection ratio (i.e., 1:1, no keepalives) and found that the magic number is about 16 threads/CPU. You should raise overflow_max to a very high value (1% worked just fine for us). Under optimal operating conditions you should not see the "threads not created" value increasing like this. Best regards, --Michael On Tue, Jun 17, 2008 at 3:37 AM, <[EMAIL PROTECTED]> wrote: > I recently made a loadtest against through varnish. > > First I received a very high response time and found out that varnish was > maxing the maximum nr of threads. > > I updated thread_min = 5 and thread_max = 300 and recevied much better > resp. times. > > Then I increased the nr of concurrent users and made another loadtest. The > strange thing here was that I received high resp. times but the threads > stopped at 238. > > The "N worker threads not created" increased rapidly. > > I increased the threads again and changed listen_depth to 2048. > > Here is all the numbers: > 238 0.00 0.22 N worker threads created >1318 4.98 1.21 N worker threads not created > >0 Debug- "Create worker thread failed 12 Cannot allocate memory" >0 Debug- "Create worker thread failed 12 Cannot allocate memory" >0 Debug- "Create worker thread failed 12 Cannot allocate memory" >0 Debug- "Create worker thread failed 12 Cannot allocate memory" >0 Debug- "Create worker thread failed 12 Cannot allocate memory" >0 Debug- "Create worker thread failed 12 Cannot allocate memory" >0 Debug- "Create worker thread failed 12 Cannot allocate memory" >0 Debug- "Create worker thread failed 12 Cannot allocate memory" > > default_ttl120 [seconds] > thread_pools 2 [pools] > thread_pool_max400 [threads] > thread_pool_min10 [threads] > thread_pool_timeout120 [seconds] > thread_pool_purge_delay1000 [milliseconds] > thread_pool_add_threshold 2 [requests] > thread_pool_add_delay 10 [milliseconds] > thread_pool_fail_delay 200 [milliseconds] > overflow_max 100 [%] > rush_exponent 3 [requests per request] > sess_workspace 8192 [bytes] > obj_workspace 8192 [bytes] > sess_timeout 5 [seconds] > pipe_timeout 60 [seconds] > send_timeout 600 [seconds] > auto_restart on [bool] > fetch_chunksize128 [kilobytes] > vcl_trace off [bool] > listen_address 0.0.0.0:80 > listen_depth 2048 [connections] > srcaddr_hash 1049 [buckets] > srcaddr_ttl30 [seconds] > backend_http11 off [bool] > client_http11 off [bool] > cli_timeout5 [seconds] > ping_interval 3 [seconds] > lru_interval 2 [seconds] > cc_command exec cc -fpic -shared -Wl,-x -o %o %s > max_restarts 4 [restarts] > max_esi_includes 5 [restarts] > cache_vbe_connsoff [bool] > connect_timeout400 [ms] > cli_buffer 8192 [bytes] > diag_bitmap0x0 [bitmap] > > Why do I get "Create worker thread failed 12 Cannot allocate memory" when I > had 1900MB free RAM and 65GB free Disk on the server? Any ideas? > > If "N worker threads not created" is increasing, is that a bad sign? > > Thanks > Duja > > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
honoring browser reload request
Using latest varnish from FreeBSD ports (version 1.1.2), is the
following VCL the "correct" solution to support browser shift-reloads to
get fresh content and actually update the cache?
sub vcl_hit {
if (req.http.Cache-Control ~ "no-cache") {
set obj.ttl = 0s;
pass;
}
}
As far as I understood vcl(7), this means:
1. fetch the object from cache (implicit in the fact that we're inside
vcl_hit)
2. set ttl to 0s, expiring it (so next requests will fetch new content)
3. pass to backend (so *this* request see new content)
Does this do what I expect it to do?
Is there a way to avoid hitting the backend twice?
Is there a way to do that in vcl_recv?
(I guess not, since there's no "obj" object available yet, there)
I guess I could use purge_url(...), except I have virtual hosts and it
wants a regexp and req.url could contain some special char (could it?).
--
Lapo Luchini - http://lapo.it/
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Question about threads
I recently made a loadtest against through varnish. First I received a very high response time and found out that varnish was maxing the maximum nr of threads. I updated thread_min = 5 and thread_max = 300 and recevied much better resp. times. Then I increased the nr of concurrent users and made another loadtest. The strange thing here was that I received high resp. times but the threads stopped at 238. The "N worker threads not created" increased rapidly. I increased the threads again and changed listen_depth to 2048. Here is all the numbers: 238 0.00 0.22 N worker threads created 1318 4.98 1.21 N worker threads not created 0 Debug- "Create worker thread failed 12 Cannot allocate memory" 0 Debug- "Create worker thread failed 12 Cannot allocate memory" 0 Debug- "Create worker thread failed 12 Cannot allocate memory" 0 Debug- "Create worker thread failed 12 Cannot allocate memory" 0 Debug- "Create worker thread failed 12 Cannot allocate memory" 0 Debug- "Create worker thread failed 12 Cannot allocate memory" 0 Debug- "Create worker thread failed 12 Cannot allocate memory" 0 Debug- "Create worker thread failed 12 Cannot allocate memory" default_ttl120 [seconds] thread_pools 2 [pools] thread_pool_max400 [threads] thread_pool_min10 [threads] thread_pool_timeout120 [seconds] thread_pool_purge_delay1000 [milliseconds] thread_pool_add_threshold 2 [requests] thread_pool_add_delay 10 [milliseconds] thread_pool_fail_delay 200 [milliseconds] overflow_max 100 [%] rush_exponent 3 [requests per request] sess_workspace 8192 [bytes] obj_workspace 8192 [bytes] sess_timeout 5 [seconds] pipe_timeout 60 [seconds] send_timeout 600 [seconds] auto_restart on [bool] fetch_chunksize128 [kilobytes] vcl_trace off [bool] listen_address 0.0.0.0:80 listen_depth 2048 [connections] srcaddr_hash 1049 [buckets] srcaddr_ttl30 [seconds] backend_http11 off [bool] client_http11 off [bool] cli_timeout5 [seconds] ping_interval 3 [seconds] lru_interval 2 [seconds] cc_command exec cc -fpic -shared -Wl,-x -o %o %s max_restarts 4 [restarts] max_esi_includes 5 [restarts] cache_vbe_connsoff [bool] connect_timeout400 [ms] cli_buffer 8192 [bytes] diag_bitmap0x0 [bitmap] Why do I get "Create worker thread failed 12 Cannot allocate memory" when I had 1900MB free RAM and 65GB free Disk on the server? Any ideas? If "N worker threads not created" is increasing, is that a bad sign? Thanks Duja ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
