5 ms·
Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck. Luckily rendering scales just by adding more servers. Rewr
by zepolen 17y ago
Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck.
Luckily rendering scales just by adding more servers.
Rewriting templating code in C though rarely adds more speed, most dynamic languages tune their string handling as much as possible.
Also, utilizing http caching mechanisms are a (quite underused) great solution for lowering load.
- bad_user 17y ago> Once you lower the the db io issues ... It is highly unlikely that happens. Once you lower your DB issues, if the application is responsive enough you start working on other features. By the time you're done the application got new users and the DB is a problem again ... it's a cycle :) Fortunately HTTP servers do scale by caching and load-balancing. The author of the post probably never worked in real-world conditions. You first have to have users and real needs for scaling, and that doesn't happen unless you deliver a useful application first, and you also have to deliver it pretty fast, otherwise you might lose to a competitor with the same idea.
- swombat 17y agoReread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck. Not really. Sending and receiving data to/from the browser becomes the bottleneck. If it takes 50ms to receive the query from the browser, 0.1ms to retrieve the data from the cache, 10ms to render it, and another 50ms to send it back to the browser - the bottleneck is now network communications with the browser. There are, unfortunately, limits on how much that can be improved.
- zepolen 17y agoApp servers don't handle the spoon feeding of clients, front end webservers do, at least in any sane architecture.