geo2tag performance evaluation, zaslavsky, krinkin
DESCRIPTION
TRANSCRIPT
![Page 1: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/1.jpg)
Geo2Tag performance evaluation
Mark Zaslavskiy, Kirill KrinkinFRUCT LETI Lab,Open Source & Linux Lab
FRUCT12, Oulu, November, 2012
![Page 2: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/2.jpg)
Motivation
● Geo2Tag LocationBased Services platform was started as project for students who want to get an Open Source development experience
● With increasing number of functions which are supported by platform performance requirements also increased
● Platform performance evaluation was never performed
2
![Page 3: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/3.jpg)
Goals
● Investigate the most frequent REST requests to platform performed by users;
● Measure performance (processing time) of the most frequent requests;
● Determine bottlenecks in request processing;● Maximize performance of request processing
and DB synchronization;
3
![Page 4: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/4.jpg)
Platform architecture
4
PlatformPlatform Interface
Control program
DB
Internet
HTTP/JSON
Lighttpd
FastCGI
qSQL
PostgreSQL
Interaction with the database
Request processing
![Page 5: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/5.jpg)
Clientserver interaction modeling
● The most frequent REST requests were found using modeling of LocationClient app behavior
● Modeling was performed using Markov chains theory
● Request executions were used as nonabsorbing states of Markov chain
● Client application shutting down was used as absorbing state of Markov chain
5
![Page 6: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/6.jpg)
Clientserver interaction modeling
● During numerical experiments average number of each request executions before absorbtion were calculated
● Modeling was performed for different initial states and tagging frequency
● As a result of modeling WriteTag and LoadTags requests had the biggest average number of executions for all conditions
6
![Page 7: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/7.jpg)
Control program profiling
7
● For determining bottlenecks during request processing profiling performed
● For each write request whole processing time and DB interaction time were measured
● In average DB interaction takes ~95% of request processing time
● DB interaction is bottleneck!
![Page 8: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/8.jpg)
Control program profiling
8
![Page 9: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/9.jpg)
Platform optimizations
9
● DB synchronization optimizations:– Thread synchronization refactoring (less
locks – more performance)– Algorithm for making decisions about
need of DB synchronization ● DB structure optimization
– Number of tables for tags storage were decreased to one – WriteTag processing speed increased
![Page 10: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/10.jpg)
DB synchronization
10
● Algorithm which determines does system need DB synchronization or not
– Periodical check with userdefined period (UPDATE_INTERVAL)
– Comparison between actual number of transactions to DB and transactions number counted by platform
– If difference is more than TRANSACTION_DIFF value than synchronization is performed, else nothing happens
– Variation of UPDATE_INTERVAL and TRANSACTION_DIFF allows to achieve different ratios “performance/data consistency”
![Page 11: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/11.jpg)
Request performance measurement
11
● Performance were measured for WriteTag and LoadTag requests in system before and after optimization
● Processing time and errors data were collected● For LoadTag set of experiments were performed with
different number of tags in DB – from 0 to 54000 with step of 1000 tags. For each tag value 10000 LoadTags requests where performed
● For WriteTag performance measurement was performed as sequentially increase of tags number in system from 0 to 12000 by sending WriteTag request
![Page 12: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/12.jpg)
Results comparison
12
● Maximum, minimum, average, variance of request processing time and number of errors where compared for both systems
● LoadTags– Maximum processing time decreased
● WriteTag– Average time decreased by 47.5%– Maximum time decreased tenfold– Variance of time decreased hundredfold
![Page 13: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/13.jpg)
Conclusions
13
● During performance evaluation where achieved next results:
– Math model of client application was created– Bottleneck of request processing was found– Performance of request processing was
optimized● Future plans:
– Support NoSQL or GISoriented DB– Support lockfree algorithms and data
structures
![Page 14: Geo2tag performance evaluation, Zaslavsky, Krinkin](https://reader034.vdocuments.us/reader034/viewer/2022051312/546458f8af795997368b483c/html5/thumbnails/14.jpg)
Questions & Answers
Mark Zaslavskiy, Kirill Krinkin{mark.zaslavskiy, kirill.krinkin}@gmail.comOpen Source & Linux Lab, http://osll.furct.org, [email protected]