Не можем да кажем, че кеша на заявката е автоматично по-ефективен от негово отсъствие. Кеширане отнема време, така че печалбата на кеш паметта може да се получи само ако спестяванията надвишават разходите. И това зависи от натоварването на сървъра.
Теоретично определяне на кеш паметта е полезно или не, това е да се сравнят обема на работата на сървъра, трябва да направите, за да включвате и изключвате кеша. Ако на кеш паметта е забранено, сървърът изпълнява всички заявки за четене и запис, в първия случай - все още генерира и връща резултата. Ако на кеш паметта е разрешено, при обработката на всяко искане за четене, трябва първо да се провери на кеш паметта и след това или да върне съхранява резултата, или (ако не е в кеша) за извършване на заявка за генериране на набор резултат и да го изпратите на клиента. При обработката на всяка молба, за да го запишете, първо трябва да изпълни, и след това да се провери дали е необходимо да се обяви за нищожно всички записи в кеша.
Въпреки че изглежда достатъчно проста, за да предскаже точно ползите от кеширане трудно. Необходимо е да се вземат предвид също и външни фактори. Например, кеша на заявката може да намали времето, необходимо за формирането на резултата време, но не и времето, необходимо, за да го изпратите на клиента, а именно, тя може да бъде доминиращ фактор.
Един от най-лесните начини да се разбере, дали парични награди - Погледнете честотата на хит кеш. Това показва колко молби са подадени от кеша, а не да се извършва от сървъра от нулата. Когато сървърът получи SELECT изявление, тя увеличава една от двете променливи състояния: Qcache_hits или Com_select, в зависимост от това дали искането е кеширана или не. Следователно, скоростта на удар кеш се изчислява с помощта на формулата Qcache_hits / (Qcache_hits + Com_select).
Всеки SELECT заявка, която не се обслужва от кеша се нарича кеш пропуска. Не попадайте в кеш паметта може да бъде по следните причини.
• Искане предотвратява кеширане или като съдържа не-детерминирана структура (например, функция CURRENT_DATE), или защото на снимачната площадка резултат е твърде голям за neniya запазва в кеш паметта. И в двата случая Qcache_not_cached променлива се увеличава.
• Сървърът не е виждал такова искане, така че той не може да кешира резултата.
• Резултатът от заявката е била предварително кеширани, но сървърът е било изтрито. Това може да се случи поради липса на памет, което се дължи на факта, че някой казал на сървъра, за да се отстрани по искане от кеша, или защото записът е обявен за недействителен.
Ако броят на кеш пропуска е голям и броят на не-кеширане-прокси заявки са много малки, най-подходящия от следните твърдения.
• Кешът все още не е "затопли", което означава, че сървърът не е имал време да се запълни резултатите от кеша на заявката.
• Сървърът винаги виждат исканията, които не са се срещали досега. Ако броят на повтарящи се малки искания, това може да се случи, дори когато на кеша "затопли".
• Твърде често записи кеш е обявена за недействителна.
Записването може да стане невалидна поради фрагментация, липса на ресурси или промени на данни. Ако сте взели кеша има достатъчно памет и конфигуриран параметър query_cache_min_res_unit правилно, обезсилване по-голямата част се дължи на промяната на съхранена стойност. Разберете колко молби са променени данни, позволи на променливите на състоянието Com_ * (Com_update, Com_delete, и т.н. ...) и колко молби са били обявени за невалидни поради липса на памет - променливи Qcache_lowmem_prunes.
Логично е да се разгледа разходите за обезсилване отделно от съотношението на хит. Например, да предположим, че само един прочит от масата, съотношението хит е 100%, а в другата - само се актуализира. Ако съотношението хит изчислява чрез променливи на състоянието, тя ще бъде 100%. Но дори и в този случай използването на кеш паметта не може да бъде ефективна, защото забавя исканията на обновления. При обработката на всяко искане за подновяване е необходимо да се провери, дали да се обяви за нищожно всички кеширани данни, но тъй като отговорът неизменно ще бъде "не", а след това цялата тази работа е свършена напразно. Този вид проблем не може да се забележи, ако не се анализира броя на не-кешира заявки заедно и удари съотношение.
Сървърът, към която смес от операции пишат и четат кеширана от същите таблици, балансирани, не винаги се възползват от наличието на кеша за запитване. Всяка операция за запис прави искания до обезсилване на кеш паметта, докато всяка операция за четене добавя нов кеш заявка. Победата може да се получи само ако тези въпроси след това сервира от кеша.
Ако кешираната резултатът става невалиден преди сървърът получи отново същата команда за избиране, цялата работа на опазване е загуба на време и памет. За да се разбере дали има такава ситуация, да сравните ценности и Com_select Qcache_inserts променливи. Ако почти всички SELECT отчети не попадат в кеша (това увеличава стойността Com_select), след което се кешира им с резултатите, а след това Qcache_inserts ще се различават малко от Com_select. И аз бих искал да Qcache_inserts стойност е значително по-малко Com_select, най-малко, след като "топъл" кеша.
За всяко приложение, не е ограничен потенциал размер на кеша, дори и при липса на записващи операции. Потенциалният размер - е количеството памет, необходима за съхранение на всички кеширани заявки, които могат да работят на заявлението. Теоретично, в повечето случаи, този размер е много голям. На практика обаче, в много приложения, тя е много по-малко, отколкото може да се очаква, се дължи на факта, че повечето от записите в кеша се обезсилва. Дори да изберете много памет за кеш заявка, че никога няма да се напълни повече от потенциалния размер на кеша.
Трябва да се внимава, какъв е процентът на памет разпределени на кеша действително се използва. Ако не използва цялата памет, намаляване на размера на кеша, ако, поради липса на памет често е изместването, - тя се увеличава. Въпреки това, при прекомерен размер на кеша - не е толкова лошо; се дължи на факта, че отпуснатите малко повече или малко по-малко памет, отколкото в действителност е необходимо, изпълнението не е много по-засегнати. Проблемът възниква, когато не използвате много памет или заявки са изселени от кеша толкова често, че всички кеширане носи само загуби.
Също така е необходимо да се пропорционално на размера на кеша искания от други сървъри кеш, като например басейн на ключове буфери или кеш InnoDB MyISAM. Невъзможно е да се предложи курс за всички поводи или който и да е проста формула, както е подходящо равновесие зависи от конкретното приложение.
Свързани статии