EE345 project sample.pdf

download EE345 project sample.pdf

of 14

Transcript of EE345 project sample.pdf

  • 8/10/2019 EE345 project sample.pdf

    1/14

    EE345AModeling and Simulation

    Final Project:Web Server Simulation

  • 8/10/2019 EE345 project sample.pdf

    2/14

    1. The SimulationThe system to be modeled is a web and database server combination that comprises one of my other software

    projects. This project is to create a file sharing system using distributed servlets to disseminate content. The centralservers fulfill search and browse requests and present the user with an interface to navigate content.

    The goal of this simulation is to determine the maximum load, in users.

    2. The Real SystemThe real system consists of a web server running scripts that access a database containing items, folders, and

    other information. These scripts format and present data to users, and these scripts also send redirection URLs fordownloading and streaming from individual servlets. This servlets sit at the periphery of the system and serveindividual items after redirection. Once redirection is complete, the central server is uninvolved.

    There is also a back end server that communicates directly with the database server transmitting items to beindexed. This server only transmits information when changes occur in the items a servlet shares.

    3. The Problem

    The system is very complicated. The amount of time necessary to fulfill any individual request is dependanton the amount of content stored. The amount of content stored is dependant on the number of users and theirindividual content. Furthermore, the load on the system is distributed between the processor for tasks such asformatting and sorting and the hard disk for tasks such as searching the database.

    Either the hard disk activity or the processor activity will be the limiting factor, and this simulation is hopedwill find out which one is.

    4. The ModelTo model this system, the database server must be modeled to a high degree of detail. To accomplish this, I

    intend to model the database server as multiple servers that respond to various requests by analyzing a cache andutilizing a single disk server to serve requests not cached. This model is detailed enough to reveal behavior in the

    system while keeping it realistically simple.The database servers are fed by two servers: the parallel web servers working directly with user requests, and

    the parallel back end servers feeding the database new information. These each have independent queues and arefed by independent sources, as each is governed by a different process.

    The database servers are queued through a read/write locking queue. This queue allows mutually exclusiveaccess to read and write database servers, with priority for writes. That is, if a write is pending, no reads can occuruntil all writes complete. While work is waiting, queues hold the requests until they can be processed.

    The database servers communicate via a single queue with a single storage server that models drive access.The database servers communicate with a single static cache controller to model memory access of cache rows andkeys.

    See below in section 8.

    5. The Data After considering the data for interarrival timings for various events, it was determined almost all input to this

    system follows complicated patterns and requires empirical data to function best. All interactive input processesconsist of a period of interactive use with very short interarrival timings then experience a large and highly variabledelay until another batch of requests occurs.

    The interarrival time function must take into account these two behaviors. This is done by choosing anempirical distribution with appropriate cumulative distribution function. An empirical CDF is found from actual

  • 8/10/2019 EE345 project sample.pdf

    3/14

    interarrival data for various classes of events for 0 to 86400 seconds. This fragment is joined piecewise to anapproximated exponential CDF fragment that covers all outliers of the actual dataset and this composite CDF as asingle function is used to determine interarrival times by inverse transform.

    The following data were collected to be used in the model: Download requests interarrival times Browse requests interarrival times Search requests interarrival times Back end data interarrival times Back end data counts Back end data delta counts Folder subfolder counts Folder item counts Folder cache status statistics Cache retrieval time Per item cache miss penalty Download request time Search request time Search result count Search word count

    Most data was analyzed using MATLAB. Scripts were created to construct histograms of the source datausing appropriate bins. The resulting histogram was used to directly construct a CDF for the input process asdescribed in the text by Banks. Due to variability in user behavior, a set of CDFs was constructed for manycommon input processes, each based on a specific real user. Random CDFs are uniformly selected and used as inputfor each of the users simulated.

    The MATLAB scripts used are attached. Two functions, cdf.m and ecdf.m, were used to create the CDFs.Other scripts invoked by the main script batch.m are used to create all data at once. Writecdf.m was used to outputthese in a format readable by the simulation.

    The CDF script works primarily by creating a histogram of appropriate bins. Other scripts are self-explanatory. The source data and all scripts used are included in the directory Data.

    Graphs of various CDFs are shown below.

  • 8/10/2019 EE345 project sample.pdf

    4/14

    0 100 200 300 400 500 6000

    0.1

    0.2

    0.3

    0.4

    0.5

    0.6

    0.7

    0.8

    0.9

    Time (seconds)

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

    Various CDFs of Download Request Interarrival Times

    0 100 200 300 400 500 6000

    0.1

    0.2

    0.3

    0.4

    0.5

    0.6

    0.7

    0.8

    0.9Various CDFs of Browse Request Interarrival Times

    Time (seconds)

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

  • 8/10/2019 EE345 project sample.pdf

    5/14

    0 100 200 300 400 500 6000

    0.05

    0.1

    0.15

    0.2

    0.25Various CDFs of Search Request Interarrival Times

    Time (seconds)

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

    For these data, it is clear that wide variability is present. Again, this is accommodated by using sets of

    empirical data collected from users as the inputs to the system.

    0 10 20 30 40 50 60 70 80 900

    0.1

    0.2

    0.3

    0.4

    0.5

    0.6

    0.7

    0.8

    0.9

    1Various CDFs of Check-in Request Interarrival Times

    Time (seconds)

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

  • 8/10/2019 EE345 project sample.pdf

    6/14

    0 50 100 150 200 250 300 350 4000

    0.1

    0.2

    0.3

    0.4

    0.5

    0.6

    0.7

    0.8

    0.9

    1Various CDFs of Check-in Request Item Counts

    Time (seconds)

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

    For these data, it is clear that a wide margin of time intervals and item counts exist in terms of requests

    submitted to the back end server.

    Single CDF functions were also created for some input processes, shown below:

    0 0.005 0.01 0.015 0.020

    0.1

    0.2

    0.3

    0.4

    0.5

    0.6

    0.7

    0.8

    0.9

    1

    Time (seconds per item)

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

    CDF of Per Item Browse Time

  • 8/10/2019 EE345 project sample.pdf

    7/14

    0 0.5 1 1.5 2 2.5 3

    x 104

    0

    0.1

    0.2

    0.3

    0.4

    0.5

    0.6

    0.7

    0.8

    0.9

    1CDF of Per User Item Counts

    Time (items per user)

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

    0 0.005 0.01 0.015 0.020

    0.1

    0.2

    0.3

    0.4

    0.5

    0.6

    0.7

    0.8

    0.9

    1

    Time (seconds per item)

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

    CDF of Per Item Search Time

  • 8/10/2019 EE345 project sample.pdf

    8/14

    0 20 40 60 80 100 1200

    0.1

    0.2

    0.3

    0.4

    0.5

    0.6

    0.7

    0.8

    0.9

    1CDF of Search Result Counts

    Items

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

    0 50 100 150 200 250 300 350 4000

    0.1

    0.2

    0.3

    0.4

    0.5

    0.6

    0.7

    0.8

    0.9

    1

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

    Items

    CDF of Folder Sub-Item Counts

  • 8/10/2019 EE345 project sample.pdf

    9/14

    0 500 1000 1500 2000 2500 3000 3500 40000

    0.1

    0.2

    0.3

    0.4

    0.5

    0.6

    0.7

    0.8

    0.9

    1

    Items

    C u m u

    l a t i v e

    P r o

    b a

    b i l i t y

    CDF of Folder Sub-Folder Counts

    of these functions plays a large role in determining the input to the system. For instan

    DF clearly shows that about 35% of the searches return close to 100 results (the limit). ThDF shows that most folders are small and contain few items. All these characteristics ar

    ce in the simulation. Empirical CDFs are important in creating this simulation.

    orkulation is to be written in C++. To facilitate creation of this complex model, a fram

    is is a generic set of template classes that form a foundation for simulation. The basiow:

    The basic work unit is a Request. Each request contains all the attributes necessary to proceses as string pairs. The Request class contains a string to string map and accessor functions t

    Requests are passed from server to server to fulfill user requests.ogical object in the system is an Actor. The Actor class is the base class for almost all objects.

    the base for request flow, it is necessary to connect actors together at the framework level. and sinks. Each actor is linked to a source from which it can pull Requests and a Sink

    Requests. Each Actor is capable of operating either in push mode (using sources) or pulls is done so any actor may push the completed Request downstream once processing is com

    pull a new Request from upstream, preventing the need to poll or have complicated relons. The generic interface makes any graph possible as long as the push/pull sema

    The actual actor pull/push interface is effected using the polymorphic functions Give and Take iefault action is simply to propagate the Give or Take call upstream or downstream usin

    Each ce, the searchresult count C e subfolderitem counts C e important toreprodu

    6. The FramewThis sim ework was

    needed. Th c operation isdescribed bel

    s it and carriesthis attribut o get and set

    pairs of data.Each l Since

    actors form This is doneusing sources to which itcan push mode (usingsources). Thi pleted andsubsequently ationships

    between functi ntics are adheredto.

    n the baseclass. The d he actorssource or sink set with SetSource and SetSink.

    g t

  • 8/10/2019 EE345 project sample.pdf

    10/14

  • 8/10/2019 EE345 project sample.pdf

    11/14

    processing. This class is only derived to collect statistics and to end the simulation after 1000 requests. If statisticswere not important, neither SampleQueue nor SampleSink would be needed.

    The flow of requests is linear from Source to Queue to Server to Sink. The SampleSimulation classconstructs this graph using Actor::ConnectChain to set appropriate sinks and sources. The following graphic showsexactly how the objects interact:

    RunSample instantiates a SampleSimulation object and calls Run(). Then it prints applicable statistics andquits.

    To turn this into a multi-server queue, all that is needed is to replace SampleServers base class withMultiServer and adjust some of the statistics code. In this fashion, the framework is extremely

    8

    o respective servers.

    itted to that server and waited upon.Each

    eue which feeds a MultiServer that governs back end requests in the

    same fashion as MultiServer. The same principle is used to convert requests to database activity.Finish

    Both WebServer and BackServer instances must share cpu time across the entire simulation. This iseffecte

    e database server is modeled as a node leading to a ReadWriteQueue leading to actual server objects. Thisqueue to aMultiServer and write requests to a single DbServer. These DbServer objects send access requests to a

    rough a queue which serializes database access requests modeling the action of disk activity. A

    flexible.Getting the single server queue operating provided a test bed for creating the larger project simulation.

    . The DetailsWebSource is the source for web requests and generates requests for all users. This class injects requests

    based on empirical CDFs for each simulated user. BackSource is the source for back end requests and generates

    requests for all users as well. Both of these communicate through queues tSince both WebServer and BackServer need to communicate with the database server, a request/response

    mechanism was needed. ServerDbUser provides the framework for this. ServerDbUser::DbBegin, called fromBegin, starts the process of sending requests to the database server that were put in the dbRequests list. These arereturned to the ServerDbUser::ReplySink object once they complete, and once these all complete, the serverexecutes a delay specified by executionTime then calls a Done/Fetch/Begin sequence to complete the transaction.

    WebSource feeds a queue which feeds a MultiServer that governs web requests. This server breaks down request types to a number of database queries which are subm

    class of request is mapped to a database request depending on request and values of statistic indicatorsdescribed above in the Data section of this report. Once completed, the requests are sent to sinks.

    BackSource also feeds a qu

    ed requests are sent to a sink.

    d by using a Scheduler class whose GetTime function allocates blocks of time and returns the end time of processing. This models a cpu of a single system.

    Th creates the read/write locking model of database servers and passes read requests

    DbStorage server thcache in the DbServer created using the DbServer::CacheController class models a row/key cache in the databaseserver.

    In all cases where subrequests are generated and sent, a return Actor method is used. An actor is createdcalled a ReplySink that receives subrequests back from the server that processed them. This is done by passing avalue in the request called return-actor with the hex representation of the actors address. Helper functionsconvert these. ReplySink just sends the request to its owner as a Reply call, allowing subrequests to be processed.

    The following graphic shows exactly how the objects interact:

  • 8/10/2019 EE345 project sample.pdf

    12/14

    9

    10

    per hour. Once this was established, the simulation was run with varying user counts until the DbServer(drive

    User Count: 50

    DbStorage::Utilization = 2.991012= 0.049921

    gth = 0

    er: drivezation: 0%

    inear user limit: 60189

    ear user limit. This value is the number of users attainable if the performance

    per us omputed as userCount * (1 / limiting utilization). It is an estimator for the next round ofsimula

    11. Eincreased until a saturation of drive or cpu access was

    reache time, 60 seconds was used for the simulation time. The startingvalue proximate range was reached. Most statistics are omitted

    . Verification of the Model and SimulationAfter coding the simulation, many bugs were removed. Several graph errors were found relating to incorrect

    graph creation leading to breaks in the source/sink paths and errors related to placement of queues. Requests were being dropped at the DbStorage server due to a lack of a queue before this server. This is because servers do notqueue requests, just indicate they were not accepted.

    Once created, the remainder of the development energy went into validating the model through input data.

    . Validation of the ModelThe first attempt at running the model resulted in slowdowns and errors related to bad data and excessive

    input. Once these issues were resolved, the internal parameters were tuned to result in a load on the simulated driveand cpu similar to daily use of the current user pool. A 50 user pool was simulated and the primary indicators werethe number of requests received by the WebServer. Numbers for hourly actual use fall in the range of 1-4 dozenrequests

    ) or Scheduler (cpu) was saturated. One of those two conditions indicates full usage of the system (ie. itsmaximum load in users.)

    Output for 3600 seconds, 50 users:Loading dataBuilding graph

    WebServer Count: 16Starting simulationStatistics:

    BackServer::AvgCheckinRows = 65.088516BackServer::AvgLoginRows = 149.720000BackServer::CheckinRequests = 3457BackServer::LoginRequests = 50DbServer::CacheHits = 1163DbServer::TableRows::items = 44130DbStorage::Requests = 3426

    Scheduler::Utilization

    StatQueue(Back)::MaxLen StatQueue(Storage)::MaxLength = 1StatQueue(Web)::MaxLength = 0WebServer::BrowseRequests = 64WebServer::CachedBrowse = 23WebServer::DownloadRequests = 33WebServer::SearchRequests = 13

    Simulation length: 3600.521167Simulation runtime: 4Drive utilization: 0.000831CPU utilization: 0.000014Performance limit

    imiting utiliLL The last line indicates the lin

    er were linear. It is ction.

    xperimentOnce the simulation was created, the user count wasd. To make the simulation run in reasonableof 50 used for validation, was increased until an ap

  • 8/10/2019 EE345 project sample.pdf

    13/14

    from t ull in the file trials.txt. The following table provides anovervi

    or LinearEstimator

    SimulationRuntime

    SimulationLength

    rive 8433 1 60

    Drive 17563 0 600% Drive 17563 1 605% Drive 1989 3 603% Drive 2922 2 605% Drive 1983 4 605% Drive 3797 4 60

    8 200 6% Drive 3371 5 60

    12 400 24% Drive 1661 26 6013 600 36% Drive 1668 31 6014 600 18% Drive 3325 16 6015 600 43% Drive 1409 39 60

    1000 70% Drive 1711 76 601200 69% Drive 1737 89 60

    23 1200 77% Drive 1556 89 6024 1200 69% Drive 1727 85 6025 1400 100% Drive 1400 296 6026 1400 100% Drive 1400 253 6027 1400 82% Drive 1714 130 6028 1600 100% Drive 1600 331 6029 1600 70% Drive 2298 117 6030 1600 92% Drive 1743 199 6031 1800 100% Drive 1800 344 6032 1800 88% Drive 2038 172 6033 1800 100% Drive 1800 295 6034 2000 100% Drive 2000 520 6035 2000 100% Drive 2000 400 6036 2000 100% Drive 2000 646 60

    his report for each iteration but are included in f ew of simulation results:

    Trial Count Utilization factUser Limiting Limiting

    1 50 1% D

    2 50 0%3 504 1005 1006 1007 200

    9 200 12% Drive 1702 9 6010 400 20% Drive 1984 17 6011 400 21% Drive 1925 17 60

    16 800 40% Drive 1995 38 60

    17 800 58% Drive 1386 51 6018 800 33% Drive 2461 28 6019 1000 31% Drive 3234 28 6020 1000 86% Drive 1166 164 602122

    As can be seen, the maximum user limit is attained at 2000 users with all simulation runs at this user countutilizing 100% of resources, while the first run to limit resources was 1400 users. The linear estimator is not capableof detecting the increase in items that accompanies increasing in users and thus falls until it approaches and settles atthe actual user limitation.

  • 8/10/2019 EE345 project sample.pdf

    14/14

    The following graph shows the utilization vs. user count:

    Limiting Utilization vs . User Count for All Trials

    0%

    10%

    20%

    30%

    40%

    50%

    60%

    70%

    80%

    90%

    100%

    0 500 1000 1500 2000 2500

    User Count

    L i m i t i n g

    U t i l i z a

    t i o n

    Unexpectedly, the curve of utilization vs. user count is somewhat linear. It can be seen that the limitingutilizations grow in variance as the number of users (and thus input variance to the system) increases. Looking at

    the graph it is clear that a limiting number of users is approximately 1400 for worst case and 2000 for best caseconditions. Average case limiting user count can be considered the average, 1700.

    on two parallel computer servers, which according to the results would suggest doublingthe pe rmance due to the database being the limiting factor in all cases. Other parameters of the system could also

    be investigated using this framework.

    12. ConclusionsThis simulation has been used to determine the maximum user load of about 1700 users, but due to the

    flexible framework it is implemented upon, it is possible to analyze other situations as well, such as the impact ofload sharing the database

    rfo