server experts: Varnish & Cookies & Traffic Trade Script ???

[miguel7]

Hi,

after installation of Varnish for caching my traffic my trade script (TE) is counting only about 30% of all incoming traffic. We added many exeptions to varnish settings to exclude traffic trade scripts, tt folder and then all php files but nothing helps.

Do you have any experience with this?

Help almost retarded Miguel!

[rowan]

I can't help you with varnish specifics but perhaps you could try a reversed set of rules... rather than a bunch of exceptions for objects that shouldn't be cached, passthrough everything EXCEPT for *.jpg, *.flv etc.

[sandman!]

better to use nginx for static content and str8 apache for html and scripts

[raymor]

Originally Posted by rowan

I can't help you with varnish specifics but perhaps you could try a reversed set of rules... rather than a bunch of exceptions for objects that shouldn't be cached, passthrough everything EXCEPT for *.jpg, *.flv etc.

Indeed caching can get pretty complex and problems often are not obvious, so if it's not quite working right for you better to only cache things that you're sure are safe to cache.

Having said that, if the caching server is on the same machine as the web server, caching static files can easily hurt performance. The real benefit is in (carefully) caching the output of scripts. If it's on the same machine, reading an extra "cached" copy of the file is no faster than reading the main copy. The only difference is what happens when a file is requested that's NOT in the cache, a cache miss. There's a bunch of extra overhead there, with these cache misses taking as much as for times as long to serve up than they would coming straight from Apache. So you'd be significantly better off just using Apache alone in those cases.

So in caching only static files hurts performance and a small error caching dynamic content causes complex problems. Therefore the cache will only cause you problems if you can't be confident that your dynamic scripts are consistently cached (or not) correctly.

Aside from having the caching work correctly, so as to avoid breaking things in some situations (like when the user has an iphone), if the cache isn't tuned correctly it can slow things down. Did you know that a very large cache is slower than no cache at all? So to is a very small cache, due to excessive misses. The cache has to be the right size in prefer to do you any good at all. What does all this mean? It means that if you have to come to GFY for help setting up your caching proxy, you're probably better off without a caching proxy.

[HomerSimpson]

varnish won't work with traffic trade scripts since it will "remember" a page and will keep it in memory and will use it like that for some time...

Best you can do is use XCache or eAccelerator to speedup php...

[miguel7]

Originally Posted by raymor

Indeed caching can get pretty complex and problems often are not obvious, so if it's not quite working right for you better to only cache things that you're sure are safe to cache.

Having said that, if the caching server is on the same machine as the web server, caching static files can easily hurt performance. The real benefit is in (carefully) caching the output of scripts. If it's on the same machine, reading an extra "cached" copy of the file is no faster than reading the main copy. The only difference is what happens when a file is requested that's NOT in the cache, a cache miss. There's a bunch of extra overhead there, with these cache misses taking as much as for times as long to serve up than they would coming straight from Apache. So you'd be significantly better off just using Apache alone in those cases.

So in caching only static files hurts performance and a small error caching dynamic content causes complex problems. Therefore the cache will only cause you problems if you can't be confident that your dynamic scripts are consistently cached (or not) correctly.

Aside from having the caching work correctly, so as to avoid breaking things in some situations (like when the user has an iphone), if the cache isn't tuned correctly it can slow things down. Did you know that a very large cache is slower than no cache at all? So to is a very small cache, due to excessive misses. The cache has to be the right size in prefer to do you any good at all. What does all this mean? It means that if you have to come to GFY for help setting up your caching proxy, you're probably better off without a caching proxy.

Thank you for your comprehensive answer.
I think I have to say from the beginning. About 2 months ago my server started to have problems due to higher traffic. When reaching the top traffic hours, Server very often fell. (last moth stats: uptime 99.05%, downtime 6h 48m 29s, number of downtimes 117).

After reading this Stop throwing hardware at your problems. Tune your server! I sent request support I reached my patience. I requested a final solution I required Nginx on my serer. They recommend me Varnish....

It seems that it helped, no any serverdown yet, but it's only 3 days.
But according to what you wrote caching without caching PHP does not make any sense ??

[miguel7]

Originally Posted by HomerSimpson

varnish won't work with traffic trade scripts since it will "remember" a page and will keep it in memory and will use it like that for some time...

Best you can do is use XCache or eAccelerator to speedup php...

I have old TGP and thousands of picture galleries. So what is the best to speed up for pictures ??

[miguel7]

No more tips?

[raymor]

Originally Posted by miguel7

Thank you for your comprehensive answer.
I think I have to say from the beginning. About 2 months ago my server started to have problems due to higher traffic. When reaching the top traffic hours, Server very often fell. (last moth stats: uptime 99.05%, downtime 6h 48m 29s, number of downtimes 117).

After reading this Stop throwing hardware at your problems. Tune your server! I sent request support I reached my patience. I requested a final solution I required Nginx on my serer. They recommend me Varnish....

It seems that it helped, no any serverdown yet, but it's only 3 days.
But according to what you wrote caching without caching PHP does not make any sense ??

What happened with the server down time? I'm guessing maybe it hit MaxClients? If that were it, adding another server process (Varnish or otherwise) could
cover for that problem until it gets busier but adjusting Apache to match the load would work a lot better. Anyway I'd start by looking at what the problem was in order to prescribe a correct solution. I'd certainly want to DIAGNOSE the problem, not hide it behind a proxy.

One thing that's common to any high traffic traffic site is that you should turn on noatime, though. Noatime makes a huge difference, as much as citing disk io in half for small files and even more if you're using RAID 5. That's actually what's mainly responsible for the apparent speed of nginx - it skips atime updates even if the server admin has the system set to do them. (Is that a bug or a feature?)

The idea of cache generally, whether it's a CPU cache, HD cache, or web cache is that the cache resides on fast (but small) storage. For example the 32 MB of RAM cache in a hard drive is also several million times FASTER than the drive spindles. If the data can be retrieved from cache that's great because the cache is on storage that's so much faster.

In your case, the "cache" is on the hard drive, I assume, the exact same storage as the main copy. Your Varnish cache will run at the speed of the drive, if the file is already cached. Without Varnish, the file would be served from the same drive at the same speed! Does that make sense? The CPU, the RAM, all of that is a million times faster than the drive. So it's the drive that determined the speed of static files, which are just read from the drive. So the cache can be faster only if a) it uses a faster drive or b) the main server is configured to do disk updates that the proxy doesn't do (noatime).

Since reading from either spot on the drive is the same, the only difference is the extra overhead of looking in the cache when it's not there, then having to request it from the main server, update the cache, then finally write it through.

So anyway all that to say:
Diagnose the problem, don't just hide it.
Use noatime on all busy servers that don't have a specific need for atime.