stored procedures i en cms miljÖ stored...

Mall skapad a

v Henrik

STORED PROCEDURES I EN CMS

MILJÖ

STORED PROCEDURES IN A CMS

ENVIRONMENT

Examensarbete inom huvudområdet Datalogi

Grundnivå 30 högskolepoäng

Vårtermin 2014

Simon Bergöö

Handledare: Daniel Sjölie

Examinator: Mikael Berndtsson

Sammanfattning I det här arbetet undersöks det ifall ett CMS som befinner sig på webben kan få bättre exekveringstid ifall databaskod ifrån webbapplikationen istället flyttas till databasen i form av stored procedures. Det har skapats 4 stycken testapplikationer för att testa procedurernas effektivitet jämfört med hur det fungerar originellt. Testapplikationerna skickar en slumpad text till Wordpress funktionerna som har hand om inmatningar till databasen. Textsträngarna matas då in i databasen via antingen procedurer eller databaskod i webbapplikationen beroende på vilken version av Wordpress det är. I det här arbetet förklaras varför det kan vara intressant att använda sig av stored procedures och vilka för och nackdelar det finns med dem. Resultatet av det här arbetet tyder på att det kan finnas anledningar till att använda sig av procedurer vid större projekt men kan anses som överflödigt vid mindre arbeten.

Nyckelord: Stored procedures, PHP, Wordpress

1

Innehållsförtäckning

1 Introduktion ........................................................................................................ 2

2 Bakgrund ............................................................................................................ 3

2.1 Content Management System ................................................................................. 3 2.1.1 Wordpress ....................................................................................................................... 3 2.1.2 Databas ........................................................................................................................... 3 2.1.3 MySQL ............................................................................................................................ 3 2.1.4 Stored procedures ........................................................................................................... 4

2.2 Övrigt ...................................................................................................................... 5 2.2.1 Open Source ................................................................................................................... 5 2.2.2 Benchmark ...................................................................................................................... 5 2.2.3 JMeter ............................................................................................................................. 5

3 Problemformulering .......................................................................................... 6

3.1 Hypotes .................................................................................................................. 6

4 Metodbeskrivning .............................................................................................. 7

4.1 Forskningsetik ......................................................................................................... 8

5 Förberedelser inför genomförande .................................................................. 9

5.1 Progression............................................................................................................. 9

5.2 Litteraturstudie ...................................................................................................... 10

5.3 Fortsatt arbete ...................................................................................................... 10

5.4 Implementation av pilotapplikation ........................................................................ 10

5.5 Pilottest av inmatning av kommentarer ................................................................. 11

6 Utvärdering....................................................................................................... 13

6.1 Presentation av undersökning ............................................................................... 13 6.1.1 Jämförelse av poster inmatade med kommentarer och original Wordpress................. 13 6.1.2 Jämförelse av kommentarer inmatade med procedurer och original Wordpress ......... 16

6.2 Analys och Slutsatser ........................................................................................... 18

7 Avslutande diskussion .................................................................................... 20

7.1 Framtida arbete .................................................................................................... 20

Referenser .............................................................................................................. 22

2

1 Introduktion

Snabba webbsidor är ett ständigt problem i moderna webbapplikationer. Användare vill

alltid att webbsidor ska vara perfekta, de ska ha lite fördröjning, snabb exekveringstid och

allting ska laddas direkt. Det kan vara svårt att uppnå alla de krav som användare ställer på

webbsidor, särskilt webbsidor som är kraftigt trafikerade med besökare och därför är det

viktigt att försöka optimera webbapplikationer till högsta grad. Det är där stored procedures

är intressant, Baogua och Ling(2010) säger att stored procedures är bra för att bland annat

reducera nätverkkapaciteten, förbättra exekveringstiden och förbättra prestandan i en

databas. Utöver det är det bra att använda sig av procedurer när man vill ställa flera SQL-

frågor samtidigt, istället för att låta applikationen skicka frågor mot databasen flera gånger

så går det att lösa med en procedur. Det går då att kalla på proceduren som redan är

färdigkompilerad istället för att skicka flera okompilerade frågor till databasen. Det betyder

att prestandan kommer att förbättras i och med att kommunikationen mellan applikationen

och databasen minskar vilket leder till att det finns potential att närverksbelastningen

minskas drastiskt. Kopplar man då ihop stored procedures tillsammans med ett CMS som

enligt Souer och Joor(2010) är en mjukvaruprodukt som kan bli skräddarsydd och anpassad

med hjälp av inställningar även för personer helt utan programmeringskunskaper. Ett CMS

största användningsområde är bloggar som ofta är högt trafikerade med många besökare.

Om exekveringstiden förbättras med några millisekunder per varje besökare så kan det göra

en märkbar skillnad i större kvantiteter.

Målet med arbetet är att flytta över funktionalitet till databasen från webbapplikationen,

vilket kommer att sprida ut belastningen av systemet, som i sin tur kommer att förbättra

prestandan. Det här arbetet är ett experiment för att undersöka om prestandan kommer att

förbättras när tyngd ifrån applikationen tas bort och istället läggs på databasen i form av

stored procedures. Stored procedures har fungerat bra i andra forskningar(Cheung et al.

2012) på andra plattformar. Det här experimentet ska undersöka ifall det kommer bli ett

liknande resultat på en webbmiljö där applikationerna har andra förutsättningar.

3

2 Bakgrund

2.1 Content Management System Ett Content Management System(CMS) är ett system som används för att hantera innehållet

på en webbsida. Fördelen med att använda sig av ett CMS är att det är lätt att installera, lätt

att underhålla och det går att göra alla administrativa uppgifter som kan behövas på till

exempel en blogg. Innan CMS kom till behövde man skapa webbsidorna manuellt i html och

ladda upp det till webbservern. Enligt Souer och Joor(2010) är ett CMS en mjukvaruprodukt

som kan bli skräddarsydd och anpassad med hjälp av inställningar. De flesta dynamiska

webbsidor använder något slags CMS, i organisationer kan det vara åtråvärt att använda sig

av ett CMS för att det möjliggör att de kan skapa en webbsida i ett tids och i ett resurs

effektivt sätt baserat på standardiserade komponenter som finns i CMS:er.

Enligt Sharma och Kurhekar (2013) är ett CMS ett datorprogram som hanterar publicering,

editering och modifiering av innehåll på webbsidor, såväl som underhåll av webbsidor från

ett centralt gränssnitt. Ett CMS möjliggör att implementera och redigera en webbsidas

innehåll utan att ha någon särskild kunskap inom programmering.

2.1.1 Wordpress Enligt Wordpress(2014) är Wordpress ett CMS som är implementerat av språket PHP, som

är ett ”server-side” skriptspråk som är designat för att göra webbsidor mer interaktiva och

dynamiska. Det är ett opensource ramverk vilket innebär att det kan laddas ner och man har

tillgång till att modifiera källkoden. Wordpress är ett modulärt ramverk, vilket innebär att

det finns möjlighet att importera olika tillägg(addons) till webbsidan. Det finns tusentals

plugins till Wordpress, vilket gör det till ett väldigt justerbart CMS och det är lätt att göra det

personifierat så det passar dig. Effektiv webbdesign är driven av ett behov av att balansera

flexibilitet och hur enkelt det är. Om ett system är för lätt då kan det bara bli använt till ett

syfte, har det för hög flexibilitet kan det vara svårt för nya användare att sätta sig in i det.

Därför siktar Wordpress på att ha en möjlighet att skräddarsy webbsidan för de mer

avancerade användarna som vill hitta en egen lösning. CMS:et kommer fortfarande skeppas

med de grundläggande verktygen för att hjälpa en användare att komma igång. Wordpress är

alltså ett innehålls hanteringssystem som möjliggör skapandet och underhållet av en

webbsida utan att veta några programmeringsspråk.

2.1.2 Databas

En databas är en organiserad samling av data som är till för att arbeta med stora mängder av

information. Det går att lägga, hämta, och hantera informationen i databaser. Man kan säga

att en databas är en samling med rå data som kan bli sorterad, manipulerad och ställa frågor

mot för att kunna producera den data som användaren har bekräftat. I det här fallet är

CMS:et ihopkopplat med databasen, alla poster som skapas, all användarinfo, alla

kommentarer som användare gör och all annan information som kan behövas sparas för att

senare återanvändas kommer att befinna sig i databasen. Enligt Paton och Díaz(1999) är

databaser traditionellt sett förvaringsutrymmen som samlar information som en applikation

anser är nödvändig, informationen kan bli tillgängligt av antingen program eller genom

interaktiva gränssnitt.

2.1.3 MySQL MySQL är enligt Vicknair, Wilkins och Chen(2012) ett Open Source databashanteringsystem

vilket är relationsbaserat. Det ägs av Oracle Corporation och kan användas under antingen

4

GNU licensen eller en vanlig kommersiell licens som kan köpas av Oracle. MySQL är ett

robust, multitrådat, transaktions databashanteringssystem. Det är ett väldigt skalbart system

som kan bli distribuerat över flera olika servrar. Det är världens näst största databas av dess

slag. MySQL kan lagra många typer av data, den kan lagra något så litet som en enstaka

bokstav eller så pass stort som en videofil. Det går att få tillgång till MySQL med hjälp av de

flesta programmeringsspråk, men det vanligaste som man brukar använda tillsammans med

MySQL är PHP, eftersom de jobbar bra tillsammans.

2.1.4 Stored procedures Enligt Microsoft(2014) är procedures ett sätt att samla sql förfrågningar på ett och samma

ställe vilket kan leda till prestandaförbättringar. Det går att förklaras som en sekvens i ett

program som utför en specifik uppgift vilket sedan blir paketerat som en enhet. Om SQL-

frågor blir skrivna inuti en stored procedure kommer den att bli en del av exekveringen av

databasservern, för att sedan använda sig av frågorna i proceduren går det med lätthet att

bara kalla på proceduren. Stored procedures är en uppsättning av redan färdigkompilerad

sqlkod som även befinner sig i ett kontrollflöde(kontrollflöde refererar till den ordning som

koden exekveras i) som är definierat i ett databassystem. Målet med att använda sig av

stored procedures är för att förbättra effektiviteten av en applikation, se till att systemet blir

lättare att underhålla och att försäkra att datans integritet och tillförlitlighet. Enligt Baogua

och Ling(2010) är några av de fördelar som finns med stored procedures enligt följande:

Reducering av nätverks kapacitet. Om en applikation använder sig av stored

procedures behöver den bara kalla på det namn som proceduren har och de

parametrar som kan behövas. När exekveringen av proceduren är färdig, behöver den

bara skicka tillbaka resultatet till klienten. Vilket innebär att kommunikationen

mellan klient och databas minskar drastiskt.

Förbättrar exekveringstiden. Eftersom en procedur redan är kompilerad och är

lagrad i databasen kommer inte någon kod kompileras dynamiskt av databasservern.

Den behöver inte kompileras var gång den exekveras vilket kommer att spara en hel

del tid.

Förbättrar databasens prestanda. När en procedur har blivit exekverad kommer den

att befinna sig i cache minnet. Vilket innebär att nästa gång en applikation vill

komma åt proceduren kan den hämta och exekvera den kompilerade binära koden

direkt från cachen.

Det är dock inte bara positiva aspekter med att flytta över applikationens sql-frågor till

databasen, det finns även nackdelar med det hela. Nackdelar som till exempel att i ett

företag, för att flytta över sin kod till databasen från applikationen så kommer

programmerarna behöva lära sig ett nytt programmeringsspråk. Utöver det kommer de

behöva övervaka två stycken applikationer istället för en. Det är inte heller vinsamt att flytta

över funktionalitet till databasen från applikationen, om databasen redan är under hög

belastning finns det en möjlighet att prestandan inte kommer att förbättras ifall mer tyngd

kommer att läggas på databasen.

5

2.2 Övrigt

2.2.1 Open Source Koponen och Hotti(2005) säger att Open Source mjukvara är en mjukvaruprodukt som är

licenserad med en speciell Open Source licens. Open Source licenser ger användarna

källkoden och den rätt att modifiera och vidaredistribuera mjukvaran.

I det här arbetet är det här intressant med Open Source just på grund av att det måste gå att

redigera filerna i ett CMS i ett experiment som det här, annars kommer det inte gå att

jämföra två olika versioner av CMS:et. Det är tillåtet att återanvända den kod i det här

sammanhanget i ett eget projekt, eller att modifiera koden så som önskas. Filerna är lätt

tillgängliga för just det ändamålet att man ska kunna modifiera filer, lägga till kod, göra vad

som nu behagas med innehållet helt enkelt.

2.2.2 Benchmark

Benchmarking är enligt Saavedra och Smith(1996) processen där man kör ett särskilt

program eller en arbetsbörda på en specifik dator eller system och mäter den resulterande

prestandan. Den tekniken förser utföraren av benchmarken en noggrann evaluering av

prestandan på den maskinen som utförde arbetsbördan.

2.2.3 JMeter Enligt Apache Software Foundation(2013) är JMeter är ett Open Source mätningsverktyg

som är gjort i programmeringsspråket Java. Programmet var från början till för att mäta

prestanda på webbapplikationer, men nu förtiden har sen dess expanderat till andra test

funktioner. JMeter har funktioner som att ladda och prestanda testa många olika slags

protokoll. Det kan användas för att testa prestandamäta både på statiska och dynamiska

applikationer. Det kan även användas för att stimulera hög belastning på en server. Det

betyder att JMeter kan användas till att prestandamäta CMS:er och andra typer av system.§

6

3 Problemformulering

Det kommer att undersökas i det här arbetet om exekveringstiden kommer att förbättras

genomatt byta ut kod från applikationen till stored procedures i databasen. SQL-frågor

kommer att ställas mot databasen istället för att ställa dem i applikationen. Utöver det

kommer det att undersökas hur mycket det går att vinna på att implementera stored

procedures i ett redan fungerande system för att göra ett försök till att optimera CMS:et ur

ett exekveringstids perspektiv.

Det här arbetet kommer att gå ut på att flytta över funktionalitet i CMS applikationen till

databasen. Det är alltså ett experiment för att se om prestandan kan förbättras om tyngd

ifrån applikationen istället läggs på databasservern. Enligt Cheung och Arden(2013) är ett

vanligt sätt att förbättra en applikations effektivitet genom att förminska antalet gånger en

applikation tar kontakt med en databas. Det kan man åstadkomma med hjälp av stored

procedures. Varje kontakt med databasen kommer att betyda en rundresa mellan klienten

och databasen. Flyttar man beräkningarna från applikationen till databasservern så

reduceras antalet rundgångar mellan de två servrarna vilket kommer leda till en ökad

effektivitet.

I en undersökning(Cheung et al. 2012) beskriver de att efter de bytte till stored procedures i

deras applikation, skriven i programmeringsspråket Java, då förminskades

nätverksfördröjningen upp till tre faldigt, vilket resulterade i en 1.7 gånger förbättring totalt

av systemet. Givet att det inte är en Java appliktion som kommer att testas i det här fallet,

men det är fortfarande optimeringen av databasen som är intressant. Förbättringen som kan

ske är substantiell ur snabbhets perspektiv. Eftersom den här studien har utgått från Java

och inte arbetat i en webbmiljö, då kommer inte resultaten bli desamma vilket gör det här

arbetet intressant.

Java använder ofta samma dator för databas och applikation, vilket innebär att det inte

kommer bli samma rundgångar mellan databas och applikation som det kan bli på webben.

Ett CMS och dess databas befinner sig oftast på två olika datorer om det gäller ett system

med hög belastning, därför kommer stored procedures vara intressant på webben, för att

försöka minska antalet rundgångar mellan de båda applikationerna för att i sin tur förbättra

exekveringstiden.

3.1 Hypotes I undersökningen som Cheung et al.(2012) gjorde, utförde de procedurer i Java med ett

lyckat resultat, därför skulle ett liknande arbete som sker på ett CMS med webben som

plattform också kunna få ett positivt resultat. Om tyngd från applikationen istället placeras

på en annan server, i det här fallet gäller det främst databasen, då kommer arbetsbördan att

spridas ut. Vilket förhoppningsvis kan leda till att exekveringstiden förbättras, eftersom

arbetsbördan sprids ut istället för att vara på ett ställe.

Målet med projektet är att få bättre och snabbare exekveringstid, ett säkrare system och

möjligtvis enklare kod.

7

4 Metodbeskrivning

Det här arbetet kommer att jämföra två olika versioner av CMS:et Wordpress. En version där

original versionen av Wordpress används och en version av Wordpress där viss

funktionalitet från webbsidan har blivit överförd till databasen. Valet av CMS var baserat på

ett par olika kriterier. CMS:et var tvunget att vara Open Source och det var tvunget att ha

flera instanser av databaskod i webbapplikationen utöver det var det viktigt för en egen del

att det var skrivet i PHP. Wordpress är ett av de största CMS:en på marknaden och fall in i

de kriterier som var eftersökta i det här fallet. Det kommer utföras som ett experiment för att

undersöka om det kan bli förbättringar i systemet ifall mer vikt läggs på databasservern

istället för applikationen. Alternativt går det att ändra CMS om Wordpress inte når ändra

fram, till exempel ifall CMS:et inte har tillräckligt med funktionalitet i applikationen som går

att flytta över till databasen.

Båda två versionerna av Wordpress kommer att mätas på samma villkor, på samma datorer

och på samma SQL-frågor. Det är exekveringstiden från att frågan har blivit skickad och tills

dess att den är avklarad som kommer att mätas. Alltså den tid det tar att hämta information

från databasen. Alternativt går det att ta bort nätverksdelen, vilket innebär att det bara

kommer att mätas på CMS:en via algoritmer. Det kan vara intressant om CMS:et parallellt

exekverar applikation och databas på en dator för att verkligen bara jämföra de två olika

versionerna av CMS:en utan nätverksportionen. Det är även nämnvärt att tillägga att

Wordpress är ett open source CMS vilket innebär att det CMS:et är gratis och det kommer

att gå att modifiera filerna vilket kommer vara en vital del för experimentets genomförande.

De funktioner som kommer att flyttas från applikationen till databasen kommer i första

hand att vara bloggposter och kommentarer. De har högst prioritet på grund av att de

kommer att ge mest intressant data när en benchmark görs på dem, eftersom de är de största

och mest vitala delarna i CMS:et, sen kommer det fyllas på med mer funktioner i mån av tid.

Det är alltså de två funktionerna som kommer att ha högst prioritet att ändras. Anledningen

till att just de funktionerna har valts är att det faktiskt är de som har potentialen att lägga

mest tyngd på databasen.

Prestandan kommer att mätas på ett liknande sätt som Li och Manoharan(2013) gör i sitt

experiment, de går igenom hur deras experiment ska läsa, lägga till nya, ta bort och hämta

alla värden. Det här arbetet kommer att fokusera på att undersöka hur snabbt båda

versionerna av CMS:et kan lägga till nya bloggposter och kommentarer. exekveringstiden

kommer att mätas i hur snabbt det går att skapa 10, 100 och 500 poster i både kommentarer

och bloggposter. Anledningen till att just de här funktionerna ska mätas är på grund av att de

är beräkningstunga och intensiva uppgifter.

Enligt Cai, Nerurkar och Wu(1998) finns det klara fördelar att använda sig av en egenskapad

benchmark applikation. De menar att de flesta mätningsverktygen inte är pålitliga och

resultaten kan ofta vara missledande. Resultaten som en sluten benchmark applikation ger

kan vara svåra att lita på eftersom man inte kan veta vad som försiggår bakom kulisserna,

samtidigt som ett egen skapad benchmarkapplikation som koden kommer att publiceras till,

kan andra forskare lätt återskapa och kolla så att allt stämmer överens. Det kan vara svårt för

utomstående som läser arbetet och kunna lita på mätningsresultaten ifall de är gjorda av en

mätapplikation som man inte själv står för, mätresultaten kan lätt vara fel och det finns inget

sätt att veta ifall resultaten stämmer om man inte gör en egen mätapplikation. För att en

8

benchmark ska kunna vara representativ måste den vara optimal, upprepningsbar och den

ska inte gå att lura. Med det i åtanke kommer det istället för att använda en existerande

benchmark kommer istället en egen variant att skapas. Mätapplikationen kommer då att

vara helt öppen med publicerad källkod för att experimentet ska kunna återskapas.

Om mätapplikationen mot all förmodan inte kommer att ge det resultat som det var tänkt,

då kommer den externa benchmark applikationen JMeter att användas istället. Det är som

sagt att föredra att använda sig av en egen benchmark applikation, men ifall det inte kommer

att gå att använda sig av en egenskapad applikation, då kommer JMeter att finnas i dess

plats som en alternativ mätningsmetod.

4.1 Forskningsetik

Arbetet kommer att mätas på en och samma dator för att se till att resultaten blir rättvisa. På

den datorn kommer det bara mätas på ett operativsystem, samt på en och samma

internetuppkoppling. Arbetet kommer även att mätas på olika webbläsare(Chrome och

Firefox), för att undgå att det finns några fel på en specifik webbläsare eller version av

webbläsare som används.

Det är medvetet att andra som vill försöka reproducera det här arbetet inte kommer få exakt

samma resultat i och med att förutsättningarna kan vara annorlunda. Men all kod, alla

verktyg som kommer att tillverkas eller att användas och den hårdvara som används

kommer att publiceras. Vilket innebär att även om personen som försöker reproducera

arbetet inte har exakt samma tillgångar, har han ändå samma förutsättningar till att

producera en likvärd produkt. Det kommer att bidra till ett pålitligt testresultat.

Experiment kan antingen vara människoorienterade eller teknikorienterade enligt Wohlin et

al.(2010). Det här arbetet är just ett teknikorienterat experiment, vilket innebär i det här

fallet kommer resultaten att vara mer exakta och de kommer inte vara partiska i och med att

det inte finns någon mänsklig påverkan.

9

5 Förberedelser inför genomförande

Som förberedelser inför genomförandet tillverkades det två stycken testningsapplikationer,

det skapades en procedur i Wordpress databas och de gjordes modifikationer i Wordpress

funktioner. Testapplikationerna som skapades är nästan identiska, det som skiljer dem åt är

att de är anpassade till två olika versioner av Wordpress, den som har blivit ändrad i och

original versionen.

5.1 Progression

Tidigt i implementationen upptäcktes det att Drupal faktiskt inte var det optimala CMS:et att

använda sig av. Efter en del efterforskning var det bästa beslutet att byta CMS till Wordpress

som faktiskt var det mest gynnsamma i ett modifierings perspektiv.

Ett problem som uppstod var att när testningsapplikationen höll på att konstrueras gick det

inte bara att inkludera den Wordpress fil som man ville komma åt. Istället skulle fyra

stycken filer inkluderas, config filer samt databasfiler var tvungna att inkluderas Wordpress

skulle kunna användas av externa PHP filer. Utöver det gick det inte heller att bara kalla på

funktionen som man gör vanligtvis, istället tvingades Wordpress en att använda sig av deras

globala variabel wpdb för att få in datan från testprogrammet till Wordpress.

Så här såg det ut från början, det är hur man brukar skriva när filer ska inkluderas och hur

det antogs att det funkade.

Include(”../wp-includes/wp-db.php”);

Det fanns ingen misstanke att det var själva inkluderingen som var fel eftersom det är det korrekta

sättet att inkludera filer i PHP. Men efter mycket felsökning och att allting hade testats så byttes den

tidigare inkluderingen till följande.

include_once '../wp-config.php';

include_once '../wp-load.php';

include_once '../wp-includes./wp-db.php';

include_once '../wp-includes./pluggable.php';

Efter att filerna hade blivit inkluderade gick det äntligen att komma åt filen wp-db.php, men ett

annat problem uppstod då. Det blev uppenbart att det inte gick att kalla på funktionen som man

brukar göra genomatt skriva:

Insert(comments, $data);

Istället behövdes en global variabel som heter wpdb deklareras för att kunna kalla på

funktionen på så vis som Wordpress själva kallar på funktioner i sitt system.

$wpdb->insert($wpdb->comments, $data);

10

Det var länge ett problem att det inte gick att mata in en array i proceduren, det blev

problem på databas änden när den skulle användas som värden i proceduren. Anledningen

till att en array önskades från början var att det hade varit snyggare om systemet var helt

dynamiskt. Men eftersom det inte gick att mata in data i proceduren via en array betydde det

att det istället skulle behövas flera olika funktioner som var och en matar in data till sin

respektive databastabell istället för en funktion som kan mata in data till alla olika tabeller.

5.2 Litteraturstudie

Inspirationen till att modifiera ett CMS kom från Cheung et al. 2012 artikel där de säger att

prestandan ökade i deras Java applikation när de bytte systemet så att det använde sig av

stored procedures istället för den föregående metoden. Därför lät det intressant att försöka

optimera ett system som befinner sig på webben med hjälp av procedurer för att se om det

har en liknande effekt.

Inspiration till mätningsapplikationen kom från artikeln Cai, Nerurkar och Wu(1998) skrev,

de sa att det ofta inte går att lita på externa benchmark applikationer på grund av att man

inte vet vad som föregår bakom kulisserna. Därför skapades en egen mätningsapplikation för

att vara säker på att mätningarna skedde på ett rätt sätt och att det inte blev några fel på

resultaten.

5.3 Fortsatt arbete

Inför genomförandedelen kommer arbetet att utvecklas med fler optimeringar av CMS:et.

Inmatning av poster och sökningsfunktionen kommer att optimeras med hjälp av procedurer

i databasen. Det kommer även att bli en mer grafisk testapplikation, det kommer gå att välja

vad man vill testa och hur många till exempel kommentarer man vill mata in i systemet med

hjälp av ett gränssnitt. Det ska även helst vara en mätningsapplikation över båda versionerna

av Wordpress, för att lätt kunna jämföra resultaten och slippa gå emellan de olika filerna för

att testa funktionerna.

5.4 Implementation av pilotapplikation

Testningen genomfördes via ett PHP-script genom en webbläsare. Testningsapplikationen

för den modifierade versionen samt original versionen av Wordpress ser nästan identiska ut

med en liten skillnad hur datan matas in till CMS:et. Ett PHP-script vars jobb är att generera

slumpmässiga meningar inkluderas i testningsapplikationen för att skapa data som

kommentarerna ska fyllas med. I en for-loop bestäms det hur många kommentarer som vill

skapas. I den for-loopen finns det ytterligare en for-loop vars jobb är att bestämma hur

många meningar det får finnas i kommentaren. Om det är satt att det ska vara 5 meningar

som det är i det här testfallet kommer, det genereras 5 stycken meningar som sätts ihop till

en sträng. En array skapas med bland annat strängen med dummy-data som innehåll för att

sedan kalla på funktionen i CMS:et som sköter inmatningen av data till databasen. Efter att

datan har skickats iväg till CMS:et kommer scriptet att itereras tills det numret som ställdes

in i den första for-loopen har mötts. Datan kommer sen matas in i databasen via antingen en

procedur eller via ett databas anrop via CMS:et. Alltså, en timer startas, en for-loop startas

för att bestämma hur många kommentarer som ska skapas, en till for-loop skapas innuti den

föregående för att bestämma hur många rader det skall vara i kommentaren. Raderna läggs

ihop till en sträng. Strängen läggs in i en array där all annan data som behövs redan är

11

hårdkodad på grund av att resten av datan inte är lika viktig att den är flexibel. Funktionen

som kallar på databasproceduren kallas på, informationen matas in i en procedur via ett

databas anrop, sen stoppas timern. Tiden på hur lång tid det tog att mata in kommentarerna

visas på skärmen.

Funktionen som modifierades heter _insert_replace_helper(). Datan skickas från

funktionen wp_insert_comment som i sin tur hämtar informationen som skall matas in i

databasen från andra funktioner som även returnerar ett default värde om inget annat värde

anges. Wp_insert_comment kommer att skicka datan vidare till en funktion som heter insert

som i sin tur kallar på _insert_replace_helper som är den funktion som har blivit

modifierad. Funktionen går ut på att den gör alla värden i arrayen som skickas med till nya

variabler för att på ett lättare sätt kunna kalla på proceduren och lätt skicka med alla värden.

5.5 Pilottest av inmatning av kommentarer

Mätningarna genomfördes genom att ta tid på hur lång tid de tog att mata in det antal

kommentarer som angivits i testningsapplikationen. I det här fallet matas det in 500

kommentarer där alla är fem meningar långa, antalet ord kan variera lite men i snitt så är

alla kommentarer ungefär lika långa. Testapplikationen har skapats på egen hand.

Syftet med den här pilottestet var att visa att det faktiskt går att mäta och visa en skillnad

mellan de två versionerna av Wordpress.

Figur 1 Resultat av 500 inmatade kommentarer

I figur 1 går det att se resultaten när PHP-scriptet kördes fyra gånger på vardera version av

Wordpress. I det här testfallet matades det in 500 kommentarer per exekvering av

testningsscriptet och det kördes fyra gånger på båda versionerna. Standardavvikelse på den

12

modifierade versionen blev 20,4 sekunder vilket betyder att det är en relativ låg

standardavvikelse. I original Wordpress blev standardavvikelsen 20,67 sekunder, en aning

längre än den modifierade versionen med fortfarande en låg standardavvikelse i relation till

mätningarna.

Anledningen till att det blir ett bättre resultat stadigt för den modifierade versionen är

antagligen för att proceduren läggs till i cachen vilket hypotetiskt sett gör att resultaten blir

bättre.

13

6 Utvärdering

I det här kapitlet presenteras alla tester som har genomförts på båda versionerna av

Wordpress, den modifierade versionen med procedurer samt original versionen av

Wordpress. Testerna har utförts både på Firefox och Chrome. I de här testfallen mäts det på

exekveringstiden, hur lång tid det tar från att scriptet startas till det avslutats och alla

förfrågningar har blivit avklarade.

6.1 Presentation av undersökning

Testerna har utförts på både Firefox och Chrome för båda versionerna av Wordpress.

Testfallen har skett i serier av 10, 100 och 500 inmatningar av poster samt kommentarer för

att undersöka ifall det blev skillnad i resultatet beroende på kvantiteten av inmatningar.

Testapplikationerna fungerar likt den som använts i pilotstudien, förutom att det har skett

ändringar för att möjliggöra inmatning av poster och inte bara kommentarer.

Testapplikationen arbetar med exekveringstid, tiden startar när den första förfrågningen

sker och slutar när sista förfrågningen har gått igenom.

Platformen som har använts för att genomföra testerna gjordes på laptop med olika installationer av Wordpress-3.8.2 installerat. Alla tester har utförts lokalt via localhost vilket gör att alla testerna har blivit rättvist testade i och med att det inte blir någon nätfördröjning. Intel i7-2630QM 2,5GHz, 4G RAM, Windows 7 ultimate 64 bitars.

6.1.1 Jämförelse av poster inmatade med kommentarer och original Wordpress

Figur 2 Graf över en inmatning av 10 poster

14

Här går det att se sekvenser av inmatningar av 10 poster i följd. Det är väldigt lika resultat

förutom att det förekommer ett fåtal spikar i Chrome, både med och utan procedurer.

Det bästa Chrome resultatet med procedurer blev 0,43 sekunder för att mata in 10 stycken

poster. Det snabbaste resultatet som Chrome fick utan procedurer blev även det 0,43

sekunder. Original versionen fick dock högre sämsta resultat med 1,28 sekunder mot

procedur varianten som fick 1,17 sekunder som sämsta resultat, vilket är ganska betydelsefull

skillnad i de här små skalorna.

Firefox bästa resultat blev 0,44 sekunder med procedurer, utan procedurer var Firefox bästa

resultat 0,33 sekunder vilket är en förbättring med 25%.


Om den snabbaste tiden som Chrome fick jämförs med den snabbaste tiden som Chrome

fick i Figur 2. I Figur 2 skapas det 10 stycken poster på 0,43 sekunders tid, vilket gör att att

det skapas en post varje 0,043 sekund. I den här grafen var den snabbaste Chrome tiden

med procedurer4,74 sekunder för att skapa 100 poster, vilket innebär att det skapas en post

varje 0,0474 sekund, vilket är en försämring med 7.73% mot den snabbaste Chrome tiden

med procedurer i Figur 2. Det innebär att i det här fallet gick det långsammare att skapa mer

poster jämfört med att skapa mindre poster i ett genomsnitt. Men i Firefox gick det

snabbare. Firefox snabbaste tid i föregående graf var 0,44 för att skapa 10 poster. Det

skapades en post var 0,044 per sekund i det fallet. Den snabbaste tiden i den här grafen som

Firefox hade när den skapade poster med hjälp av procedurer var 3,84 sekunder, vilket

innebär att det skapades en post var 0,0384 sekund, vilket är en förbättring med 12.73%

jämfört med den snabbaste Firefox tiden i Figur 2.

Original versionerna av Wordpress hade både lägre dalar och lägre toppar än sina procedur

motsvarigheter. Chromes sämsta tid var 0,02 sekunder bättre än Chromes sämsta tid med

procedurer, originalversionen hade som sämsta tid 5,63 sekunder och procedur versionens

15

sämsta tid var 5,65. Firefox original version var också 0,02 sekunder snabbare än sin

procedur motsvarighet, original Firefox hade som sämst 5,04 och procedur Firefox hade

5,06 som sämsta tid. Både Chrome och Firefox hade bättre tider än sina procedur

konterparter, den bästa tiden hade Firefox med 3,58, vilket innebär att det skapades en post

varje 0,0385 sekund. Original Firefox bästa tid var alltså 6.77% bättre än procedur versionen

av Firefox. Original Chromes bästa tid var 4,26 sekunder, jämfört med procedur Chromes

bästa tid som var 4,74 sekunder, Original Chrome var 10.13% snabbare än den bästa tiden

med procedurer på Chrome.


Chromes bästa tid med procedurer är 19,69, det innebär att det skapas en post varje 0,03938

sekunder. Det är en förbättring om man jämför med Chrome i Figur 3. Firefox bästa tid med

procedurer är 19,22 i den här grafen, det betyder att det skapas en post varje 0,03844

sekund. Firefox resultatet är samma resultat som Firefox fick med procedurer i Figur 3.

Chromes bästa tid utan procedurer var 19,5 sekunder, vilket betyder att det skapas en post

var 0,039 sekund, vilket är 0,00038 sekunder i snitt snabbare än den bästa tiden med

procedurer för Chrome, det är en förbättring med 0.96% jämfört med motsvarigheten med

procedurer. Snabbaste tiden för Firefox utan procedurer var 19,23 sekunder, vilket innebär

att det skapades en post varje 0,03846 sekunder i det testfallet. Firefox utan procedurer

presterade 0,00002 sekunder långsammare än sin konterpart med procedurer, vilket är

0,05% bättre.

Chrome har de sämsta resultaten genom alla testfallen av Wordpress. Firefox snittar bra

resultat genom alla 5 testfallen förutom på ett ställe i testfall 1 där det spikar.

16

6.1.2 Jämförelse av kommentarer inmatade med procedurer och original Wordpress

Figur 5 Graf över en inmatning av 10 kommentarer

Chromes bästa tid med procedurer var i det här fallet 0,37 sekunder, vilket är 17,78% bättre

än Firefox bästa resultat som var 0,45 sekunder med procedurer. Det skapas en kommentar

varje 0,037 sekund för Chrome vilket är hela 0,008 sekunder snabbare än Firefox. 0,008 per

varje post kan anses litet men det är ett substantiellt nummer i de här små skalorna.

Chromes bästa tid utan procedurer var 0,37, vilket är 2.63% bättre än Firefox vars bästa tid

utan procedurer var 0.38 sekunder. Även här skapas det en k ommentar varje 0,037 sekund,

0,001 sekunder snabbare än Firefox.

I testfall 3 gjorde Chrome utan procedurer hela 27.54% bättre än Chrome med procedurer.

17

Figur 6 Graf över inmatning av 100 kommentarer

I testfall 2 fick Firefox med procedurer 3,66 sekunder, vilket är en väldigt bra tid jämfört

med de tidigare mätningarna som har genomförts. Det skapas en kommentar varje 0,0366

sekund, det är 3.94% snabbare än Firefox utan procedurer vars bästa tid var 3,81 sekunder.

3,66 sekunder är en klar förbättring om det jämförs med Figur 5 där Firefox med procedurer

fick 0,45 sekunder, vilket i snitt är en ganska dålig tid. Firefox med procedurer fick både den

bästa tiden samt de 2 sämsta tiderna

Chromes bästa tid med procedurer är inte lika imponerande, det bästa resultatet blev 4,04

och snittade i övrigt väldigt högt. Procedur Chrome gjorde sämre ifrån sig än original

Chrome på alla tillfällen utan på testfall 1. På testfall 1 gjorde procedur Chrome 3.35%(4,04

sekunder) bättre än Chrome utan procedurer(4,18 sekunder).

Original Chrome och Original Firefox presterade i snitt bättre än sina konterparter.

18

Figur 7 Graf över inmatning av 500 kommentarer

I testfall 5 fick Chrome med procedurer sin bästa tid med 19,41 sekunder. Jämför man det

med original Chrome som hade 2.73% bättre tid med 18,88 sekunder som rekord. I Chrome

med procedurer skapas det en kommentar var 0,03882 sekund, vilket är ett sämre snitt i

resultat jämfört med både Figur 6 och Figur 5.

Firefox snabbaste tid med procedurer finns i testfall nummer 4 med tiden 20,44 sekunder,

jämför man den tiden med Firefox utan procedurer vars bästa tid är 18,46 så är procedur

varianten 9.69% sämre. Firefox med procedurer matar in kommentarer var 0,04088 sekund

gentemot original Firefox som matar in kommentarer varje 0,03692 sekund. En kommentar

varje 003692 sekund är ett väldigt bra snitt, inte ett bättre snitt än det bästa resultatet i

Figur 6, men fortfarande ett bra resultat gentemot de andra resultaten i Figur 7.

Firefox med procedurer har fått sämst resultat i varje testfall i den här grafen och Original

Firefox presterade bäst i alla testfall utom nummer 2.

6.2 Analys och Slutsatser

Ett mönster som är tydligt genom alla testerna är att de bästa resultaten genom alla testfall

alla hamnar på ungefär 0,037 i snitt. Vilket kan få en att undra ifall det kan vara att det inte

går att lägga till poster och kommentarer snabbare i Wordpress. Eller att det kan vara datorn

som är långsam, vilket kan leda till att det finns möjligheten att det är ett hårdvaru problem

som gör att resultaten blir väldigt lika på de bästa resultaten. Det finns flera andra

möjligheter varför den bästa tiden nästan alltid blir den samma, en möjlighet kan vara att

det inte går att mata in entiteter snabbare in i databasen. Det skulle även kunna vara brister i

Wordpress som gör att datan inte kan passeras snabbare genom funktionerna än vad det nu

görs. Det skulle också kunna vara en ren slump att resultaten blir lika.

19

Firefox presterar bättre nästan överallt både med och utan procedurer, eftersom Firefox

resultaten är bättre konsekvent i alla graferna förutom i Figur 7 där det matas in 500

kommentarer i Wordpress. Då går det att dra parallellen Firefox är en snabbare webbläsare

än Chrome angående den här typen av uträkningar. Original versionen av Wordpress med

Firefox fick bäst resultat 3 gånger av 6, eftersom Firefox med procedurer fick bäst resultat 2

gånger och original Chrome fick bäst 1 gång. De här resultaten visar att Firefox helt enkelt är

den bättre webbläsaren i det här syftet, vad det beror på är oklart dock.

Skillnaderna mellan att använda sig av procedurer och inte är minimala. Firefox och Chrome

med procedurer fick bara bättre resultat än original versionerna vid 2 av 6 tillfällen(Figur 4,

testfall 4 och Figur 6, testfall 2) samt att Chrome med procedurer fick bäst resultat en

gång(Figur 5, testfall 5) vilket betyder att procedur versionerna av Wordpress fick bäst

resultat 50% av graferna. Båda versionerna och båda webbläsarna fick dock spikar

oberoende på vilken plats på testfallen de var. Första tanken i pilotstudien var att det var

höga spikar i början av procedur versionerna på grund av att proceduren lägger sig i cachen

när proceduren exekveras flera gånger i följd. Men eftersom spikarna kom i slumpvis

ordning visade det sig att cache teorin inte stämde.

Resultaten tyder på att när det matas in små nummer som 10 poster eller kommentarer så

blir resultaten minimalt åtskilliga. I större projekt blir det anledningen till att använda sig av

procedurer allt större, exekveringstiderna blir allt viktigare ju mer belastad sidan är. Därför

är det viktigt att försöka sänka exekveringstiderna så mycket som möjligt på trafikerade

sidor.

Eftersom det finns tillfällen där procedur varianterna av Wordpress har riktigt bra tider, om

det går att reproducera de bra tiderna för att göra på något vis att de förekommer oftare. Då

kan procedurer fungera riktigt bra i en större webbplats.

I Cheung et al.(2012) arbete säger de att det blir en förbättring med 1,7 gånger med hjälp av

procedurer i deras system och att det kan bli en förbättring upp mot 3 gånger så snabbt

jämfört med en applikation utan stored procedures. Anledningen till att varför de kan få

mycket bättre resultat än de resultat som har blivit presenterade i det här arbetet är nog att

de samlar flera olika SQL förfrågningar som finns i applikationen i samma procedur. Det

betyder att det blir mycket färre förfrågningar som sker från applikationen till databasen,

vilket kommer att generera bättre resultat. I det här arbetet har det inte samlats flera

förfrågningar i samma procedur, vilket innebär att det sker samma antal rundgångar mellan

applikationen och databasen som det hade gjort utan procedurer. Om det istället hade mätts

flera operationer i båda versionerna av Wordpress, där det hade varit flera förfrågningar i

proceduren, då hade resultaten nog varit i procedur versionens favör.

Det går att dra slutsatsen att ifall det används mycket funktionalitet i varje procedur, då

kommer det vara värt att använda sig av procedurer. Eftersom antalet rundgångar mellan

applikation och databas minskas. Är det dock bara en SQL fråga per procedur kommer det

nog inte vara värt att använda sig av procedurer i och med att antalet rundgångar mellan

applikation och databas kommer att bli samma till antalet.

20

7 Avslutande diskussion

Målet med det här arbetet var att undersöka ifall ett system på webben skulle få ett liknande

lyckat resultat som de fick i Cheung et al.(2012) undersökning på en Java plattform. I

hypotesen står det att även på webben finns det möjlighet att det blir ett lyckat resultat

eftersom det blev ett lyckat resultat på en Java applikation. Om man jämför resultatet med

hypotesen så blev egentligen inte resultaten olyckade, men inte heller lyckade. Procedur

versionerna av Wordpress hade de snabbaste tiderna på hälften av graferna, vilket är ett

acceptabelt resultat. Men det fanns få bra resultat och många spikar på slumpade tillfällen

vilket gjorde testerna inkonsekventa. Det var svårt att tyda om det fanns något mönster

varför resultaten faktiskt blev som de blev, eftersom det fanns spikar varvat av bra resultat

på alla versioner av Wordpress och webbläsare.

Det finns självklart risk i att det är testningsapplikationen som gör att det blir spikar och

inkonsekventa resultat. Eftersom det är en egenskapad testapplikation som Cai, Nerurkar

och Wu(1998) råder om att man ska göra, så finns det möjlighet till att den är felaktig. Men

om det hade varit ett externt program som användes för att testa applikationerna då vet man

inte med säkerhet om det går att lita på resultaten. Nu går det att lita på att resultaten har

blivit rättvist gjorda eftersom koden inte gömmer sig bakom ett programs skal, utan koden

finns att se och för bruk. Vilket betyder att även om inte testapplikationerna må ha något

tekniskt fel så har de i alla fall blivit testade på samma villkor. Testapplikationen kan också

vara helt korrekt och spikarna kan bero på något helt annat, det är inte troligt att det är

testapplikationen som det är fel, men möjligheten finns alltid.

All kod och funktioner som har blivit modifierade samt testningsapplikationerna finns med i

den här rapporten finns tillgängligt som appendix för att hålla arbetet forskningsetiskt.

Angående hur det här arbetet kan hjälpa till med samhällsnytta är att andra programmerare

som är intresserade av att använda sig av procedurer i ett CMS, inte nödvändigtvis

Wordpress, kan titta på det här arbetet och få inspiration och hjälp. Det kan hjälpa de som är

intresserade i ämnet insikt i frågan ifall procedurer faktiskt kan förbättra ett system på

webben. Det här arbetet har en möjlighet att ge insikt i ämnet från ett annat perspektiv än

Cheung et al.( 2012) undersökning som istället för att fokusera sig på webben använde sig av

en Java plattform.

7.1 Framtida arbete

För framtida arbeten går det att undersöka ifall resultaten kan bli bättre ifall databasservern

och webbsidan befinner på olika datorer. Om en administratör som driver en trafikerad sida

och har webbsidan och databasen på olika servrar för att separera belastningen, kan det vara

intressant att använda sig av stored procedures i sitt system för att experimentera ifall

exekveringstiderna kan förbättras.

Kan vara intressant att undersöka ifall det finns andra CMS ifall det går snabbare att mata in

poster och kommentarer i dem för att se ifall de lika resultaten ligger i Wordpress

kodstruktur.

Det finns även andra funktionaliteter som det går potentiellt sett att använda procedurer i.

Alla funktioner som använder sig av något slags databasanrop i klienten, hade det gått att

byta ut till en procedur som befinner sig i databasen. Det här går inte bara för Wordpress

21

utan det går att utnyttja i alla CMS så länge det finns databasanrop från webbapplikationen.

Det hade till exempel fungerat att byta ut sökfunktionen i ett CMS mot proceduranrop.

Ett långsiktig framtida arbete är att försöka återskapa de bra tiderna som förekommer

relativt sällan i procedur versionerna av Wordpress. Observera vad det är som gör att

procedurerna får bra tider och vad som gör att de får dåliga, eliminera det som gör att

tiderna spikar och försöka göra så att det blir bra exekveringstider hela konsistent.

22

Referenser

Apache Software Foundation (2013) 2013. Apache JMeter. Tillgänglig på Internet:

http://jmeter.apache.org/ [Hämtad Februari 20, 2014].

Baohua, T. & Ling, Z. (2010) A performance optimization based on stored procedure in RDBS

project. Computer and Communication Technologies in Agriculture Engineering (CCTAE),

2010 International Conference On. Juni s. 594–597.

Cai, J.-Y., Nerurkar, A. & Wu, M.-Y. (1998) Making benchmarks uncheatable. Computer

Performance and Dependability Symposium, 1998. IPDS ’98. Proceedings. IEEE

International. September s. 216–226.

Cheung, A., Arden, O., Madden, S. & Myers, A.C. (2013) Speeding Up Database Applications

with Pyxis. Proceedings of the 2013 ACM SIGMOD International Conference on

Management of Data. SIGMOD ’13. New York, NY, USA, ACM. s. 969–972.

Cheung, A., Madden, S., Arden, O. & Myers, A.C. (2012) Automatic Partitioning of Database

Applications. Proc. VLDB Endow. 5 (11), s. 1471–1482.

Koponen, T. & Hotti, V. (2005) Open Source Software Maintenance Process Framework.

Proceedings of the Fifth Workshop on Open Source Software Engineering. 5-WOSSE. New

York, NY, USA, ACM. s. 1–5.

Li, Y. & Manoharan, S. (2013) A performance comparison of SQL and NoSQL databases. 2013

IEEE Pacific Rim Conference on Communications, Computers and Signal Processing

(PACRIM). August s. 15–19.

Microsoft (2014) 2014. SQL Stored Procedures. Tillgänglig på Internet:

http://technet.microsoft.com/en-us/library/aa174792(v=sql.80).aspx [Hämtad Mars 18, 2014].

Paton, N.W. & Díaz, O. (1999) Active Database Systems. ACM Comput. Surv. 31 (1), s. 63–103.

Saavedra, R.H. & Smith, A.J. (1996) Analysis of Benchmark Characteristics and Benchmark

Performance Prediction. ACM Trans. Comput. Syst. 14 (4), s. 344–384.

Sharma, P.N.A. & Kurhekar, D.P.P. (2013) Content Management System. International Journal

of Innovative Research and Development. 2 (12).

Souer, J. & Joor, D.-J. (2010) An Approach to Identify Commonalities in Web Application

Engineering for a Web Content Management System. Proceedings of the 12th International

Conference on Information Integration and Web-based Applications & Services. iiWAS

’10. New York, NY, USA, ACM. s. 558–565.

Vicknair, C., Wilkins, D. & Chen, Y. (2012) MySQL and the Trouble with Temporal Data.

Proceedings of the 50th Annual Southeast Regional Conference. ACM-SE ’12. New York,

NY, USA, ACM. s. 176–181.

Wordpress (2014) 2014. Tillgänglig på Internet: http://wordpress.org/ [Hämtad Mars 19, 2014].

Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., et al. (2000) Experimentation in Software

Engineering: An Introduction. Norwell, MA, USA, Kluwer Academic Publishers.

23

Appendix A - Wp-db.php – Kommentar Wordpress

function _insert_replace_helper( $table, $commentdata) {

$comment_post_ID = $commentdata['comment_post_ID'];

$comment_author = $commentdata['comment_author'];

$comment_author_email = $commentdata['comment_author_email'];

$comment_author_url = $commentdata['comment_author_url'];

$comment_author_IP = $commentdata['comment_author_IP'];

$comment_date = $commentdata['comment_date'];

$comment_date_gmt = $commentdata['comment_date_gmt'];

$comment_content = $commentdata['comment_content'];

$comment_karma = 0;//karma är depricated.

$comment_approved = $commentdata['comment_approved'];

$comment_agent = $commentdata['comment_agent'];

$comment_type = $commentdata['comment_type'];

$comment_parent = $commentdata['comment_parent'];

$user_id = $commentdata['user_id'];

$sql = "CALL CommentsProcedure('$comment_post_ID', '$comment_author',

'$comment_author_email', '$comment_author_url', '$comment_author_IP', '$comment_date',

'$comment_date_gmt', '$comment_content', '$comment_karma', '$comment_approved', '$comment_agent',

'$comment_type', '$comment_parent', '$user_id')";

return $this->query( $this->prepare( $sql, $commentdata ) );

}

function insert( $table, $commentdata) {

return $this->_insert_replace_helper( $table, /*$data, $type_of_table,*/ $commentdata/*,

$format, 'INSERT'*/ );

}

24

Appendix B - Comment.php

function wp_insert_comment($commentdata) {

global $wpdb;

extract(wp_unslash($commentdata), EXTR_SKIP);

if ( ! isset($comment_author_IP) )

$comment_author_IP = '';

if ( ! isset($comment_date) )

$comment_date = current_time('mysql');

if ( ! isset($comment_date_gmt) )

$comment_date_gmt = get_gmt_from_date($comment_date);

if ( ! isset($comment_parent) )

$comment_parent = 0;

if ( ! isset($comment_approved) )

$comment_approved = 1;

if ( ! isset($comment_karma) )

$comment_karma = 0;

if ( ! isset($user_id) )

$user_id = 0;

if ( ! isset($comment_type) )

$comment_type = '';

$wpdb->insert($wpdb->comments, $commentdata);

$id = (int) $wpdb->insert_id;

if ( $comment_approved == 1 )

wp_update_comment_count($comment_post_ID);

$comment = get_comment($id);

25

do_action( 'wp_insert_comment', $id, $comment );

wp_cache_set( 'last_changed', microtime(), 'comment' );

return $id;

}

26

Appendix C - Original Wordpress testapplikation för kommentarer

<?php

include("ncfg/ContextFreeGrammar.php");





global $wpdb;

/*$table = "";

if (isset($_GET['hello'])) {

add_comments();

}*/

function microtime_float()

{

list($usec, $sec) = explode(" ", microtime());

return ((float)$usec + (float)$sec);

}

$time_start = microtime_float();

for($j=0; $j<500; $j++){ //antal kommentarer

$title = generate_sentence(0.5,0.5,0.5,0.5,0,0,0,0,0,0,0);

$text = "";

for($i=0; $i<5; $i++){//antal rader på varje kommentar

$sentence = generate_sentence(0.5,0.5,0.5,0.5,0,0,0,0,0,0,0);

$sentence = ucfirst(trim($sentence)).". ";

27

$text = $text.$sentence;//plussar ihop grabbarna

}

$body = $text;

$table = "comments";

$data = array(

"comment_post_ID" => 1,

"comment_author" => "Simon Berg",

"comment_author_email" => "[email protected]",

"comment_author_url" => "www.arla.se",

"comment_author_IP" => "127.0.0.1",

"comment_date" => "",

"comment_date_gmt" => "",

"comment_content" => $body,

"comment_approved" => 1,

"comment_agent" => "",

"comment_type" => "",

"comment_parent" => "",

"user_ID" => 0

);

$wpdb->insert($wpdb->comments, $data);

}

$time_end = microtime_float();

$time = $time_end - $time_start;

echo "Det tog: $time tid.";

?>

29

Appendix D - Procedur Wordpress kommentar testapplikation

<?php






global $wpdb;


{



}




$text = "";





30

}

$body = $text;

$table = "";

$commentdata = array(

"comment_post_ID" => 1,

"comment_author" => "Simon Berg",

"comment_author_email" => "[email protected]",

"comment_author_url" => "www.arla.se",

"comment_author_IP" => "127.0.0.1",

"comment_date" => "",

"comment_date_gmt" => "",

"comment_content" => $body,

"comment_approved" => 1,

"comment_agent" => "",

"comment_type" => "",

"comment_parent" => "",

"user_ID" => 0

);

$wpdb->_insert_replace_helper($table, $commentdata);

}




?>

31

Appendix E - Kommentar procedur

DELIMITER $$

CREATE PROCEDURE `CommentsProcedure`(IN comment_post_ID bigint(20), IN comment_author

tinytext, IN comment_author_email VARCHAR(100), IN comment_author_url VARCHAR(200), IN

comment_author_IP VARCHAR(100), IN comment_date datetime, IN comment_date_gmt datetime, IN

comment_content text,

IN comment_karma int(11), IN comment_approved VARCHAR(20), IN comment_agent VARCHAR(255),

IN comment_type VARCHAR(20), IN comment_parent bigint(20), IN user_ID bigint(20))

BEGIN

INSERT INTO wp_comments(comment_post_ID, comment_author, comment_author_email,

comment_author_url, comment_author_IP, comment_date, comment_date_gmt, comment_content,

comment_karma, comment_approved, comment_agent, comment_type, comment_parent, user_id)

VALUES(comment_post_ID, comment_author, comment_author_email, comment_author_url,

comment_author_IP, comment_date, comment_date_gmt, comment_content, comment_karma,

comment_approved, comment_agent, comment_type, comment_parent, user_id);

END

$$

DELIMITER ;

32

Appendix F - Post procedur

DELIMITER //

CREATE PROCEDURE `PostsProcedure`(IN post_author bigint(20), IN post_date datetime, IN

post_date_gmt datetime, IN post_content longtext, IN post_title text, IN post_excerpt text, IN post_status

varchar(20), IN comment_status varchar(20), IN ping_status varchar(20), IN post_password varchar(20),

IN post_name varchar(200), IN to_ping text, IN pinged text, IN post_content_filtered longtext, IN

post_parent bigint(20), IN guid varchar(255), IN menu_order int(11), IN post_type varchar(20), IN

post_mime_type varchar(100), IN comment_count bigint(20))

BEGIN

INSERT INTO wpp_posts(post_author, post_date, post_date_gmt, post_content, post_title,

post_excerpt, post_status, comment_status, ping_status, post_password, post_name, to_ping, pinged,

post_content_filtered, post_parent, guid, menu_order, post_type, post_mime_type, comment_count)

VALUES(post_author, post_date, post_date_gmt, post_content, post_title, post_excerpt,

post_status, comment_status, ping_status, post_password, post_name, to_ping, pinged,

post_content_filtered, post_parent, guid, menu_order, post_type, post_mime_type, comment_count);

END

//

DELIMITER ;

33

Appendix G - Post.php Original Wordpress testapplikation för poster

<?php






global $wpdb;


{



}




$text = "";





}

$body = $text;

34

$table = "comments";

$data = array(

"post_author" => 1,

"post_date" => "",

"post_date_gmt" => "",

"post_content" => $body,

"post_title" => "titel",

"post_excerpt" => "",

"post_status" => "publish",

"comment_status" => "open",

"ping_status" => "open",

"post_password" => "",

"post_name" => "Hello",

"to_ping" => "",

"pinged" => "",

"post_content_filtered" => "",

"post_parent" => "",

"guid" => "",

"menu_order" => "",

"post_type" => "post",

"post_mime_type" => "",

"comment_count" => ""

);

$wpdb->insert($wpdb->posts, $data);

}



echo "Det tog: $time tid.";?>

35

Appendix H - Wpdb.php Post procedur versionen

function _insert_replace_helper( $table, $data, $format = null, $type = 'INSERT' ) {

$post_author = $data['post_author'];

$post_content = $data['post_content'];

$post_date = $data['post_date'];

$post_date_gmt = $data['post_date_gmt'];

$post_content_filtered = $data['post_content_filtered'];

$post_title = $data['post_title'];

$post_excerpt = $data['post_excerpt'];

$post_status = $data['post_status'];

$post_type = $data['post_type'];

$comment_type = $data['comment_type'];

$comment_status = $data['comment_status'];

$ping_status = $data['ping_status'];

$post_password = $data['post_password'];

$post_name = $data['post_name'];

$to_ping = $data['to_ping'];

$pinged = $data['pinged'];

$post_parent = $data['post_parent'];

$menu_order = $data['menu_order'];

$post_mime_type = $data['post_mime_type'];

$guid = $data['guid'];

$sql = "CALL PostsProcedure( '$post_author', '$post_date',

'$post_date_gmt', '$post_content', '$post_title', '$post_excerpt', '$post_status', '$comment_status',

'$ping_status', '$post_password', '$post_name', '$to_ping', '$pinged', '$post_content_filtered',

'$post_parent', '$guid', '$menu_order', '$post_type', '$post_mime_type', '$comment_count')";

return $this->query( $this->prepare( $sql, $data ) );}

36

Appendix I - Post procedur testapplikation

<?php






global $wpdb;


{



}




$text = "";





}

$body = $text;

37

//$table = "";

$data = array(

"post_author" => 1,

"post_date" => "",

"post_date_gmt" => "",

"post_content" => $body,

"post_title" => "titel",

"post_excerpt" => "",

"post_status" => "publish",

"comment_status" => "open",

"ping_status" => "open",

"post_password" => "",

"post_name" => "Hello",

"to_ping" => "",

"pinged" => "",

"post_content_filtered" => "",

"post_parent" => "",

"guid" => "",

"menu_order" => "",

"post_type" => "post",

"post_mime_type" => "",

"comment_count" => ""

);

$wpdb->_insert_replace_helper($table, $data, $format, $type);

}




?>

stored procedures i en cms miljÖ stored...

Documents