gzip - за и против

[Bibi]

Става дума за ползването му в сайт.
На пръв поглед звучи като нещо, което може да донесе само ползи, но след замисляне, започват да излизат и други аргументи.
Споделете как да преценя предварително ефекта от ползването му в конкретен действащ сайт към днешна дата?

Имам предвид следното: с нарастването на скоростите, които потребителите ползват, съчетано с усложняването на функционалността на страниците, "тясното място" в комуникацията в много случаи вече е изместено при сървъра. При такава ситуация, ако го натоварим с още една операция, това само би влошило скоростта. Вероятно при голям брой лесни заявки решението да е едно, а при нормален брой, но бавни за обработка запитвания, да е друго. Също така се питам съвременните браузери кога кешират - преди или след декомпресията? За да знам дали да добавя и това към общото време за отговор. Има ли и още съображения, които не съм се сетила да отчета?

[NO CARRIER]

За кеширането не се притеснявай. Когато е включено и документът е статичен (хтмл, картинка), браузърът изпраща заявка като нещо от сорта "if not modified since xxxx.xx.xx xx:xx" и сървърът му отговаря според датата на файла.

Ако "сервираш" предимно текстово съдържание, компресията е за предпочитане. Ако съдържанието е предимно големи, некомпресиращи се файлове, процентът икономия ще е минимален, а при високи скорости както отбеляза по-горе - само ще се натоварва машината.

[Bibi]

Дам...
За кеша не съобразих добре.
И все пак ми е любопитно кое се пази

Иначе в Гугъл има доста теми "pros & cons", но част от тях са стари и не отчитат промяната в обстановката: по-бързи машини и на двете места, по-съвременни браузери...
На всичко отгоре компресираните сайтове не са чак толкова голям процент.
Това ме накара да търся по-комплексен поглед.

[dark]

при днешните скорости на пренос на данни, хардуера (диск+процесор) ще се задъхват повече отколкото интернет връзката. gzip-a за мен оправдан само в много специфични ситуации (големи текстови файлове(т.е. файлове с потенциална огромна компресия)). да не говорим, че ако говорим за толкова голям сайт, трябва да се внимава и за поддръжка от всички браузери а компресията, макар и с широка подръжка не е 100% съвместима с всички проксита/браузери.

може би ако дадеш по-конкретен пример ще можем, да поразсъждаваме по обстойно и съответно да направим няколко тест-а на аналогични конфигурации.

браузерите кешират реалните данни. а според настройката правят проверка за това дали им е стар кеша. повечето по-подразбиране май проверяват всеки път, което се изразява в стандартна заявка, a сървъра отговаря с 304... т.е. реално няма пренос на данни, а само заявка...

[Ghost]

По-добре е да се ползват други методи. gzip компресията за всяка заявка товари прекалено много сървъра. По-добро решение е примерно php + eAccelerator [1]. Кеширането става еднократно и резултатът се запазва в кеш директория на сървъра. При заявка eAccelerator проверява дали кеша е валиден и изпраща вече кешераната страница - хем натоварването е много по-малко, хем се пести трафик.

[1] http://eaccelerator.net/

Има веб сървъри, които предлагат вградена подобна функционалност. Друг вариант е да се ползва reverse proxy пред web сървъра.

[Bibi]

Мерси.
На сървъра имам кеширане.
А компресията за сега ще я обявя за непотребна в конкретния случай.

[recycled_bin]

Аз по-скоро ще се съглася донякъде с изказаните твърдения ... ще ти препоръчам просто да тестваш (някакъв stress test, примерно ab за apache), тъй като има прекалено много "ако". Ще предположа за улеснение, че говориш за apache. Вероятно намираш стари данни из google за mod_gzip, който май не се поддържа особено много, тъй като преди доста време избраха тогавашния mod_deflate и го включиха в apache (виж http://httpd.apache.org/docs/2.2/mod/mod_deflate.html). Съществуват и "не-генерални" решения, примерно в PHP може да се използва вграден output handler за тази цел http://bg2.php.net/manual/en/ref.zli...ut-compression. Всеки от изброените може да се "настройва" достатъчно добре като степен на компресия и/или избор на контента, подлежащ на компресиране. gzip/deflate методите на компресия се поддържат от всички "модерни" браузери (даже някои може би поддържат и bzip) и са достатъчно "леки" и бързи, за да се използват в доста от необходимите случаи. Казах, че има доста "ако", тъй като наистина зависи според случая, т.е. ако да речем се опитваш да постигнеш максимално pps (pages per second) от машината. Ако процесорът ти е натоварен в по-голямата част от времето (примерно над 80-90%), то тогава едва ли ще има смисъл от такава компресия. Също така, ако ползваш някакъв кеш акселератор, поинтересувай се дали кешира компресиран контент (мисля, че е малко вероятно за динамичния такъв, но пък си струва да провериш). Ако генерираш големи динамични страници, които не товарят процесора, нищо чудно една такава компресия да ти вдигне pps, тъй като клиентските заявки ще бъдат обслужвани доста по-бързо. Винаги може да се ползва и нещо междинно, примерно mod_deflate може достатъчно добре да се конфигурира да кешира само определени файлове и/или заявки, а в zlib output stream-а в PHP може да се ползва програмно. Затова ... тествай, нищо не ти пречи.

[NO CARRIER]

Форум е добре да се компресира. ;-)

[Vesu]

Нов съм тук, но гледам има хубав раздел.

Според мен поне deflate е добре да се пусне. Това, че сървърът се товари е вярно, но не вярвам да си използва CPU времето за нещо друго в това време. В същото време връзката не е 100Mbs или 1Gbps колкото е мрежовата карта, а се забавя по-нататък. По-къси пакети, по-добра работа. А и повечето хостинги искат пари и за екстра трафик.