Trade me use case
•Télécharger en tant que PPTX, PDF•
1 j'aime•141 vues
Trade Me presents their Varnish use case in Auckland, 2016
Recommandé
Contenu connexe
Tendances
Tendances (20)
Plus de Varnish Software
Plus de Varnish Software (20)
Trade me use case
- 1. 1
- 2. • • • • •
- 3. • • • • • •
- 5. 6
- 6. • • • • • •
- 7. • • •
- 16. 17
- 17. • • •
- 18. • • • • • • •
- 20.
- 22. • • • •
- 26. /photoserver/thumb/12345.jpg /photoserver/thumb/345/12345.jpg /photoserver/thumb/45/12345.jpg /photoserver/thumb/345/12345.jpg /photoserver/full/12345.jpg /photoserver/full/345/12345.jpg /photoserver/45/12345_full.jpg /photoserver/full/345/12345.jpg /photoserver/lv/0/1234500.jpg /photoserver/lv/500/1234500.jpg
- 27. • • • •
Notes de l'éditeur
- We’ve been a user of Varnish since v2.0.1 (sometime before 2011?) Even though we only use Varnish in a couple of niche places, it’s extremely flexible and we get good use out of it
- We’ve been around since 1999. We try to keep our site fast, we host in 2 NZ locations and are generally running on pretty reliable infrastructure. We aren’t tied to any particular vendor or product, we use the best tool for the job. We moved away from proprietary caching appliances to Varnish, and haven’t looked back.
- Our site relies heavily on images. Our members upload 20+ images every second, and at peak times we serve 10,000 image requests per second. Because they are static, we can normalise requests and cache them heavily.
- How we use Varnish to integrate an off the shelf CMS with our main website, trademe.co.nz
- Examples are: help pages, policies (T&Cs), advertising rates etc, some areas wanted a blog. Which CMS we use isn’t important, we went with an open source .NET CMS, but it could be anything.
- Kinda hard to describe the header/footer thing, might be easier to show what a dynamic header looks like
- The header has a number of dynamic elements, some of which may not be obvious We did try to recreate it with static content, but it wasn’t satisfactory
- Load balancer sends request to webserver. Page is header & content & footer
- When the load balancer detects the URL is for one of the CMS areas, it directs traffic to the Varnish server. Varnish config is light, basically minimal caching, with ESI enabled. Varnish backend is the CMS server CMS page content includes ESI tags for header and footer, which are on the main site
- When the load balancer detects the URL is for one of the CMS areas, it directs traffic to the Varnish server. Varnish config is light, basically minimal caching, ESI enabled. Varnish backend is the CMS server CMS page content includes esi tags for header and footer, which are on the main site
- Here it is in action. Can you see the joins?
- We have around 11m unique images, stored in 9 sizes in 2 redundant locations = ~200m files Files were in 100 dirs. on disk (around 100,000 per dir) – storage vendor’s recommendation is to keep it under 20k objects per directory(!) We had performance problems, even with our high cache hitrates.
- We have around 11m unique images, stored in 9 sizes in 2 redundant locations = ~200m files Files were in 100 dirs. on disk (around 100,000 per dir) – storage vendor’s recommendation is to keep it under 20k objects per directory(!) We had performance problems, even with our high cache hitrates.
- Image IDs are incremental integers, allocated on upload.
- Activation was based around a trigger image ID. This was forecasted and agreed upon (and tested before we got to Prod). In the event, we had to change it at the last minute anyway The main stuff we were concerned about was missing some code – eg an API edge case for a mobile app.
- This bit contains Regex. Even when you are staring at them, sometimes it takes a while to process what you’re looking at. I’ll try to explain… if I do a bad job, you can hopefully get the idea.
- I use Regex Buddy. Life is too short to accurately understand regex yourself.
- Again, the main idea is to catch all requests for image IDs > threshold value and ensure they are sent to the backend with the 3 digit directory in them. Also we tidy up the FULL size requests and log everything to Varnishlog.
- We call the sub first
- Private cloud – we should have enough capacity to do this. We’re doing this for all apps and services. Object (S3-like) storage – solves metadata issues, redundancy, resilience, management and others. API – we currently use something similar, which we have written ourselves. We’re at the point of looking at alternatives. Currently we use PRTG and Cacti for stats, manual management of our small number of servers. We did use VAC for a period and are thinking it’s something we should do again.