Application-level caching with transactional consistency

Thesis (Ph. D.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 2012.This electronic version was submitted by the student author. The certified thesis is available in the Institute Archives and Special Collections.Cataloged from PDF version of thesis.Includes bibliographical references (p. 147-159).Distributed in-memory application data caches like memcached are a popular solution for scaling database-driven web sites. These systems increase performance significantly by reducing load on both the database and application servers. Unfortunately, such caches present two challenges for application developers. First, they cannot ensure that the application sees a consistent view of the data within a transaction, violating the isolation properties of the underlying database. Second, they leave the application responsible for locating data in the cache and keeping it up to date, a frequent source of application complexity and programming errors. This thesis addresses both of these problems in a new cache called TxCache. TxCache is a transactional cache: it ensures that any data seen within a transaction, whether from the cache or the database, reflects a slightly stale but consistent snapshot of the database. TxCache also offers a simple programming model. Application developers simply designate certain functions as cacheable, and the system automatically caches their results and invalidates the cached data as the underlying database changes. Our experiments found that TxCache can substantially increase the performance of a web application: on the RUBiS benchmark, it increases throughput by up to 5.2x relative to a system without caching. More importantly, on this application, TxCache achieves performance comparable (within 5%) to that of a non-transactional cache, showing that consistency does not have to come at the price of performance.by Dan R. K. Ports.Ph.D

Sarjallisen ja transaktionaalisen operaation optimointi verkkokaupan käyttäjäpiikin aikana

Monessa järjestelmässä on tarpeellista suorittaa sarjallisia ja transaktionaalisia operaatioita. Sarjallista ja transaktionaalista operaatiota saattaa olla hankalaa tai mahdotonta rinnakkaistaa ja operaation sarjalliset ja transaktionaaliset osat saattavat olla tiukasti pariutuneita. Tällainen operaatio saattaa olla merkittävä rajoite järjestelmän suorituskyvyssä. Suorituskyvylliset rajoitteet korostuvat erityisesti järjestelmän kuormituksen kasvaessa. Tämän diplomityön tavoitteena on löytää asiakkaan verkkokaupan sarjallisen ja transaktionaalisen operaation nykyiselle toteutukselle tehokkaampi korvaava toteutus. Asiakkaan nykyinen toteutus sisältää tiukasti pariutuneen sarjallisen ja transaktionaalisen operaation, joka ei ole pystynyt käsittelemään historiallisesti toistuvaa käyttäjäpiikkiä. Työssä tutustutaan yksityiskohtaisemmin asiakkaan sarjalliseen ja transaktionaaliseen operaation toteutukseen, sekä millaisia vaatimuksia korvaavalla toteutuksella tulee olla. Vaatimusten, kirjallisuuden sekä aiempien tutkimuksien pohjalta suunnitellaan neljä eri toteutusvaihtoehtoa, joista arvioinnin perusteella toteutukseen valitaan kaksi: ominaisuuskohtainen lukitus ja välimuistitus. Alkuperäiselle toteutukselle sekä vaihtoehtoisille toteutuksille suoritetaan kolme eri rasituskoetta suorituskyvyn määrittämiseksi. Rasituskokeissa tärkeimpinä suureina mitataan operaation läpisyöttö ja keskimääräinen pyyntöjen vasteaika. Rasituskokeiden tuloksena oli, että ominaisuuskohtaisessa lukituksessa läpisyöttö nousi kokeesta riippuen 29-96 prosenttia verrattuna alkuperäiseen ja vasteaika pieneni 32-55 prosenttia. Välimuistitoteutuksessa läpisyöttö nousi kokeesta riippuen 340-667 prosenttia ja pyyntöjen vasteaika pieneni 87-98 prosenttia. Ainoastaan välimuistitettu toteutus pystyi selviytymään kaikista rasituskokeista ylittämättä 30 sekunnin pyyntöjen vasteajan rajaa. Tulosten perusteella asiakkaan käyttötarkoitukseen välimuistitettu toteutus on vaihtoehdoista ainut vaatimukset täyttävä vaihtoehto. Välimuistin käyttö sisältää kuitenkin useita riskejä ja haasteita, joiden merkitystä kehittäjän täytyy arvioida käyttötapauskohtaisesti