Ну мой опыт (9.2, но все же) подсказывает, что автовакуум почти не помогает, а без фуллвакуума постепенно накапливается сильная деградация производительности.
Насколько я понимаю, S.M.A.R.T. поможет предсказать падение HDD, не SSD.
Для SSD он лишь оценивает число циклов перезаписи и в принципе не может помочь при сломе контроллера, что является основной проблемой отказа SSD.
Вы написали, что постгрес оставил вам только проблему автовакуума, но не написали, как вы ее решаете.
Фулл вакуум каждый день во время профилактики? А если не успеет?
Фишка со словарем напоминает сжатие LZ, но в рамках сессии, а не запроса. Да, это интересная вещь. Но, как я понял документацию, этот словарь статический:
The stream is initialized with the following dictionary (without line breaks and IS null-terminated):
optionsgetheadpostputdeletetraceacceptaccept-charsetaccept-encodingaccept-languageauthorizationexpectfromhostif-modified-sinceif-matchif-none-matchif-rangeif-unmodifiedsincemax-forwardsproxy-authorizationrangerefererteuser-agent100101200201202203204205206300301302303304305306307400401402403404405406407408409410411412413414415416417500501502503504505accept-rangesageetaglocationproxy-authenticatepublicretry-afterservervarywarningwww-authenticateallowcontent-basecontent-encodingcache-controlconnectiondatetrailertransfer-encodingupgradeviawarningcontent-languagecontent-lengthcontent-locationcontent-md5content-rangecontent-typeetagexpireslast-modifiedset-cookieMondayTuesdayWednesdayThursdayFridaySaturdaySundayJanFebMarAprMayJunJulAugSepOctNovDecchunkedtext/htmlimage/pngimage/jpgimage/gifapplication/xmlapplication/xhtmltext/plainpublicmax-agecharset=iso-8859-1utf-8gzipdeflateHTTP/1.1statusversionurl
То есть, передавая в каждом запросе User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
SPDY будет ссылаться только на подстроку «User-Agent», чем сэкономит считанные байты, а сам юзер-агент будет передаваться полностью каждый раз. А, возможно, и название заголовка не будет сжато, так как оно набрано кэмел-кейсом.
Реально клево помог бы сжимать заголовки пополняемый словарь, но его, как я понимаю, в SPDY не будет. Или будет?
Это вы в идеальном мире быстрого домашнего интернета. А еще есть мобильный интернет
Интересный аргумент. Но есть и такой — на медленных мобильных каналах исходная страница будет загружаться кусками. И пока загрузится сама страница, большая часть сопутствующих запросов уже будет отправлена, неважно, по HTTP или SPDY.
А еше говорят, что можно устанавливать TLS сессию без шифрования.
Можно, факт. Но медленного установления соединения это не отменяет.
При желании можно использовать SPDY без TLS на отдельном порту.
Вот с этим было бы очень интересно поэкспериментировать. Но я спрашивал об этом представителя nginx на последнем Highload++ и он явно сказал, что нет, SPDY этого не позволяет.
Не поделитесь более подробной информацией на этот счет?
А за счет чего возникает преимущество по скорости у SPDY и HTTP/2? Я не понимаю.
Сжатие заголовков HTTP?
Но ведь в нынешних HTTP/1 браузерах и веб-серверах повсеместно используется Accept-Encoding:gzip,deflate. Что предлагает SPDY помимо этих же модулей, но только используемых по дефолту?
Мультиплексирование запросов и расстановка приоритетов для запросов? — это связанные вещи и рассматривать их лучше вместе.
Допустим, у нас есть загружаемая страница, с которой происходит еще 100 вызовов на дизайнерские картинки, превью фото, js, css…
Как сейчас работает правильная связка HTTP/1 клиент-сервер?
а) 4-8 параллельных соединений с клиента (реалии всех современных браузеров)
б) keep-alive
В результате нет необходимости каждый раз устанавливать tcp-соединение (б) и отпадает вопрос, что делать, когда один тупящий запрос тормозит остальные (а).
Несколько лет назад было такое многообещающее расширение — HTTP pipelining, предусматривавшее передачу нескольких HTTP-запросов в рамках одной TCP-сессии. Вот в нем проблема с тупящим запросом встала в полный рост: запросы из пачки должны были обрабатываться строго по очереди. В результате вместо увеличения скорости работы получили непредсказуемые тормоза. Сейчас это расширение поддерживается браузерами, но почти везде по умолчанию отключено. Но с параллельными соединениями ситуация другая: чтобы начали проявляться тормоза, нужно, чтобы все 4-8 соединений были забиты тупящими файлами. Я, наверное, могу придумать такую ситуацию: из 100 объектов на странице 10 относятся к одному домену, сервер с которым лег. Но это довольно искусственный пример (пропорция должна быть именно такой и мы неявно предполагаем, что страница без этих объектов все еще будет информативна для пользователя).
Получается, что сравнение не совсем корректно.
SPDY по сравнению с голым ненастроенным HTTP/1 сервером, доставленным на машине времени из 2000 года — да, превосходен.
SPDY по сравнению со связкой HTTP/1 + gzip,deflate + keep-alive + параллельные соединения с клиента… примерно то же самое.
А теперь самое интересное. SPDY требует наличия TLS.
Подождите, но ведь TLS-handshake для каждого соединения значительно дольше, чем TCP-handshake в старом добром HTTP/1? Да.
И шифрование трафика значительно увеличит нагрузку на сервер? Да.
И что, в Google это понимают? Да.
«Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection.» — честно признаются разработчики.
В общем, если ваш проект уже использует только https — наверное, есть небольшой бенефит от перехода на spdy.
А вот какой смысл переходить на него с http — не понимаю.
Между прочим, в Швеции Карлсона не особо-то любят, считая его вредным жадиной, который учит ребенка плохому. (на самом деле так оно и есть, но мы как-то привыкли, что ли)
А Астрид Линдгрен ценят за другие книги, коих она написала достаточно. В первую очередь Пеппи Длинныйчулок и Эмиль из Ленеберга.
Пелевин «Бэтман Аполло» — нет. Вообще нет книг Пелевина: видимо, правообладатель хорошо мониторит такие ресурсы.
Лев Рубинштейн «Случаи из языка» — нет.
Не поймите меня неправильно, Флибуста — хороший каталог, просто вкусы людей бесконечно разнообразны.
Или в личку, или, в идеале, еще одним постом :)
Еще и скорость выросла.
Холивара не хочу, но постгресса после этого в моих проектах больше не будет.
А с ним проверять SMART бесполезно, все равно рванет неожиданно.
Для SSD он лишь оценивает число циклов перезаписи и в принципе не может помочь при сломе контроллера, что является основной проблемой отказа SSD.
Фулл вакуум каждый день во время профилактики? А если не успеет?
Все игроки пришли в столицу, сервер с этой локацией лег.
Что делать? Ставить ограничение и мрачных секьюрити на вход в город?
The stream is initialized with the following dictionary (without line breaks and IS null-terminated): optionsgetheadpostputdeletetraceacceptaccept-charsetaccept-encodingaccept-languageauthorizationexpectfromhostif-modified-sinceif-matchif-none-matchif-rangeif-unmodifiedsincemax-forwardsproxy-authorizationrangerefererteuser-agent100101200201202203204205206300301302303304305306307400401402403404405406407408409410411412413414415416417500501502503504505accept-rangesageetaglocationproxy-authenticatepublicretry-afterservervarywarningwww-authenticateallowcontent-basecontent-encodingcache-controlconnectiondatetrailertransfer-encodingupgradeviawarningcontent-languagecontent-lengthcontent-locationcontent-md5content-rangecontent-typeetagexpireslast-modifiedset-cookieMondayTuesdayWednesdayThursdayFridaySaturdaySundayJanFebMarAprMayJunJulAugSepOctNovDecchunkedtext/htmlimage/pngimage/jpgimage/gifapplication/xmlapplication/xhtmltext/plainpublicmax-agecharset=iso-8859-1utf-8gzipdeflateHTTP/1.1statusversionurlТо есть, передавая в каждом запросе
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36SPDY будет ссылаться только на подстроку «User-Agent», чем сэкономит считанные байты, а сам юзер-агент будет передаваться полностью каждый раз. А, возможно, и название заголовка не будет сжато, так как оно набрано кэмел-кейсом.
Реально клево помог бы сжимать заголовки пополняемый словарь, но его, как я понимаю, в SPDY не будет. Или будет?
Интересный аргумент. Но есть и такой — на медленных мобильных каналах исходная страница будет загружаться кусками. И пока загрузится сама страница, большая часть сопутствующих запросов уже будет отправлена, неважно, по HTTP или SPDY.
Можно, факт. Но медленного установления соединения это не отменяет.
Вот с этим было бы очень интересно поэкспериментировать. Но я спрашивал об этом представителя nginx на последнем Highload++ и он явно сказал, что нет, SPDY этого не позволяет.
Не поделитесь более подробной информацией на этот счет?
Сжатие заголовков HTTP?
Но ведь в нынешних HTTP/1 браузерах и веб-серверах повсеместно используется Accept-Encoding:gzip,deflate. Что предлагает SPDY помимо этих же модулей, но только используемых по дефолту?
Мультиплексирование запросов и расстановка приоритетов для запросов? — это связанные вещи и рассматривать их лучше вместе.
Допустим, у нас есть загружаемая страница, с которой происходит еще 100 вызовов на дизайнерские картинки, превью фото, js, css…
Как сейчас работает правильная связка HTTP/1 клиент-сервер?
а) 4-8 параллельных соединений с клиента (реалии всех современных браузеров)
б) keep-alive
В результате нет необходимости каждый раз устанавливать tcp-соединение (б) и отпадает вопрос, что делать, когда один тупящий запрос тормозит остальные (а).
Несколько лет назад было такое многообещающее расширение — HTTP pipelining, предусматривавшее передачу нескольких HTTP-запросов в рамках одной TCP-сессии. Вот в нем проблема с тупящим запросом встала в полный рост: запросы из пачки должны были обрабатываться строго по очереди. В результате вместо увеличения скорости работы получили непредсказуемые тормоза. Сейчас это расширение поддерживается браузерами, но почти везде по умолчанию отключено. Но с параллельными соединениями ситуация другая: чтобы начали проявляться тормоза, нужно, чтобы все 4-8 соединений были забиты тупящими файлами. Я, наверное, могу придумать такую ситуацию: из 100 объектов на странице 10 относятся к одному домену, сервер с которым лег. Но это довольно искусственный пример (пропорция должна быть именно такой и мы неявно предполагаем, что страница без этих объектов все еще будет информативна для пользователя).
Получается, что сравнение не совсем корректно.
SPDY по сравнению с голым ненастроенным HTTP/1 сервером, доставленным на машине времени из 2000 года — да, превосходен.
SPDY по сравнению со связкой HTTP/1 + gzip,deflate + keep-alive + параллельные соединения с клиента… примерно то же самое.
А теперь самое интересное. SPDY требует наличия TLS.
Подождите, но ведь TLS-handshake для каждого соединения значительно дольше, чем TCP-handshake в старом добром HTTP/1? Да.
И шифрование трафика значительно увеличит нагрузку на сервер? Да.
И что, в Google это понимают? Да.
«Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection.» — честно признаются разработчики.
В общем, если ваш проект уже использует только https — наверное, есть небольшой бенефит от перехода на spdy.
А вот какой смысл переходить на него с http — не понимаю.
А Астрид Линдгрен ценят за другие книги, коих она написала достаточно. В первую очередь Пеппи Длинныйчулок и Эмиль из Ленеберга.
Пелевин «Бэтман Аполло» — нет. Вообще нет книг Пелевина: видимо, правообладатель хорошо мониторит такие ресурсы.
Лев Рубинштейн «Случаи из языка» — нет.
Не поймите меня неправильно, Флибуста — хороший каталог, просто вкусы людей бесконечно разнообразны.
Попробуйте, это в самом деле несложно.
У вас на сайте в рейтинге фото лидируют длиннокот, лыжница без головы и замороженная капуста? о_0
Яндекс.Маркет