4 ms·

I don't get this. As fast as static blogging is, in-memory applications: 1) will actually beat static files in speed 2) you lose none of the flexibility of da

by waps 13y ago

I don't get this. As fast as static blogging is, in-memory applications: 1) will actually beat static files in speed 2) you lose none of the flexibility of databases. In fact, because your effective query impact is going to be much smaller, you gain. Not in what can theoretically be done, but in what can be done practically without impact on response time, you gain a lot. Also expressivity gains (SQL is good, but it doesn't match general programming languages) (e.g. drawing a graph of "this person replies to this person and never replies to this other person" would be feasible). I suppose there's problems too: 3) you lose that your state is always on-disk. In other words : there's a chance that you/your developer will get it wrong, but you won't notice it until your process restarts, which can be months. 4) of course, you have to start monitoring memory usage in these kinds of scenarios.

argonaut 13y ago
... Serving up static HTML/CSS/JS will always be faster than having to render on the server-side. Now the tradeoff is that you can't have certain dynamic elements based on state unless you use a third party service (i.e. comments). But that's obvious.
- waps 13y ago
  No it won't. There's lots of problems with doing that. 1) you need to -at least- check the disk for updates. On linux, you need to update access time. This will take time. In memory has no such obligations. 2) you still need to compress the file in memory. You can cache the result of the compression, but that won't buy you much. Specifically it'll be too large to ... see point 3. 3) Because in practice pages are generated from very little data (the template is -way- shorter than the filled in sent out text), the ability to work with the data in little pieces without allocating large buffers in memory will avoid trampling the cache, which is going to get you an insurmountable advantage. And this is ignoring the elephants in the room: 1) Because it's a static file, you'll have to send more data to the client side in total to achieve the same result (e.g. look at how GWT does it, and even there). 2) Because you still want to show customers "their" page, you'll need several more roundtrips to achieve the same with javascript that you wouldn't need with server pages (Note how one of the GWT pagespeed optimizations is to dynamically generate the page initialization data using the webserver to avoid an initial roundtrip). 3) Pure static files lose you a lot of features. Comments, scores, ... none of that. That may or may not be acceptable.
  - boomlinde 13y ago
    1) You can have the kernel notify you upon a file system change via a watch descriptor. It's not rocket science, and you don't have to do any polling. 2) It might not buy you much (I disagree), but is hardly a disadvantage over any other approach where you'd want to send compressed http responses. 3) Let me get this straight; you're talking about the CPU data cache? It's not going to be the bottleneck in a scenario where you are basically pumping data into a socket. If it was, how would allocating a lot small buffers have an advantage over a single large allocation, if the data was the same in the end? As for elephants... 1) It depends on the expected result. A page built on static files doesn't need to be static in any other sense. 2) I'm not sure why you think that dynamically generated "server pages" are different from static ones in this case. The GWT pagespeed optimizations you are talking about are not relevant to the discussion, since they are not inherent to either static/dynamic backends. 3) As far as I'm concerned, this is the only valid point you have brought to the discussion.
    - waps 13y ago
      1) and the atime updates (I am saying this because apache does make sure it updates them, which runs them -at least- 1ms per file they serve, and yes they accumulate these accesses, but they still cause limits and slowness) ? Caching the file will, incidentally, make watch descriptors not work anymore for other apps. 2) so it's identical. Meaning it's not an advantage of static files. 3) Actually the cpu data cache is going to be the bottleneck when you have 2x10G going into a single server (because you're using 92%+ of your data bandwidth just pumping data into the network cards). Not writing (or reading) to/from memory when you don't absolutely have to is what's going to make the difference in speed. If you get to the point where you can expand templates and compress them without hitting main memory (not that hard in chips with 16M third level cache), it will make a huge difference. And of course this is assuming it actually fits in physical memory. If templates fit, but expanded they don't, templates win hands down (so expanding per-user stats pages into static files, for example, is guaranteed to cost you more than it buys you). Elephants. 1) true, but it's going to cost you in roundtrips 2) yes they are. The optimization states that you optimize by having an "initialize" call, to get all data you need to render the full user's page. Then the dynamic backend calls that function, stores the result at the bottom of the GWT serving page, and boom, you go from n roundtrips to 1. Since a roundtrip is going to cost you at least 80-90 ms in any case except a local LAN, this is one of those optimizations that if you don't have them, you can forget about having your page displayed in less than 400-500ms. Dynamic serving gets a bad rap because people are doing 10 mysql queries to a database server (meaning a different physical machine) with explicitly disabled caching and then complaining that actually takes time ... it's ridiculous. Looking at some PHP code and the speed complaints on fora that accompany it, it feels like putting your grandmother's dead grandmother behind the wheel of a ferrari and complaining it doesn't move fast. Having small programs generate data on cue is always going to be faster than reading the actual data. I don't get why this isn't obvious to everyone. Hell, it's how (and why) compression works.
boomlinde 13y ago
Do you have any benchmarks to support your first assertion?
- waps 13y ago
  Not off hand. Hire me and I'll put together a convincing example with whatever qualifiers you want, and document the findings.
beambot 13y ago
With static files, it's easy to setup serving assets cached in memory. Since all files are static, expiring assets is also trivial. Also, setting up a CDN is super easy too (just a CNAME redirect). Also of note: HN uses the filesystem as a database (ie static files).
- waps 13y ago
  This is the same sort of argument that functional languages keep making. It can work in certain manufactured examples, but in practice it falls on it's face because of the amount of data you need to keep track of, and the features you're throwing out are not optional for the vast majority of problems. Even then, doing this will blow up the data size by necessity and you'll lose time, first to cache trampling, then to virtual memory. And frankly, the moment you hit virtual memory, you won't even get to 10 qps anymore without an SSD, and 100 with an SSD. Static serving is a trivial optimization, and like all such things, it has huge qualifiers, and only works in the case it's intended for. It will only have a speed advantage in the obvious, simple case. As soon as you want to use any sort of dynamic element, extra round-trips will kill whatever advantage you thought you had. If you actually have large amounts of repeating elements (e.g. a table of some sort, article list, pagination, ... what have you), the extra memory usage will kill your advantage.
  - beambot 13y ago
    I have no idea what you're talking about. Functional languages are irrelevant to this conversation. For 99% of personal blogs and a large number of "mom-and-pop" business sites, you'd be lucky to find >1000 individual webpages on their site, each less than 100kB in size. MMAP to your heart's content... 100MB can easily be kept permanently in memory. None of those "dynamic" elements you mentioned are difficult to do statically: You render once using a template language by iterating through and rendering each page in your sitemap. This handles most "dynamic" content you mentioned: tables, tags, tagclouds, pagination, related posts, etc. Using Jekyll or Hyde, you're talking ~100ms per post -- or 1.5 minutes to render 1000 pages. (In fact, Hyde used to use Django under the hood to do the rendering!) I can definitively say, it's a big win for most personal websites -- most dynamic elements can be done at "compile time", others are covered by 3rd party services using client-side JS (eg. Disqus for comments), and if you need any others you should switch to a dynamic site. Tom Preston-Werner (github CEO) agrees with me; that's why he developed Jekyll for github [1]. Github pages are hardly a "manufactured" example, and they do work well in practice. [1] http://tom.preston-werner.com/2008/11/17/blogging-like-a-hacker.html http://tom.preston-werner.com/2008/11/17/blogging-like-a-hac...

by waps 13y ago

argonaut 13y ago

... Serving up static HTML/CSS/JS will always be faster than having to render on the server-side. Now the tradeoff is that you can't have certain dynamic elements based on state unless you use a third party service (i.e. comments). But that's obvious.

waps 13y ago
No it won't. There's lots of problems with doing that. 1) you need to -at least- check the disk for updates. On linux, you need to update access time. This will take time. In memory has no such obligations. 2) you still need to compress the file in memory. You can cache the result of the compression, but that won't buy you much. Specifically it'll be too large to ... see point 3. 3) Because in practice pages are generated from very little data (the template is -way- shorter than the filled in sent out text), the ability to work with the data in little pieces without allocating large buffers in memory will avoid trampling the cache, which is going to get you an insurmountable advantage. And this is ignoring the elephants in the room: 1) Because it's a static file, you'll have to send more data to the client side in total to achieve the same result (e.g. look at how GWT does it, and even there). 2) Because you still want to show customers "their" page, you'll need several more roundtrips to achieve the same with javascript that you wouldn't need with server pages (Note how one of the GWT pagespeed optimizations is to dynamically generate the page initialization data using the webserver to avoid an initial roundtrip). 3) Pure static files lose you a lot of features. Comments, scores, ... none of that. That may or may not be acceptable.
- boomlinde 13y ago
  1) You can have the kernel notify you upon a file system change via a watch descriptor. It's not rocket science, and you don't have to do any polling. 2) It might not buy you much (I disagree), but is hardly a disadvantage over any other approach where you'd want to send compressed http responses. 3) Let me get this straight; you're talking about the CPU data cache? It's not going to be the bottleneck in a scenario where you are basically pumping data into a socket. If it was, how would allocating a lot small buffers have an advantage over a single large allocation, if the data was the same in the end? As for elephants... 1) It depends on the expected result. A page built on static files doesn't need to be static in any other sense. 2) I'm not sure why you think that dynamically generated "server pages" are different from static ones in this case. The GWT pagespeed optimizations you are talking about are not relevant to the discussion, since they are not inherent to either static/dynamic backends. 3) As far as I'm concerned, this is the only valid point you have brought to the discussion.
  - waps 13y ago
    1) and the atime updates (I am saying this because apache does make sure it updates them, which runs them -at least- 1ms per file they serve, and yes they accumulate these accesses, but they still cause limits and slowness) ? Caching the file will, incidentally, make watch descriptors not work anymore for other apps. 2) so it's identical. Meaning it's not an advantage of static files. 3) Actually the cpu data cache is going to be the bottleneck when you have 2x10G going into a single server (because you're using 92%+ of your data bandwidth just pumping data into the network cards). Not writing (or reading) to/from memory when you don't absolutely have to is what's going to make the difference in speed. If you get to the point where you can expand templates and compress them without hitting main memory (not that hard in chips with 16M third level cache), it will make a huge difference. And of course this is assuming it actually fits in physical memory. If templates fit, but expanded they don't, templates win hands down (so expanding per-user stats pages into static files, for example, is guaranteed to cost you more than it buys you). Elephants. 1) true, but it's going to cost you in roundtrips 2) yes they are. The optimization states that you optimize by having an "initialize" call, to get all data you need to render the full user's page. Then the dynamic backend calls that function, stores the result at the bottom of the GWT serving page, and boom, you go from n roundtrips to 1. Since a roundtrip is going to cost you at least 80-90 ms in any case except a local LAN, this is one of those optimizations that if you don't have them, you can forget about having your page displayed in less than 400-500ms. Dynamic serving gets a bad rap because people are doing 10 mysql queries to a database server (meaning a different physical machine) with explicitly disabled caching and then complaining that actually takes time ... it's ridiculous. Looking at some PHP code and the speed complaints on fora that accompany it, it feels like putting your grandmother's dead grandmother behind the wheel of a ferrari and complaining it doesn't move fast. Having small programs generate data on cue is always going to be faster than reading the actual data. I don't get why this isn't obvious to everyone. Hell, it's how (and why) compression works.

boomlinde 13y ago

Do you have any benchmarks to support your first assertion?

waps 13y ago
Not off hand. Hire me and I'll put together a convincing example with whatever qualifiers you want, and document the findings.

beambot 13y ago

With static files, it's easy to setup serving assets cached in memory. Since all files are static, expiring assets is also trivial. Also, setting up a CDN is super easy too (just a CNAME redirect). Also of note: HN uses the filesystem as a database (ie static files).

waps 13y ago
This is the same sort of argument that functional languages keep making. It can work in certain manufactured examples, but in practice it falls on it's face because of the amount of data you need to keep track of, and the features you're throwing out are not optional for the vast majority of problems. Even then, doing this will blow up the data size by necessity and you'll lose time, first to cache trampling, then to virtual memory. And frankly, the moment you hit virtual memory, you won't even get to 10 qps anymore without an SSD, and 100 with an SSD. Static serving is a trivial optimization, and like all such things, it has huge qualifiers, and only works in the case it's intended for. It will only have a speed advantage in the obvious, simple case. As soon as you want to use any sort of dynamic element, extra round-trips will kill whatever advantage you thought you had. If you actually have large amounts of repeating elements (e.g. a table of some sort, article list, pagination, ... what have you), the extra memory usage will kill your advantage.
- beambot 13y ago
  I have no idea what you're talking about. Functional languages are irrelevant to this conversation. For 99% of personal blogs and a large number of "mom-and-pop" business sites, you'd be lucky to find >1000 individual webpages on their site, each less than 100kB in size. MMAP to your heart's content... 100MB can easily be kept permanently in memory. None of those "dynamic" elements you mentioned are difficult to do statically: You render once using a template language by iterating through and rendering each page in your sitemap. This handles most "dynamic" content you mentioned: tables, tags, tagclouds, pagination, related posts, etc. Using Jekyll or Hyde, you're talking ~100ms per post -- or 1.5 minutes to render 1000 pages. (In fact, Hyde used to use Django under the hood to do the rendering!) I can definitively say, it's a big win for most personal websites -- most dynamic elements can be done at "compile time", others are covered by 3rd party services using client-side JS (eg. Disqus for comments), and if you need any others you should switch to a dynamic site. Tom Preston-Werner (github CEO) agrees with me; that's why he developed Jekyll for github [1]. Github pages are hardly a "manufactured" example, and they do work well in practice. [1] http://tom.preston-werner.com/2008/11/17/blogging-like-a-hacker.html http://tom.preston-werner.com/2008/11/17/blogging-like-a-hac...