|
|
|
|
|
by mozumder
3063 days ago
|
|
Definitely #3. That's when I went from an amateurish 1s page generation times to a respectable and professional 50ms or so, just by cutting down on the number of SQL queries from hundreds to a few. This also massively cut down CPU usage. Using materialized views cut down the 50ms page generation to about 10-15ms, by flattening queries into a flat table so there aren't joins. Using prepared statements cut down 10-15ms page generation to 5ms. Each Postgres query has an entire setup process that involved about 7ms of overhead, and prepared statements cut all that overhead. You won't notice this overhead when your queries are 50-100ms each, but when your queries are only 10ms, it matters. Getting rid of Gzip in the page generation by serving cached gzip cut down page generation times down to sub-millisecond range for cache hit fragments. |
|