3 ms·

Sites like those (e.g. Wikipedia) tend to be driven by a CRM on the backend, with content maintained by a team of people, and so it's not super reasonable for t

by dymk 5y ago

Sites like those (e.g. Wikipedia) tend to be driven by a CRM on the backend, with content maintained by a team of people, and so it's not super reasonable for the site to be regenerated and the static HTML file to be reuploaded to the server on every change. Cache the body page, put the timestamped footer on it, and serve it up. Easy peasy, been doing it since 1995.

jiggawatts 5y ago
It's trivial to generate pages statically, irrespective of the update volume. Instead of updating database rows, just save S3 blobs of HTML. The reason this is not done is an accident of history that is no longer required but has become the norm. "Back in the day", browser compatibility issues meant that user agent strings had to be inspected and different HTML content served based on the browser. Mobile browsers especially required vastly different content compared to desktop browser. I don't mean two different kinds of content, but dozens. Similarly, text encoding variations was a huge pain. With HTML5 and modern browser standards this is a thing of the past. The same static HTML can be served to everyone. Any content that needs to vary based on client-side metrics is best implemented by JavaScript or CSS, which can be responsive to display changes like phone rotation. There is literally no benefit to dynamic rendering for many sites. It nearly guarantees scalability issues at the hardest part to scale -- the database. It means that every "moving part" must always be moving, or you get a guaranteed outage. It means that any caching tier like a CDN gets you right back to the pros and cons of static rendering: either you don't cache all of the site OR you have to live with the limitations of static/stale content. CMS products like SiteCore or Wordpress are especially bad, doing everything fully dynamically. I've seen these products struggle to serve 10 requests per second on clusters of VMs that should be able to serve 10 million. The most crazy thing I saw was a plugin that did image compression optimisation dynamically with a fixed-size cache on a per-server basis. If you had more GB of pictures than the cache size, you'd get cache thrashing and the CPU load on all nodes would spike. Scaling up the farm wouldn't help either because the new server would have an empty cache and hence would overload its CPUs for hours. Simply pre-optimising everything and dumping the result in something like and S3 bucket would be orders of magnitude more efficient and scalable. We're talking up to 100 Gbps egress to the Internet, no sweat.
- ryan_lane 5y ago
  Have you worked on one of these products before? I worked for Wikimedia Foundation, and it's not trivial to generate the pages statically. The content itself is wikitext, not html. It'd derived from content, templates, and meta-templates. Quite a bit of the data comes from other sources, like wikidata, or commons. You need to display things differently based on logged-in vs logged-out status. Through lots of layers of caching, the fact that the backend is dynamic doesn't really make things that taxing. Serving mostly static content is a pretty well-known problem-set at this point. Wordpress is perfectly fine, btw. If you use memcache/redis, and some form of a reverse-proxy caching layer (like cloudflare/fastly), you can very easily be #1 on hackernews for the entire day, from a single t2 instance in AWS (I say this from experience, multiple times). Yes, if you can static-generate your site, it's probably better to do so, but it's a more difficult approach, and is also limiting in terms of managing the content.
  - jiggawatts 5y ago
    Yes, I have worked with these products at a moderately large scale. I have also developed a wiki-like CMS from scratch myself, with templating, macros, and everything. The issues I saw would occur at any scale above "tiny". Essentially as soon as scale-out is needed for a dynamic site, caching also becomes mandatory. Caching is not well understood at all. People think they understand it, but probably don't actually know most of the pitfalls, especially in the face of failure in the general case. With Wikimedia, many of the issues are not super important. E.g.: transaction integrity is not relevant. The occasional 404 or eventual (in)consistency problem is also not a big deal. Similarly, the user-based rendering is also fairly easy to handle. The vast majority of the content (the rendered wiki text) is identical-ish between users. The headers, footers, CSS, etc... do change. This can be handled on the client-side in a variety of ways, typically via JavaScript. Even with mostly static content, headings can be altered on the way out "at the edge" by a CDN or CDN-like system. This is my point: If you're going to cache things in something like a CDN, then you're 90% of the way there to static content anyway! Take the leap and go the whole way to get the benefits. Some things need to be done 100%, otherwise it's like being almost pregnant. Some random examples of static vs dynamic problems/comparisons: - You mentioned templating: In the static world, you can regenerate all static pages based on the new template asynchronously at whatever slow "batch process" rate you desire. In a dynamic system, a change to a template would typically invalidate the entire cache and blow your CPU budget instantly, dragging down the synchronous rendering path into molasses. This can be managed, but it's complex and difficult. Similarly, code changes can similarly result in either mixed/corrupt cache content or instant CPU spikes. At least with static content you can manage the rollout by content instead of by server. A trick you can pull with static content is pre-generate the updated pages side-by-side and swap instantly. This is impossible with dynamic content generation. You either get mixed content as the caches slowly expire, or instant load spike. - Variations such as mobile/non-mobile pages: These add to cache pressure, and can result in sudden performance cliffs where going from 90% cache utilisation to 110% can cause dramatic spikes in load. If you use static content, your "utilisation" is known in advance and changes slowly. Everything is served at the same speed, always. In fact, with systems like S3, your speed goes up as your data volume increases because of the way the sharding works. - Memcache and the like are hilarious to me. These days the "standard" is to have layers upon layers of caching to paper over the fundamental bottleneck of the database tier. SiteCore has so many layers of caching that I lost count. Is it ten? Eleven maybe? Whatever. The point is that keeping that straight in your head as a web developer is so difficult that SiteCore keeps all caching off by default, murdering performance for most sites most of the time. It's just too "difficult" to have it on by default because devs would lose their minds. Just the access control issues of providing devs with access to shared Redis clusters or CDNs for purge operations is a task all by itself. In large enterprise, this is almost never done and then it becomes a tradeoff between cache TTLs and freshness/consistency. I've lost count of the number of times I've heard some dev tell users to "clear their browser cache" as the "fix". - Cache purging: you can hide a fundamental performance problem under a layer of caching for years, have it grow to monumental proportions, and then blow up your production site for days while everything slowly recovers from 1,000% load. This has caused several large-scale outages that have hit headlines. Look at it this way: Wikipedia is something like 99% read-only access and 1% write access. With a static hosting model the VMs would only need to be scaled to handle the write-throughput, not the read-throughput. The content could be put on cloud storage like S3 and that's it. The whole site could be hosted of a handful of small VMs just for HA/DR!
TheOtherHobbes 5y ago
You don't need to regenerate the entire site. You only need to regenerate the pages that have changed and maybe some indexes. Considering that SSR has to generate the pages for each view - unless they're cached, which sort of reduces to option 1 anyway - site (i.e. page) regeneration is hugely more efficient.

by dymk 5y ago

jiggawatts 5y ago

It's trivial to generate pages statically, irrespective of the update volume. Instead of updating database rows, just save S3 blobs of HTML. The reason this is not done is an accident of history that is no longer required but has become the norm. "Back in the day", browser compatibility issues meant that user agent strings had to be inspected and different HTML content served based on the browser. Mobile browsers especially required vastly different content compared to desktop browser. I don't mean two different kinds of content, but dozens. Similarly, text encoding variations was a huge pain. With HTML5 and modern browser standards this is a thing of the past. The same static HTML can be served to everyone. Any content that needs to vary based on client-side metrics is best implemented by JavaScript or CSS, which can be responsive to display changes like phone rotation. There is literally no benefit to dynamic rendering for many sites. It nearly guarantees scalability issues at the hardest part to scale -- the database. It means that every "moving part" must always be moving, or you get a guaranteed outage. It means that any caching tier like a CDN gets you right back to the pros and cons of static rendering: either you don't cache all of the site OR you have to live with the limitations of static/stale content. CMS products like SiteCore or Wordpress are especially bad, doing everything fully dynamically. I've seen these products struggle to serve 10 requests per second on clusters of VMs that should be able to serve 10 million. The most crazy thing I saw was a plugin that did image compression optimisation dynamically with a fixed-size cache on a per-server basis. If you had more GB of pictures than the cache size, you'd get cache thrashing and the CPU load on all nodes would spike. Scaling up the farm wouldn't help either because the new server would have an empty cache and hence would overload its CPUs for hours. Simply pre-optimising everything and dumping the result in something like and S3 bucket would be orders of magnitude more efficient and scalable. We're talking up to 100 Gbps egress to the Internet, no sweat.

ryan_lane 5y ago
Have you worked on one of these products before? I worked for Wikimedia Foundation, and it's not trivial to generate the pages statically. The content itself is wikitext, not html. It'd derived from content, templates, and meta-templates. Quite a bit of the data comes from other sources, like wikidata, or commons. You need to display things differently based on logged-in vs logged-out status. Through lots of layers of caching, the fact that the backend is dynamic doesn't really make things that taxing. Serving mostly static content is a pretty well-known problem-set at this point. Wordpress is perfectly fine, btw. If you use memcache/redis, and some form of a reverse-proxy caching layer (like cloudflare/fastly), you can very easily be #1 on hackernews for the entire day, from a single t2 instance in AWS (I say this from experience, multiple times). Yes, if you can static-generate your site, it's probably better to do so, but it's a more difficult approach, and is also limiting in terms of managing the content.
- jiggawatts 5y ago
  Yes, I have worked with these products at a moderately large scale. I have also developed a wiki-like CMS from scratch myself, with templating, macros, and everything. The issues I saw would occur at any scale above "tiny". Essentially as soon as scale-out is needed for a dynamic site, caching also becomes mandatory. Caching is not well understood at all. People think they understand it, but probably don't actually know most of the pitfalls, especially in the face of failure in the general case. With Wikimedia, many of the issues are not super important. E.g.: transaction integrity is not relevant. The occasional 404 or eventual (in)consistency problem is also not a big deal. Similarly, the user-based rendering is also fairly easy to handle. The vast majority of the content (the rendered wiki text) is identical-ish between users. The headers, footers, CSS, etc... do change. This can be handled on the client-side in a variety of ways, typically via JavaScript. Even with mostly static content, headings can be altered on the way out "at the edge" by a CDN or CDN-like system. This is my point: If you're going to cache things in something like a CDN, then you're 90% of the way there to static content anyway! Take the leap and go the whole way to get the benefits. Some things need to be done 100%, otherwise it's like being almost pregnant. Some random examples of static vs dynamic problems/comparisons: - You mentioned templating: In the static world, you can regenerate all static pages based on the new template asynchronously at whatever slow "batch process" rate you desire. In a dynamic system, a change to a template would typically invalidate the entire cache and blow your CPU budget instantly, dragging down the synchronous rendering path into molasses. This can be managed, but it's complex and difficult. Similarly, code changes can similarly result in either mixed/corrupt cache content or instant CPU spikes. At least with static content you can manage the rollout by content instead of by server. A trick you can pull with static content is pre-generate the updated pages side-by-side and swap instantly. This is impossible with dynamic content generation. You either get mixed content as the caches slowly expire, or instant load spike. - Variations such as mobile/non-mobile pages: These add to cache pressure, and can result in sudden performance cliffs where going from 90% cache utilisation to 110% can cause dramatic spikes in load. If you use static content, your "utilisation" is known in advance and changes slowly. Everything is served at the same speed, always. In fact, with systems like S3, your speed goes up as your data volume increases because of the way the sharding works. - Memcache and the like are hilarious to me. These days the "standard" is to have layers upon layers of caching to paper over the fundamental bottleneck of the database tier. SiteCore has so many layers of caching that I lost count. Is it ten? Eleven maybe? Whatever. The point is that keeping that straight in your head as a web developer is so difficult that SiteCore keeps all caching off by default, murdering performance for most sites most of the time. It's just too "difficult" to have it on by default because devs would lose their minds. Just the access control issues of providing devs with access to shared Redis clusters or CDNs for purge operations is a task all by itself. In large enterprise, this is almost never done and then it becomes a tradeoff between cache TTLs and freshness/consistency. I've lost count of the number of times I've heard some dev tell users to "clear their browser cache" as the "fix". - Cache purging: you can hide a fundamental performance problem under a layer of caching for years, have it grow to monumental proportions, and then blow up your production site for days while everything slowly recovers from 1,000% load. This has caused several large-scale outages that have hit headlines. Look at it this way: Wikipedia is something like 99% read-only access and 1% write access. With a static hosting model the VMs would only need to be scaled to handle the write-throughput, not the read-throughput. The content could be put on cloud storage like S3 and that's it. The whole site could be hosted of a handful of small VMs just for HA/DR!

TheOtherHobbes 5y ago

You don't need to regenerate the entire site. You only need to regenerate the pages that have changed and maybe some indexes. Considering that SSR has to generate the pages for each view - unless they're cached, which sort of reduces to option 1 anyway - site (i.e. page) regeneration is hugely more efficient.