riak VS memcache

Известно време (няколко месеца) се тества на riak за storage на PHP sessions и variable caching. До сега за това бяхме използвали memcache и поради една или друга причина имахме някои недоволства към него. Основно при много връзки към него, често удряше в някои лимити и не връщаше резултат, което пък от своя страна беше критично за PHP сесиите, защото потребителите биваха logout-нати.

Какво беше направено с riak?
Riak беше конфигуриран под формата на ring. На 5 уеб сървъра имаше локална инсталация на riak, като данните се репликираха помежду им. Основното ни изискване, както при работата с memcache, беше да може потребителя на всяка своя импресия да ползва различен уеб сървър за по-добро балансиране. Причината за това да направим инсталация на riak локално на всеки сървър под формата на ring е, че няма (или поне на нас не ни беше известен такъв) свестен PHP клиент, с който да си говори по нормална TCP сесия. Всичко се случва с curl requests, което коства доста connections ако сървъра е remote. Затова е и локалната инсталация на всеки сървър – curl request-ите отиват към локален сокет и не правят външно connectivity. Представяте ли си какво ще стане иначе, ако имаме един remote riak server и на една страница стандартно се кешират 10, 20, 30, 100 променливи? Всичко тръгна долу-горе добре. Конфигурацията се изчистваше в продължение на месеци. Основен проблем имахме с чистенето на старите данни, защото riak-a си е предвиден да е NoSQL база данни, а не кеш сървър и съответно няма expire time на записите. Така се наложи да направим собствен handler, който да симулира expire на данните и те да се презаписват или изтриват нацяло.

Какъв беше резултата?
След като решихме, че сме постигнали оптималната конфигурация (за около 3-4 месеца) решихме да направим performance/benchmarking тестове на уеб-а ни. Подбрахме достаточно стабилен брой заявки към сървъра, които генерират най-голямо натоварване както към PHP-то, така и към базата данни и caching системата ни. След тестовете се оказа, че с memcache нещата вървят 6 пъти по-бързо. Абсолютно изненадващо за нас, но все пак това не бяха изгубени 3-4 месеца, защото имаме вече опит с тази база данни и знаем за какво би ни свършила работа. Като цяло се оказа, че не е добро решение за caching.

This entry was posted in IT and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published.