1) Если уровень компрессии преодолевает порог в 5-ку, дальнейшее сжатие неоправданно. Дело в том, что нагрузка на процессор увеличивается, а КПД уровня сжатия стремится к нулю.
Пример сжатия text/html в вариациях уровней:
0 55.38 KiB (100.00% of original size)
1 11.22 KiB ( 20.26% of original size)
2 10.89 KiB ( 19.66% of original size)
3 10.60 KiB ( 19.14% of original size)
4 10.17 KiB ( 18.36% of original size)
5 9.79 KiB ( 17.68% of original size)
6 9.62 KiB ( 17.37% of original size)
7 9.50 KiB ( 17.15% of original size)
8 9.45 KiB ( 17.06% of original size)
9 9.44 KiB ( 17.05% of original size)
Пример сжатия application/x-javascript в вариациях уровней:
0 261.46 KiB (100.00% of original size)
1 95.01 KiB ( 36.34% of original size)
2 90.60 KiB ( 34.65% of original size)
3 87.16 KiB ( 33.36% of original size)
4 81.89 KiB ( 31.32% of original size)
5 79.33 KiB ( 30.34% of original size)
6 78.04 KiB ( 29.85% of original size)
7 77.85 KiB ( 29.78% of original size)
8 77.74 KiB ( 29.73% of original size)
9 77.75 KiB ( 29.74% of original size)
По поводу второго пункта.
В любом случае есть основной маршрутизатор, который в случае падения отключит ноды. Поэтому стоит позаботится о более оптимизированной работе самого балансировщика.
По поводу сонфига nginx, не рекомендуется ставить уровень сжатия больше 5.
Не совсем понял сути keepalived, по идее у нас есть основной сервер, на котором стоит балансировщик, но nginx сам — прокси, поэтому upstream web {
server 10.211.77.131 weight=10 max_fails=60 fail_timeout=2s;
server 10.211.77.136 weight=10 max_fails=60 fail_timeout=2s;
}
выступает в качестве раздатки, и он сам видит живой ли хост, если нет передает дальше по приоритету. Ну а если он упадет, главный который, то смысла то и нет во всём остальном.
Мда. Столько денег собрали, а сделать то ничего хорошего не сделали. Представить только $400 000, там явно должно быть что-то эдакое, в чём я сильно сомневаюсь.
Не хочу обидеть, но раньше я хостился за 60р в месяц, на достаточно известном хостере. Много раз один из сайтов попадал под хабраэффект, ни разу сайт не упал и денег не переплачивал. По сравнению с Jelastic получаются просто копейки, зато всё настроено и готово к употреблению. Облака это конечно круто, но пока дорого.
Понравился полёт. Пока смотрел, подумал, что можно коптер использовать при съемках фильмов. Они ведь сейчас вертолёты берут для подобных планов. А тут какая экономия получится. Появится рынок.
Понимаете, сервис в большинстве случаем используется для быстрого постинга скриншота. Соответственно разработчики могли бы усложнить процесс генерации ссылок, например на YouTube используется длина идентификатора равная 11 символов, включая некоторые спец. символы, причем видео нужно явно загружать, а тут нажал на 1 кнопку и скриншот на котором могут быть «интересные данные» уже в сети.
Это отличная демонстрация того, что в наше время интернет ресурсы гораздо дороже «физических». Не случись того, что произошло — магазин так и остался бы неизвестным.
Думаю рано или поздно на таких домофонах будут искать баги. Следовательно можно будет открыть дверь на расстоянии. Именно поэтому домофон должен быть просто домофоном.
Пример сжатия text/html в вариациях уровней:
Пример сжатия application/x-javascript в вариациях уровней:
Взято отсюда: serverfault.com/questions/253074/what-is-the-best-nginx-compression-gzip-level
По поводу второго пункта.
В любом случае есть основной маршрутизатор, который в случае падения отключит ноды. Поэтому стоит позаботится о более оптимизированной работе самого балансировщика.
Не совсем понял сути keepalived, по идее у нас есть основной сервер, на котором стоит балансировщик, но nginx сам — прокси, поэтому
upstream web { server 10.211.77.131 weight=10 max_fails=60 fail_timeout=2s; server 10.211.77.136 weight=10 max_fails=60 fail_timeout=2s; }
выступает в качестве раздатки, и он сам видит живой ли хост, если нет передает дальше по приоритету. Ну а если он упадет, главный который, то смысла то и нет во всём остальном.
И еще
print_r(get_defined_vars())
рассказывает что это за код и зачем он нужен.