Links to Exploration step
Le document en format XML
<record><TEI><teiHeader><fileDesc><titleStmt><title xml:lang="en">The cloud paradigm applied to e-Health</title><author><name sortKey="Vilaplana, Jordi" sort="Vilaplana, Jordi" uniqKey="Vilaplana J" first="Jordi" last="Vilaplana">Jordi Vilaplana</name><affiliation><nlm:aff id="I1">Computer Science Department, University of Lleida, Jaume II 69, Lleida, 25001, Spain</nlm:aff></affiliation></author><author><name sortKey="Solsona, Francesc" sort="Solsona, Francesc" uniqKey="Solsona F" first="Francesc" last="Solsona">Francesc Solsona</name><affiliation><nlm:aff id="I1">Computer Science Department, University of Lleida, Jaume II 69, Lleida, 25001, Spain</nlm:aff></affiliation></author><author><name sortKey="Filgueira, Rosa" sort="Filgueira, Rosa" uniqKey="Filgueira R" first="Rosa" last="Filgueira">Rosa Filgueira</name><affiliation><nlm:aff id="I3">Edinburgh Data-Intensive Research Group, School of Informatics, The University of Edinburgh, Edinburgh, UK</nlm:aff></affiliation></author><author><name sortKey="Rius, Josep" sort="Rius, Josep" uniqKey="Rius J" first="Josep" last="Rius">Josep Rius</name><affiliation><nlm:aff id="I4">ICG Software, Pol. Industrial Torrefarrera C. Mestral, , s/n 25123 Torrefarrera, Lleida, Spain</nlm:aff></affiliation></author></titleStmt><publicationStmt><idno type="wicri:source">PMC</idno><idno type="pmid">23496912</idno><idno type="pmc">3618213</idno><idno type="url">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3618213</idno><idno type="RBID">PMC:3618213</idno><idno type="doi">10.1186/1472-6947-13-35</idno><date when="2013">2013</date><idno type="wicri:Area/Pmc/Corpus">000334</idno><idno type="wicri:explorRef" wicri:stream="Pmc" wicri:step="Corpus" wicri:corpus="PMC">000334</idno></publicationStmt><sourceDesc><biblStruct><analytic><title xml:lang="en" level="a" type="main">The cloud paradigm applied to e-Health</title><author><name sortKey="Vilaplana, Jordi" sort="Vilaplana, Jordi" uniqKey="Vilaplana J" first="Jordi" last="Vilaplana">Jordi Vilaplana</name><affiliation><nlm:aff id="I1">Computer Science Department, University of Lleida, Jaume II 69, Lleida, 25001, Spain</nlm:aff></affiliation></author><author><name sortKey="Solsona, Francesc" sort="Solsona, Francesc" uniqKey="Solsona F" first="Francesc" last="Solsona">Francesc Solsona</name><affiliation><nlm:aff id="I1">Computer Science Department, University of Lleida, Jaume II 69, Lleida, 25001, Spain</nlm:aff></affiliation></author><author><name sortKey="Filgueira, Rosa" sort="Filgueira, Rosa" uniqKey="Filgueira R" first="Rosa" last="Filgueira">Rosa Filgueira</name><affiliation><nlm:aff id="I3">Edinburgh Data-Intensive Research Group, School of Informatics, The University of Edinburgh, Edinburgh, UK</nlm:aff></affiliation></author><author><name sortKey="Rius, Josep" sort="Rius, Josep" uniqKey="Rius J" first="Josep" last="Rius">Josep Rius</name><affiliation><nlm:aff id="I4">ICG Software, Pol. Industrial Torrefarrera C. Mestral, , s/n 25123 Torrefarrera, Lleida, Spain</nlm:aff></affiliation></author></analytic><series><title level="j">BMC Medical Informatics and Decision Making</title><idno type="eISSN">1472-6947</idno><imprint><date when="2013">2013</date></imprint></series></biblStruct></sourceDesc></fileDesc><profileDesc><textClass></textClass></profileDesc></teiHeader><front><div type="abstract" xml:lang="en"><sec><title>Background</title><p>Cloud computing is a new paradigm that is changing how enterprises, institutions and people understand, perceive and use current software systems. With this paradigm, the organizations have no need to maintain their own servers, nor host their own software. Instead, everything is moved to the cloud and provided on demand, saving energy, physical space and technical staff. Cloud-based system architectures provide many advantages in terms of scalability, maintainability and massive data processing.</p></sec><sec><title>Methods</title><p>We present the design of an e-health cloud system, modelled by an M/M/m queue with QoS capabilities, i.e. maximum waiting time of requests.</p></sec><sec><title>Results</title><p>Detailed results for the model formed by a Jackson network of two M/M/m queues from the queueing theory perspective are presented. These results show a significant performance improvement when the number of servers increases.</p></sec><sec><title>Conclusions</title><p>Platform scalability becomes a critical issue since we aim to provide the system with high Quality of Service (QoS). In this paper we define an architecture capable of adapting itself to different diseases and growing numbers of patients. This platform could be applied to the medical field to greatly enhance the results of those therapies that have an important psychological component, such as addictions and chronic diseases.</p></sec></div></front><back><div1 type="bibliography"><listBibl><biblStruct><analytic><author><name sortKey="Free, C" uniqKey="Free C">C Free</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Bobrie, G" uniqKey="Bobrie G">G Bobrie</name></author><author><name sortKey="Chatellier, G" uniqKey="Chatellier G">G Chatellier</name></author><author><name sortKey="Genes, N" uniqKey="Genes N">N Genes</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Le N, A" uniqKey="Le N A">A León</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Kuo, Amh" uniqKey="Kuo A">AMH Kuo</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Rosenthal, A" uniqKey="Rosenthal A">A Rosenthal</name></author><author><name sortKey="Mork, P" uniqKey="Mork P">P Mork</name></author><author><name sortKey="Li, Mh" uniqKey="Li M">MH Li</name></author><author><name sortKey="Standford, J" uniqKey="Standford J">J Standford</name></author><author><name sortKey="Koester, D" uniqKey="Koester D">D Koester</name></author><author><name sortKey="Reynolds, P" uniqKey="Reynolds P">P Reynolds</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Armbrust, M" uniqKey="Armbrust M">M Armbrust</name></author><author><name sortKey="Fox, A" uniqKey="Fox A">A Fox</name></author><author><name sortKey="Griffith, R" uniqKey="Griffith R">R Griffith</name></author><author><name sortKey="Joseph, A" uniqKey="Joseph A">A Joseph</name></author><author><name sortKey="Katz, R" uniqKey="Katz R">R Katz</name></author><author><name sortKey="Konwinski, A" uniqKey="Konwinski A">A Konwinski</name></author><author><name sortKey="Lee, G" uniqKey="Lee G">G Lee</name></author><author><name sortKey="Patterson, D" uniqKey="Patterson D">D Patterson</name></author><author><name sortKey="Rabkin, A" uniqKey="Rabkin A">A Rabkin</name></author><author><name sortKey="Stoica, I" uniqKey="Stoica I">I Stoica</name></author><author><name sortKey="Zaharia, V" uniqKey="Zaharia V">V Zaharia</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Khazaei, H" uniqKey="Khazaei H">H Khazaei</name></author><author><name sortKey="Misic, J" uniqKey="Misic J">J Misic</name></author><author><name sortKey="Misic, V" uniqKey="Misic V">V Misic</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Wang, L" uniqKey="Wang L">L Wang</name></author><author><name sortKey="Von Laszewski, G" uniqKey="Von Laszewski G">G von Laszewski</name></author><author><name sortKey="Younge, A" uniqKey="Younge A">A Younge</name></author><author><name sortKey="He, X" uniqKey="He X">X He</name></author><author><name sortKey="Kunze, M" uniqKey="Kunze M">M Kunze</name></author><author><name sortKey="Tao, J" uniqKey="Tao J">J Tao</name></author><author><name sortKey="Fu, C" uniqKey="Fu C">C Fu</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct><analytic><author><name sortKey="Mao, M" uniqKey="Mao M">M Mao</name></author><author><name sortKey="Li, J" uniqKey="Li J">J Li</name></author><author><name sortKey="Humphrey, M" uniqKey="Humphrey M">M Humphrey</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Barham, P" uniqKey="Barham P">P Barham</name></author><author><name sortKey="Dragovic, B" uniqKey="Dragovic B">B Dragovic</name></author><author><name sortKey="Fraser, K" uniqKey="Fraser K">K Fraser</name></author><author><name sortKey="Hand, S" uniqKey="Hand S">S Hand</name></author><author><name sortKey="Harris, T" uniqKey="Harris T">T Harris</name></author><author><name sortKey="Ho, A" uniqKey="Ho A">A Ho</name></author><author><name sortKey="Neugebauer, R" uniqKey="Neugebauer R">R Neugebauer</name></author><author><name sortKey="Pratt, I" uniqKey="Pratt I">I Pratt</name></author><author><name sortKey="Warfield, A" uniqKey="Warfield A">A Warfield</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct><analytic><author><name sortKey="The Openstack, Project" uniqKey="The Openstack P">Project The OpenStack</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Mell, P" uniqKey="Mell P">P Mell</name></author><author><name sortKey="Grance, T" uniqKey="Grance T">T Grance</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Xiong, K" uniqKey="Xiong K">K Xiong</name></author><author><name sortKey="Perros, H" uniqKey="Perros H">H Perros</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Yang, B" uniqKey="Yang B">B Yang</name></author><author><name sortKey="Tan, F" uniqKey="Tan F">F Tan</name></author><author><name sortKey="Dai, Y" uniqKey="Dai Y">Y Dai</name></author><author><name sortKey="Guo, S" uniqKey="Guo S">S Guo</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Ma, N" uniqKey="Ma N">N Ma</name></author><author><name sortKey="Mark, J" uniqKey="Mark J">J Mark</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct><analytic><author><name sortKey="Baker, J" uniqKey="Baker J">J Baker</name></author><author><name sortKey="Bond, C" uniqKey="Bond C">C Bond</name></author><author><name sortKey="Corbett, J" uniqKey="Corbett J">J Corbett</name></author><author><name sortKey="Furman, Jj" uniqKey="Furman J">JJ Furman</name></author><author><name sortKey="Khorlin, A" uniqKey="Khorlin A">A Khorlin</name></author><author><name sortKey="Larsonand, J" uniqKey="Larsonand J">J Larsonand</name></author><author><name sortKey="Leon, Jm" uniqKey="Leon J">JM Leon</name></author><author><name sortKey="Li, Y" uniqKey="Li Y">Y Li</name></author><author><name sortKey="Lloyd, A" uniqKey="Lloyd A">A Lloyd</name></author><author><name sortKey="Yushprakh, V" uniqKey="Yushprakh V">V Yushprakh</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Watson, J" uniqKey="Watson J">J Watson</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Beloglazov, A" uniqKey="Beloglazov A">A Beloglazov</name></author><author><name sortKey="Buyya, R" uniqKey="Buyya R">R Buyya</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Beloglazov, A" uniqKey="Beloglazov A">A Beloglazov</name></author><author><name sortKey="Fotuhi, S" uniqKey="Fotuhi S">S Fotuhi</name></author><author><name sortKey="Alrokayan, M" uniqKey="Alrokayan M">M Alrokayan</name></author><author><name sortKey="Buyya, R" uniqKey="Buyya R">R Buyya</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Burke, P" uniqKey="Burke P">P Burke</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Burke, Pj" uniqKey="Burke P">PJ Burke</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Jackson, Jr" uniqKey="Jackson J">JR Jackson</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Jackson, Jr" uniqKey="Jackson J">JR Jackson</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Nah, F" uniqKey="Nah F">F Nah</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Hoxmeier, Ja" uniqKey="Hoxmeier J">JA Hoxmeier</name></author><author><name sortKey="Dicesare, C" uniqKey="Dicesare C">C DiCesare</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Shneiderman, B" uniqKey="Shneiderman B">B Shneiderman</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct></listBibl></div1></back></TEI><pmc article-type="research-article" xml:lang="en"><pmc-dir>properties open_access</pmc-dir>
<front><journal-meta><journal-id journal-id-type="nlm-ta">BMC Med Inform Decis Mak</journal-id><journal-id journal-id-type="iso-abbrev">BMC Med Inform Decis Mak</journal-id><journal-title-group><journal-title>BMC Medical Informatics and Decision Making</journal-title></journal-title-group><issn pub-type="epub">1472-6947</issn><publisher><publisher-name>BioMed Central</publisher-name></publisher></journal-meta><article-meta><article-id pub-id-type="pmid">23496912</article-id><article-id pub-id-type="pmc">3618213</article-id><article-id pub-id-type="publisher-id">1472-6947-13-35</article-id><article-id pub-id-type="doi">10.1186/1472-6947-13-35</article-id><article-categories><subj-group subj-group-type="heading"><subject>Technical Advance</subject></subj-group></article-categories><title-group><article-title>The cloud paradigm applied to e-Health</article-title></title-group><contrib-group><contrib contrib-type="author" id="A1"><name><surname>Vilaplana</surname><given-names>Jordi</given-names></name><xref ref-type="aff" rid="I1">1</xref><email>jordi@diei.udl.cat</email></contrib><contrib contrib-type="author" id="A2"><name><surname>Solsona</surname><given-names>Francesc</given-names></name><xref ref-type="aff" rid="I1">1</xref><email>francesc@diei.udl.cat</email></contrib><contrib contrib-type="author" id="A3"><name><surname>Abella</surname></name><xref ref-type="aff" rid="I2">2</xref><email>abella@gss.scs.es</email></contrib><contrib contrib-type="author" id="A4"><name><surname>Filgueira</surname><given-names>Rosa</given-names></name><xref ref-type="aff" rid="I3">3</xref><email>rosa.filgueira@ed.ac.uk</email></contrib><contrib contrib-type="author" corresp="yes" id="A5"><name><surname>Rius</surname><given-names>Josep</given-names></name><xref ref-type="aff" rid="I4">4</xref><email>jrius@icg.es</email></contrib></contrib-group><aff id="I1"><label>1</label>Computer Science Department, University of Lleida, Jaume II 69, Lleida, 25001, Spain</aff><aff id="I2"><label>2</label>Unitat de Tabaquisme of Hospital Santa Maria de Lleida, , Alcalde Rovira Roure, 44, Lleida, 25198, Spain</aff><aff id="I3"><label>3</label>Edinburgh Data-Intensive Research Group, School of Informatics, The University of Edinburgh, Edinburgh, UK</aff><aff id="I4"><label>4</label>ICG Software, Pol. Industrial Torrefarrera C. Mestral, , s/n 25123 Torrefarrera, Lleida, Spain</aff><pub-date pub-type="collection"><year>2013</year></pub-date><pub-date pub-type="epub"><day>14</day><month>3</month><year>2013</year></pub-date><volume>13</volume><fpage>35</fpage><lpage>35</lpage><history><date date-type="received"><day>17</day><month>9</month><year>2012</year></date><date date-type="accepted"><day>19</day><month>2</month><year>2013</year></date></history><permissions><copyright-statement>Copyright © 2013 Vilaplana et al.; licensee BioMed Central Ltd.</copyright-statement><copyright-year>2013</copyright-year><copyright-holder>Vilaplana et al.; licensee BioMed Central Ltd.</copyright-holder><license license-type="open-access" xlink:href="http://creativecommons.org/licenses/by/2.0"><license-p>This is an Open Access article distributed under the terms of the Creative Commons Attribution License (<ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/licenses/by/2.0">http://creativecommons.org/licenses/by/2.0</ext-link>), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p></license></permissions><self-uri xlink:href="http://www.biomedcentral.com/1472-6947/13/35"></self-uri><abstract><sec><title>Background</title><p>Cloud computing is a new paradigm that is changing how enterprises, institutions and people understand, perceive and use current software systems. With this paradigm, the organizations have no need to maintain their own servers, nor host their own software. Instead, everything is moved to the cloud and provided on demand, saving energy, physical space and technical staff. Cloud-based system architectures provide many advantages in terms of scalability, maintainability and massive data processing.</p></sec><sec><title>Methods</title><p>We present the design of an e-health cloud system, modelled by an M/M/m queue with QoS capabilities, i.e. maximum waiting time of requests.</p></sec><sec><title>Results</title><p>Detailed results for the model formed by a Jackson network of two M/M/m queues from the queueing theory perspective are presented. These results show a significant performance improvement when the number of servers increases.</p></sec><sec><title>Conclusions</title><p>Platform scalability becomes a critical issue since we aim to provide the system with high Quality of Service (QoS). In this paper we define an architecture capable of adapting itself to different diseases and growing numbers of patients. This platform could be applied to the medical field to greatly enhance the results of those therapies that have an important psychological component, such as addictions and chronic diseases.</p></sec></abstract><kwd-group><kwd>Cloud systems</kwd><kwd>e-Health</kwd><kwd>Queue systems</kwd><kwd>Quality of service</kwd></kwd-group></article-meta></front><body><sec><title>Background</title><p>A recent study
[<xref ref-type="bibr" rid="B1">1</xref>] showed as personalized follow-up by using of telematic tracking applications by means of SMS messaging improved the results in the quitting smokers patients. Related experiments also proved that the same method is useful for application related with the treatment of hypertensive patients
[<xref ref-type="bibr" rid="B2">2</xref>] and in patients with chronic diseases in general
[<xref ref-type="bibr" rid="B3">3</xref>]. By using telematic applications, the time dedicated to personalized clinical attention to patients increase, and clinicians more effectively scheduled and managed that time. Also avoids unnecessary travel by patients, while allowing them to feel closely followed by the clinician. This is just one example of the benefits that can bring telematic applications, whose implementation in health centres is increasing.</p><p>This article presents the design of a cloud platform with QoS guarantees (based on waiting time for services) applied to e-Health. It is thought to include a wide range of telematic as well as usual programs (administration, specialised, general purpose, etc.). Cloud computing can offer many opportunities to improve health care services from the viewpoint of management, technology, security and legality
[<xref ref-type="bibr" rid="B4">4</xref>]. By moving the infrastructure to the cloud, valuable data extracted from the different databases of treatment, patients, diseases, and so on will be accessible to doctors to perform analytical studies and see statistical results. By hiding personal patient details, data could be shared between doctors and even hospitals, and could also be cross-reference information from different diseases and treatments. In
[<xref ref-type="bibr" rid="B5">5</xref>], the authors examine how the biomedical informatics community, especially consortia that share data and applications, can take advantage of cloud computing. Cloud computing systems offer the illusion of infinite computing resources available on demand, allowing an expansion of the resources when needed. Hardware and software services are more efficiently handled than in other High Performance Computing (HPC) infrastructure as they can be added and released dynamically
[<xref ref-type="bibr" rid="B6">6</xref>]. However, problems arise when scaling the system, this is, when trying to deploy a platform to support the computing needs of many hospitals, with different clinical departments, with their corresponding clinicians and patients. We can say that this health approach can be extrapolated to many other areas, administration, education, social care, etc.</p><p>Cloud computing has gained worldwide attention from many researchers, but only a small portion of them have addressed the QoS performance problem
[<xref ref-type="bibr" rid="B7">7</xref>]. QoS performance includes indicators such as response time, task blocking probability, probability of immediate service, and mean number of tasks in the system
[<xref ref-type="bibr" rid="B8">8</xref>], all of which may be determined using the tools of queuing theory
[<xref ref-type="bibr" rid="B9">9</xref>].</p><p>We use Cloud computing and queuing system theory to address the problem of cloud scaling. By modelling a queue system we aim to provide scalability to the cloud infrastructure running on a given virtualized platform. Thus the cloud system can automatically scale out in an optimal way in order to guarantee the QoS (e.g. waiting time), planning the proper deployment and removal of virtual machines according to the system load
[<xref ref-type="bibr" rid="B10">10</xref>]. Platforms like Xen
[<xref ref-type="bibr" rid="B11">11</xref>] or VMWare
[<xref ref-type="bibr" rid="B12">12</xref>] offer virtual computing environments that allow for flexible cloud system management and configuration. Despite this, they do not offer tools to manage the computational resources (mainly virtual servers) in a dynamic and flexible way given a defined Quality of Service (QoS). In order to achieve that, OpenStack
[<xref ref-type="bibr" rid="B13">13</xref>] can be used, an open source software for managing virtual machines.</p><p>Quite different, our work does not focus on the investigation of specific queuing theory challenges but on the use of existing models for designing and testing performance of cloud systems in e-Health. We are interested in modelling QoS performance by scaling e-Health cloud platforms, leaving aside other issues such as reliability, security or availability.</p><sec><title>Preliminary concepts and related work</title><p>A cloud system is a network of computer servers that are offered under demand as a service, and they are designed to be scalable and flexible. Cloud systems can be served in three different ways (see Figure
<xref ref-type="fig" rid="F1">1</xref>). The first layer is Infrastructure as a Service (IaaS), which means offering hardware, storage and physical devices over the Internet; The second layer is Software as a Service (SaaS), which means offering software and hosted applications over the Internet; And as a combination of both, Platform as a Service (PaaS), which means offering the capability to deploy applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, but has control over the deployed applications
[<xref ref-type="bibr" rid="B7">7</xref>,<xref ref-type="bibr" rid="B14">14</xref>]. In our case, we are interested in modelling a private cloud system, maintained by one organization/institution, of the SaaS kind, which mainly provides software services to its members or end users, clinicians and patients.</p><fig id="F1" position="float"><label>Figure 1</label><caption><p><bold>Cloud services.</bold> Classification of cloud systems according to the services they offer. <bold>SaaS</bold> allows users to run online applications. The vendors own the applications and the users pay a fixed subscription fees. <bold>PaaS</bold> allows users to create their own cloud applications, providing all the execution and compilation of software as well as operating systems. <bold>IaaS</bold> allows users to run any applications they want to on cloud hardware of their choice.</p></caption><graphic xlink:href="1472-6947-13-35-1"></graphic></fig><p>In
[<xref ref-type="bibr" rid="B15">15</xref>], the authors obtained the response time distribution of a cloud system modelled by means of queuing theory on a classical <italic>M/M/m</italic> open network with <italic>m</italic> servers, assuming an exponential density function for the inter-arrival and service times (<italic>M</italic>). By using the response time distribution, they determined the level of service and the relationship between the maximum number of tasks and the minimum number of resources (virtual machines). The response time takes into account both waiting time in the queue and service time. In
[<xref ref-type="bibr" rid="B16">16</xref>], the authors obtained the response time distribution for a cloud with a <italic>M/M/m/m+r</italic> system model. Having in addition a finite number of buffers (i.e. connections) of size <italic>m+r</italic>. M/M/m/m+r models can be more suitable when we have a known finite buffer for arrivals. M/M/m models are useful when these maximum connections are unknown or not relevant, and the resulting analysis is not as complex as in the M/M/m/m+r models.</p><p>The study of the case where the time between arrivals and/or service time does not follow an exponential distribution is much more complex, as for example G/M/m, M/G/m and G/G/m models. Many theoretical studies have been based on extensive research in performance evaluation, including those that analysed the M/G/m model (e.g.
[<xref ref-type="bibr" rid="B17">17</xref>]). The complexity in these cases comes from the impossibility of obtaining a closed formula to represent the probability distributions of the response or waiting time of customers in the queue, and therefore requires finding approximate models.</p><p>As stated in
[<xref ref-type="bibr" rid="B18">18</xref>], the majority of current cloud computing infrastructure as of 2009 consists of services that are offered up and delivered through a service centre such as a data centre that can be accessed from a web browser anywhere in the world. Our proposal also relies on that.</p><p>In this paper, we study a queuing performance model consisting of a cloud architecture (or simply called a cloud) and a service centre such as a data centre. The cloud, is a single point of access for the computing needs of the customers being serviced
[<xref ref-type="bibr" rid="B18">18</xref>] through a Web browser supported by a Web server. In
[<xref ref-type="bibr" rid="B15">15</xref>] the service centre was modelled as a collection of service resources used by a service provider to host service applications for customers. In our case, the service centre is a database server. The service provider is required to execute service requests from a customer within negotiated quality of service (QoS) requirements for a given price determined by the service level agreement (SLA). The SLA is a contract negotiated and agreed between a customer and a service provider. In our case the customers will be the end users (clinicians and patients) and the service provider the owner organization of the cloud.</p><p>However, traditional queuing results are not directly applicable to performance analysis of cloud computing when one or more of the three following issues holds
[<xref ref-type="bibr" rid="B7">7</xref>], the number of servers is huge, this is cloud systems made up by hundreds or thousands of nodes
[<xref ref-type="bibr" rid="B19">19</xref>]; the distribution of service times is unknown, and does not follow a “well-behaved” probability distributions such as exponential distribution; finally, the traffic intensity can vary in an extremely wide range. Cloud centres must provide expected QoS at widely varying loads due to its dynamic nature
[<xref ref-type="bibr" rid="B15">15</xref>,<xref ref-type="bibr" rid="B20">20</xref>], so load peaks are badly modelled by queuing systems.</p></sec><sec><title>Cloud architecture</title><p>The architecture of our cloud platform consists of two main parts: Front-end and Back-end (see Figure
<xref ref-type="fig" rid="F2">2</xref>).</p><fig id="F2" position="float"><label>Figure 2</label><caption><p><bold>Cloud system modelling.</bold> Design of the proposed cloud architecture. User requests from multiple devices go through a HTTP interface to the cloud system. A First-Come-First-Serve scheduler distributes all these requests to the Front-end nodes, which forward these to the Back-end nodes. The Back-end nodes process the requests and compute the expected user result, accessing the system database if needed. In the Back-end, there are also control nodes that monitor the state of the system, and are able to create or destroy virtual machines according to that state.</p></caption><graphic xlink:href="1472-6947-13-35-2"></graphic></fig><sec><title>Front-end</title><p>The Front-end is the gateway to the cloud and consists of the software components and the interfaces needed to connect to the platform by using remote client applications. These applications usually use standard Web protocols to access the system and an authentication protocol which allows access to authorised users (clinicians and patients). All requests are processed by the scheduler, which sends the selected tasks to the queue of the Back-end. For simplicity, a First Come First Serve (FCFS) scheduling policy was assumed.</p><p>As we are proposing a generic system, medical workflows will not be implemented as part of our model. Instead, these medical workflows will be implemented via software. All arriving tasks in our model will consist of web requests, avoiding deadlock situations that could otherwise arise when using a FCFS queue policy.</p></sec><sec><title>Back-end</title><p>The Back-end functions include management of the job queue, the servers and their virtual machines and the storage servers with their database system. Database inconsistencies are avoided by considering only one storage (i.e. database) server. All requests from the Front-end are managed by a scheduler to be allocated in a queue. The server system consists of multiple virtual machines managed by OpenStack and connected to a database server.</p><p>The Back-end is made up of three different kinds of servers: <bold>Primary servers:</bold> virtual machines running the multithreading application. The parallel degree of the applications will depend on the threads (tasks making up the application when executed) it can be decomposed. These servers are responsible for performing most of the computation. <bold>Specific Servers:</bold> virtual machines whose main task is to perform specific calculations and handle the Front-end interface. Moreover, they manage the communication with the database and with other servers (even the primary servers). <bold>Control Server:</bold> virtual machine in charge of monitoring the overall system status. This server is responsible for creating and removing virtual machines dynamically.</p></sec></sec><sec><title>OpenStack</title><p>The cloud architecture presented in previous section can be implemented with OpenStack
[<xref ref-type="bibr" rid="B13">13</xref>]. OpenStack is an open source software that provides a massively scalable and pluggable framework for building private and public clouds. Notice that our cloud was characterised as private and scalable, so it ideal for our purpose. It goes beyond a classic hypervisor (i.e. VirtualBox
[<xref ref-type="bibr" rid="B21">21</xref>], Xen
[<xref ref-type="bibr" rid="B11">11</xref>], VMware
[<xref ref-type="bibr" rid="B12">12</xref>]), and allows the setup of virtual machines dynamically, as computational resources are needed. This guarantees high QoS in periodic traffic spikes, when the arrival rate of the requests to be served increases. OpenStack can be set up to create new instances when current servers are overwhelmed and to shut them down when traffic decreases. This feature ensures you that the number of instances in the cloud system scales up when your system grows, and is particularly well suited for applications that experience deep variability in usage.</p><p>OpenStack offers a set of APIs (Application Programming Interface) that allow to interact dynamically with the installed OpenStack platform. Using these APIs, it is possible to authenticate and interact with the system from the command line or programmatically. For example, in Python we have available the python-nova client API
[<xref ref-type="bibr" rid="B22">22</xref>,<xref ref-type="bibr" rid="B23">23</xref>] avaialble, where the <italic>nova boot</italic> and <italic>nova delete</italic> commands allow us respectively to boot a new server and immediately shut down and delete a server dynamically.</p></sec></sec><sec sec-type="methods"><title>Methods</title><sec><title>System analysis and design</title><p>The main aim of this work is the design of the Back-end, composed of the primary, specific and control servers. The design has to take into account the analysis of requirements, which in our case exclusively focus on the characterisation of arrival frequency of the users and the QoS in serving them with our cloud platform.</p><p>The e-Health application we are targeting must be scalable in order to provide a service to an unlimited number of users which will be mainly healthcare staff and patients from various hospitals. Taking into account the cloud architecture (Section Back-end), the <italic>primary</italic> servers of the Back-end are the ones in charge of serving the platform users’ requests.</p><p>Furthermore, several <italic>specific servers</italic> will be in charge of the communications with the database containing the healthcare information.</p><p>Finally, the <italic>control server</italic> will be in charge of managing the creation and disposal of the <italic>specific</italic> and <italic>primary</italic> servers. In order to control the system we propose the creation of a queuing system that models system performance. This model is described in Section <italic>Modelling</italic>.</p><p>Figure
<xref ref-type="fig" rid="F2">2</xref> shows the design of the cloud system, including how service requests are planned by the “Scheduler” via a FCFS queue. Then, the requests are forwarded to the Front-end in charge of submitting tasks to the Back-end. Finally, the communication among the Back-end components is also shown.</p></sec><sec><title>Modelling</title><p>In this section, we will focus only on the Back-end, which is managed by the <italic>control server</italic>. Its basic function is to create and remove <italic>specific</italic> and <italic>primary</italic> servers. These decisions are taken according to the waiting time of the user tasks.</p><p>As can be seen in Figure
<xref ref-type="fig" rid="F3">3</xref>, the system will contain two queues of the same type (<italic>M/M/m</italic>). This means that both the time between user arrivals to the system and the service time of the system follow an exponential distribution with means <italic>λ</italic> and <italic>μ</italic> respectively, with <italic>m</italic> servers with an FCFS scheduling policy. The first queue models the <italic>primary servers</italic> while the second one models the <italic>specific servers</italic> that interact with the database.</p><fig id="F3" position="float"><label>Figure 3</label><caption><p><bold>Model.</bold> Graphical representation of the two system queues. Both of them are of the same type (<italic>M/M/m</italic>). The first <italic>M/M/m</italic> queue models the access to the primary servers, and is always accessed when new requests enter the system. The second <italic>M/M/m</italic> queue models the access to the database cluster, which is accessed based on a probability depending on the Back-end nodes.</p></caption><graphic xlink:href="1472-6947-13-35-3"></graphic></fig><p>Abstracting away the details of the application problem, we propose a model of a queueing system composed by two <italic>M/M/m</italic> queues connected serially, as can be seen in Figure
<xref ref-type="fig" rid="F4">4</xref>. The user tasks enter the system though the first queue; then they move on to the second queue (this represents the database system) with probability <italic>d</italic>. Conversely, a user has (1−<italic>d</italic>) probability of leaving the system without passing through the second queue. In this way, we are modelling a system in which each user requires a computing operation and a database access with probability <italic>d</italic>.</p><fig id="F4" position="float"><label>Figure 4</label><caption><p><bold>Two serially connected</bold><bold><italic>M/M/m</italic></bold><bold> queues.</bold> Queueing system composed by two <italic>M/M/m</italic> queues connected serially. The first one models the access to the primary servers, and the second one models the access to the database. <italic>λ</italic> is the request arrival rate. There is a probability <italic>d</italic> of accessing the second queue, and a probability (1−<italic>d</italic>) of exiting the queueing system without going through the second queue.</p></caption><graphic xlink:href="1472-6947-13-35-4"></graphic></fig><p>According to Burke’s theorem
[<xref ref-type="bibr" rid="B24">24</xref>], the output of a stable <italic>M/M/m</italic> queue with an input parameter <italic>λ</italic> and a service parameter <italic>μ</italic> for each one of the <italic>m</italic> servers is a Poisson process with the same input parameter <italic>λ</italic>. This means that the serial connection of two <italic>M/M/m</italic> systems (without cycles) is independent between them and these systems keep the same density distributions, both for arrival and service.</p><p>Our two queues can be analysed independently, and they form an open Jackson network. The interconnection and behaviour between the queues is ruled by Burke’s
[<xref ref-type="bibr" rid="B25">25</xref>] and Jackson’s theorems. Burke states that we may connect many multiple-server nodes together in a feedforward network and still preserve the node-by-node decomposition. Jackson
[<xref ref-type="bibr" rid="B26">26</xref>,<xref ref-type="bibr" rid="B27">27</xref>] states that to calculate the total average arrival rate we must sum the arrivals from outside the system plus arrivals from all internal nodes.</p><sec><title>M/M/m</title><p>In this section we analyze the <italic>M/M/m</italic> queuing system, with <italic>m</italic> servers and two density functions, that represents the average arrival (<italic>λ</italic>) and service rate per server (<italic>μ</italic>), as can be seen in Figure
<xref ref-type="fig" rid="F5">5</xref>.</p><fig id="F5" position="float"><label>Figure 5</label><caption><p><bold><italic>M/M/m</italic></bold><bold> queue scheme.</bold> Representation of an <italic>M/M/m</italic> queuing system with <italic>m</italic> servers and two density functions. The average arrival rate of the requests is represented by <italic>λ</italic>. The total number of servers goes from one to <italic>m</italic>, each one having a service rate represented by <italic>μ</italic>.</p></caption><graphic xlink:href="1472-6947-13-35-5"></graphic></fig><p>Figure
<xref ref-type="fig" rid="F6">6</xref> shows the state transition diagram of the system in equilibrium, as well as the equations that define it.</p><fig id="F6" position="float"><label>Figure 6</label><caption><p><bold>Transition state diagram and equilibrium equations of</bold><bold><italic>M/M/m</italic></bold><bold> queue.</bold> State transition diagram of the <italic>M/M/m</italic> queue and the equilibrium equations that define it. The state space records the number of customers in the queueing system. The values <italic>λ</italic> and <italic>μ</italic> represent the arrival and service rates of customers.</p></caption><graphic xlink:href="1472-6947-13-35-6"></graphic></fig><p>Solving the system of equations we can obtain the value for <italic>p</italic><sub><italic>k</italic></sub>, i.e., the probability of the system having exactly <italic>k</italic> users.</p><p><disp-formula id="bmcM1"><label>(1)</label><mml:math id="M1" name="1472-6947-13-35-i1" overflow="scroll"><mml:msub><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfenced open="{"><mml:mrow><mml:mtable class="array" columnalign="left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub><mml:mfrac><mml:mrow><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:mtext mathvariant="italic">mp</mml:mtext><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>!</mml:mo></mml:mrow></mml:mfrac></mml:mtd><mml:mtd><mml:mspace width="2.77695pt"></mml:mspace><mml:mi>k</mml:mi><mml:mo>≤</mml:mo><mml:mi>m</mml:mi></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub><mml:mfrac><mml:mrow><mml:msup><mml:mrow><mml:mi>m</mml:mi></mml:mrow><mml:mrow><mml:mi>m</mml:mi></mml:mrow></mml:msup><mml:msup><mml:mrow><mml:mi>ρ</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>m</mml:mi><mml:mo>!</mml:mo></mml:mrow></mml:mfrac></mml:mtd><mml:mtd><mml:mspace width="2.77695pt"></mml:mspace><mml:mi>k</mml:mi><mml:mo>≥</mml:mo><mml:mi>m</mml:mi></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mfenced></mml:math></disp-formula></p><p>where the utilisation factor (<italic>ρ</italic>) is:</p><p><disp-formula id="bmcM2"><label>(2)</label><mml:math id="M2" name="1472-6947-13-35-i2" overflow="scroll"><mml:mi>ρ</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>λ</mml:mi></mml:mrow><mml:mrow><mml:mi>mμ</mml:mi></mml:mrow></mml:mfrac><mml:mo><</mml:mo><mml:mn>1</mml:mn></mml:math></disp-formula></p><p>Taking into account that:</p><p><disp-formula id="bmcM3"><label>(3)</label><mml:math id="M3" name="1472-6947-13-35-i3" overflow="scroll"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mi mathsize="big">∑</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mi>∞</mml:mi></mml:mrow></mml:munderover><mml:msub><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo></mml:math></disp-formula></p><p>we obtain the probability of having no users in the system (<italic>p</italic><sub>0</sub>):</p><p><disp-formula id="bmcM4"><label>(4)</label><mml:math id="M4" name="1472-6947-13-35-i4" overflow="scroll"><mml:msub><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msup><mml:mrow><mml:mfenced open="[" close="]"><mml:mrow><mml:msubsup><mml:mrow><mml:mi mathsize="big">∑</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mi>m</mml:mi><mml:mo>−</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msubsup><mml:mfrac><mml:mrow><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:mi>mρ</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>!</mml:mo></mml:mrow></mml:mfrac><mml:mo>+</mml:mo><mml:mfrac><mml:mrow><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:mi>mρ</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mi>m</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>m</mml:mi><mml:mo>!</mml:mo><mml:mo>(</mml:mo><mml:mn>1</mml:mn><mml:mo>−</mml:mo><mml:mi>ρ</mml:mi><mml:mo>)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:mfenced></mml:mrow><mml:mrow><mml:mo>−</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msup></mml:math></disp-formula></p><p>The average number of users in the waiting queue (<italic>N</italic><sub><italic>W</italic></sub>) is:</p><p><disp-formula id="bmcM5"><label>(5)</label><mml:math id="M5" name="1472-6947-13-35-i5" overflow="scroll"><mml:mtable><mml:mtr><mml:mtd columnalign="left"><mml:msub><mml:mrow><mml:mi>N</mml:mi></mml:mrow><mml:mrow><mml:mi>W</mml:mi></mml:mrow></mml:msub></mml:mtd><mml:mtd columnalign="left"><mml:mo>=</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mi mathsize="big">∑</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mi>∞</mml:mi></mml:mrow></mml:munderover><mml:mi>k</mml:mi><mml:msub><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>+</mml:mo><mml:mi>m</mml:mi></mml:mrow></mml:msub></mml:mtd></mml:mtr><mml:mtr><mml:mtd></mml:mtd><mml:mtd columnalign="left"><mml:mo>=</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mi mathsize="big">∑</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mi>∞</mml:mi></mml:mrow></mml:munderover><mml:mi>k</mml:mi><mml:msub><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub><mml:mfrac><mml:mrow><mml:msup><mml:mrow><mml:mi>m</mml:mi></mml:mrow><mml:mrow><mml:mi>m</mml:mi></mml:mrow></mml:msup><mml:msup><mml:mrow><mml:mi>ρ</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>+</mml:mo><mml:mi>m</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>m</mml:mi><mml:mo>!</mml:mo></mml:mrow></mml:mfrac><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:mi>mρ</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mi>m</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>m</mml:mi><mml:mo>!</mml:mo></mml:mrow></mml:mfrac><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mi mathsize="big">∑</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mi>∞</mml:mi></mml:mrow></mml:munderover><mml:mi>k</mml:mi><mml:msup><mml:mrow><mml:mi>ρ</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msup></mml:mtd></mml:mtr><mml:mtr><mml:mtd></mml:mtd><mml:mtd columnalign="left"><mml:mo>=</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:mfrac><mml:mrow><mml:msub><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:mi>mρ</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mi>m</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>m</mml:mi><mml:mo>!</mml:mo></mml:mrow></mml:mfrac><mml:mfrac><mml:mrow><mml:mi>ρ</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:mn>1</mml:mn><mml:mo>−</mml:mo><mml:mi>ρ</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup></mml:mrow></mml:mfrac></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p><p>The average waiting time in the queue <italic>W</italic> (this is the QoS parameter we have chosen for this work) is defined as:</p><p><disp-formula id="bmcM6"><label>(6)</label><mml:math id="M6" name="1472-6947-13-35-i6" overflow="scroll"><mml:mi>W</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mrow><mml:mi>N</mml:mi></mml:mrow><mml:mrow><mml:mi>W</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:mi>λ</mml:mi></mml:mrow></mml:mfrac></mml:math></disp-formula></p></sec><sec><title>Quality of service</title><p>As was said before, the selected Quality of Service (QoS) criterion is the waiting time in the queue. This waiting time depends on the utilization factor <italic>ρ</italic>. In an <italic>M/M/m</italic> system queue,
<inline-formula><mml:math id="M7" name="1472-6947-13-35-i7" overflow="scroll"><mml:mi>ρ</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>λ</mml:mi></mml:mrow><mml:mrow><mml:mi>mμ</mml:mi></mml:mrow></mml:mfrac></mml:math></inline-formula>.</p><p>According to the guidelines stated by Shneiderman
[<xref ref-type="bibr" rid="B28">28</xref>-<xref ref-type="bibr" rid="B30">30</xref>], a system’s response time should be appropriate to the task that is being performed. For typing, cursor motion and mouse selection, they define an interval of between 50 and 150 milliseconds, and a value of 750 to 1000 milliseconds for simple and frequent tasks. The customers of our system will be performing simple and frequent tasks due to the interaction with a web-based application. For these reasons, we assume a <italic>W</italic><sub><italic>min</italic></sub> value of 150ms and a <italic>W</italic><sub><italic>max</italic></sub> value of 750ms. These values could be modified to analyse other kinds of system where mean acceptable response times could be different.</p><p>As a consequence, we can establish that if the average waiting time of our system is longer than <italic>W</italic><sub><italic>max</italic></sub>, the system will have to create new virtual machines, this is, to increase the number of <italic>primary</italic> servers or, depending on the case, <italic>specific</italic> servers until <italic>W</italic> returns back under the <italic>W</italic><sub><italic>max</italic></sub> threshold. Conversely, if <italic>W</italic> drops below the <italic>W</italic><sub><italic>min</italic></sub> value, the system can release resources, which in our case corresponds to removing <italic>primary</italic> (or <italic>specific</italic>) <italic>servers</italic>, until <italic>W</italic> is again above the lower limit <italic>W</italic><sub><italic>min</italic></sub>. This mechanism is implemented in the algorithm presented in Quality of service section which checks every period of time <italic>T</italic> the value of <italic>W</italic> and determines the need for creating or removing <italic>primary</italic> or <italic>specific</italic> servers until <italic>W</italic> lies within the range <italic>W</italic><sub><italic>min</italic></sub> ≤ <italic>W</italic> ≤ <italic>W</italic><sub><italic>max</italic></sub> range. Currently, <italic>T</italic> is a predetermined value, set by the system administrator, but it would be interesting to calculate <italic>T</italic> in function of <italic>ρ</italic>. In the same way, it would also be interesting to incorporate some kind of control mechanism in the algorithm in order to decide which type of virtual machines (primary or specific) should be created or removed when necessary.</p></sec></sec></sec><sec><title></title><sec><title>Algorithm 1 QoS control</title></sec></sec><sec><title>Results and discussion</title><p>The following section presents an analysis about how the response time is affected by increasing the number of servers in an <italic>M/M/m</italic> queue. Figure
<xref ref-type="fig" rid="F7">7</xref> shows how the waiting times (in generic units) of the first queue increases by increasing the occupation ratio <italic>ρ</italic> for one, two, ten and a hundred servers. These values have been obtained by using the queue simulator server Queue 2.0
[<xref ref-type="bibr" rid="B31">31</xref>].</p><fig id="F7" position="float"><label>Figure 7</label><caption><p><bold>Waiting time on queue 1 (M/M/m).</bold> Graph plotting how the waiting times (in generic units) of the first queue increases by increasing the occupation ratio <italic>ρ</italic> for one, two, ten and a hundred servers. It shows that increasing the number of servers significantly decreases the resulting waiting time.</p></caption><graphic xlink:href="1472-6947-13-35-7"></graphic></fig><p>For the second queue, the entering rate is based on <italic>λd</italic>. Figure
<xref ref-type="fig" rid="F8">8</xref> shows the same results as Figure
<xref ref-type="fig" rid="F7">7</xref> by using instead the second queue. We have assumed a value of <italic>d</italic> = 0.9 as the probability of one user accessing the database servers.</p><fig id="F8" position="float"><label>Figure 8</label><caption><p><bold>Waiting time on queue 2 (M/M/m).</bold> Graph plotting how the waiting times (in generic units) of the second queue increases by increasing the occupation ratio <italic>ρ</italic> for one, two, ten and a hundred servers. It shows that increasing the number of servers significantly decreases the resulting waiting time.</p></caption><graphic xlink:href="1472-6947-13-35-8"></graphic></fig><p>The mean access rate to the database <italic>d</italic> can widely vary from one application to another. We have assumed a 0.9 value due to our experimental application making requests to the database for 90% of the user requests. We also did some testing with slightly modified values of <italic>d</italic> and proportional results were obtained.</p><p>As was expected, the waiting time of the queue 2 is smaller than that of queue 1. As the user flow lowers in the queue 2 also decreases its mean waiting time. Thus, waiting times decreases with <italic>d</italic>. <italic>W</italic> is the sum of waiting times in queue 1 and 2. <italic>W</italic><sub><italic>max</italic></sub> and <italic>W</italic><sub><italic>min</italic></sub> will determine the number of clients/connections to be served simultaneously. For example, we could set <italic>W</italic><sub><italic>max</italic></sub> = 13 if this generic time value corresponds to 750ms in the real cloud. It has been shown how a widely used and tested kind of queuing model can be used to model cloud computing systems.</p><p>We would like to highlight that for small numbers of servers, the relation between the waiting time of both queues does not change, keeping it at constant levels. On the other hand, for large computing systems, with huge computing requirements (virtual servers), the waiting time between the first and the second phase tends to stabilize when we increase the parameter <italic>ρ</italic>. Furthermore, as Figure
<xref ref-type="fig" rid="F9">9</xref> shows, this relation suffers a significant drop in large systems with high number of virtual machines. This explain why queuing systems cannot be applied to model huge cloud farms of servers.</p><fig id="F9" position="float"><label>Figure 9</label><caption><p><bold>Waiting time rate.</bold> Graph plotting the waiting time ratio between waiting times of the first and second queues with one and a hundred servers, for different <italic>ρ</italic> values.</p></caption><graphic xlink:href="1472-6947-13-35-9"></graphic></fig></sec><sec sec-type="conclusions"><title>Conclusions</title><p>In this paper, a new application of cloud computing paradigm is presented by designing a system model applied to e-Health. The design of a cloud system requires the use of scalable, centralized, flexible, and dynamic architectures with a high level of integration. We have selected queuing theory as the basic mean to model the performance of the cloud system. As a result, the dynamics of the system based on the creation/deletion of the virtual systems is controlled by a queuing system model.</p><p>Through a preliminary analysis, the design of a cloud architecture with e-Health requirements has been proposed. The combination of two systems M/M/m in sequence has been proposed to model the cloud e-Health platform. The first offers compute services, and the second provides service access to a database server. Our work has shown that to provide good QoS, in terms of averaged waiting times, the the waiting time between the first and the second phase tends to stabilize. This reduction becomes much more significant when we increase the number of virtual machines.</p><p>The proposed system can improve the e-Health field by providing a model to support medical software, saving resources and enhancing the control and management of the patients. Pay-per-use service would lower overall costs. The proposed system would also allow tendencies that could be used to improve the current treatments to be generated and analysed. Also, having an electronic clinical history would save paper, physical space and would improve the efficiency of those who need to access it. The design can easily satisfy the needs of e-Health related applications without major changes, allowing the construction of web-based applications that implement all the needed medical workflows. The proposed system guarantees high scalability, ensuring that when the system requirements grow, the underlying platform will be able to handle the situation. Also, the proposed system suggests the usage of a large shared infrastructure, which would result in many hospitals and treatments having homogeneous data that would facilitate correlations and data mining.</p><sec><title>Future work</title><p>As explained above, we would like to extend the algorithm presented in Quality of service section to determine the value of <italic>T</italic> based on <italic>ρ</italic>. We would like to run more tests in order to explain how fast can W (waiting time) change and the proposed system reaction to these changes. Furthermore, it would be of great interest to incorporate mechanisms for deciding the type of virtual machines that should be created/deleted (primary or specific servers). Moreover, we would like to replace both queues with a more realistic <italic>M</italic>/<italic>M</italic>/<italic>m</italic>/<italic>m</italic> + <italic>r</italic>/<italic>K</italic> model, with <italic>m</italic> servers, <italic>m</italic> + <italic>r</italic>user connections (the maximum number of users in the system, that is, users receiving the service, being at most <italic>m</italic>, plus users who are waiting, at most <italic>r</italic>), and a maximum number of <italic>K</italic> users as presented in
[<xref ref-type="bibr" rid="B7">7</xref>]. In our case, if patients can enter the system, a <italic>M/M/m</italic> system could be used, as we would have not a clear reference to the maximum number of users in the system. In the other case, if patients can not enter the system, we could take the <italic>M</italic>/<italic>M</italic>/<italic>m</italic> + <italic>r</italic>/<italic>K</italic>approach because we would have a more specific set of customers. We would want to create an adaptive system that could select the best model for each situation. As future work, we also plan to develop an application by using OpenStack, which will emulate the requirements of the Tobacco Control Unit in Santa Maria Hospital (Lleida, Spain), using real data based on user numbers and requirements. We have already implemented a preliminary prototype
[<xref ref-type="bibr" rid="B32">32</xref>]. The aim of this work would be to estimate the computing resources that such a Tobacco Control Unit would require. In this way, by knowing the hospital users, we will design a cloud system applied to e-Health in a specific hospital. This application should be extended to emulate the behaviour of the system assuming the scalability of the system by increasing the number of hospitals. We would also like to extend the scalability tests to more than one hundred servers. We would like to test up to one million servers in order to verify the scalability of the system.</p></sec></sec><sec><title>Competing interests</title><p>The authors declare that they have no competing interests.</p></sec><sec><title>Authors’ contributions</title><p>JV, RF and DR contributed to the study concept and design of the experimental tests. JV and JR performed the experimental tests and the data analysis. FS contributed to the development of the model and the algorithms presented in this paper, and took the lead in drafting this paper. FS, JV and JR wrote the first version of the manuscript. All five authors contributed to the preparation of the manuscript. All authors read and approved the final manuscript.</p></sec><sec><title>Authors’ information</title><p>JV received his BS and MS in computer science from Universitat de Lleida (UdL) in 2006 and 2008 respectively. Currently he is a PhD student in the same University and his research interests are Cloud computing, e-Health, and parallel simulation.</p><p>FS received the B.S., M.S. and Ph.D. degrees in computer science from the Autonomous University of Barcelona, Spain, in 1991, 1994 and 2002 respectively. At the present time, he is an associate professor in the Department of Computer Science at the University of Lleida (Spain). His research interests include distributed processing and HPC.</p><p>JR received his B.S., M.S. and Ph.D. in computer science from University of Lleida (UdL) in 2006, 2008 and 2012 respectively. Currently he is leading the research division at ICG Software and he is an assistant lecturer at University of Lleida. His main research interests are high-performance computing, P2P systems and Cloud computing.</p><p>RF received the MS degree in computer science from the University Deusto of Bilbao in 2003 and the Ph.D degree in computer science University Carlos III of Madrid in 2010. She had been an assistant professor since 2004 at the Universidad Carlos III de Madrid. Nowadays she is working as Research Assistant in University of Edinburgh. Her main reseach interest are high performance computing, data stream transfer and Cloud Computing.</p><p>DR received his BS and PhD in Physics from University of Cantabria in 1998 and 2007 respectively. Currently he is an associate researcher at the Edinburgh Data Intensive Research group (School of Informatics) and the Brain Research Imaging Centre (Division of Clinical Neurosciences) of the University of Edinburgh. His main research interests are information governance, privacy protection in the e-Health context and data intensive science.</p></sec><sec><title>Pre-publication history</title><p>The pre-publication history for this paper can be accessed here:</p><p><ext-link ext-link-type="uri" xlink:href="http://www.biomedcentral.com/1472-6947/13/35/prepub">http://www.biomedcentral.com/1472-6947/13/35/prepub</ext-link></p></sec></body><back><sec><title>Acknowledgements</title><p>This work was supported by the MEyC under contract TIN2011-28689-C02-02. Some of the authors are members of the research group 2009 SGR145, funded by the Generalitat de Catalunya.</p></sec><ref-list><ref id="B1"><mixed-citation publication-type="journal"><name><surname>Free</surname><given-names>C</given-names></name><article-title>Smoking cessation support delivered via mobile phone text messaging (txt2stop): a single-blind, randomised trial</article-title><source>Lancet</source><year>2011</year><volume>378</volume><issue>9785</issue><fpage>49</fpage><lpage>55</lpage><pub-id pub-id-type="doi">10.1016/S0140-6736(11)60701-0</pub-id><pub-id pub-id-type="pmid">21722952</pub-id></mixed-citation></ref><ref id="B2"><mixed-citation publication-type="journal"><name><surname>Bobrie</surname><given-names>G</given-names></name><name><surname>Chatellier</surname><given-names>G</given-names></name><name><surname>Genes</surname><given-names>N</given-names></name><article-title>Cardiovascular prognosis of “masked hypertension” detected by blood pressure self-measurement in elderly treated hypertensive patients</article-title><source>JAMA</source><year>2004</year><volume>291</volume><issue>11</issue><fpage>1342</fpage><lpage>1349</lpage><pub-id pub-id-type="doi">10.1001/jama.291.11.1342</pub-id><pub-id pub-id-type="pmid">15026401</pub-id></mixed-citation></ref><ref id="B3"><mixed-citation publication-type="journal"><name><surname>León</surname><given-names>A</given-names></name><article-title>A new multidisciplinary home care telemedicine system to monitor stable chronic human immunodeficiency virus-infected patients: A randomized study</article-title><source>PLoS ONE</source><year>2011</year><volume>6</volume><issue>1</issue><fpage>e14515</fpage><pub-id pub-id-type="doi">10.1371/journal.pone.0014515</pub-id><pub-id pub-id-type="pmid">21283736</pub-id></mixed-citation></ref><ref id="B4"><mixed-citation publication-type="journal"><name><surname>Kuo</surname><given-names>AMH</given-names></name><article-title>Opportunities and challenges of cloud computing to improve health care services</article-title><source>J Med Internet Res (JMIR)</source><year>2011</year><volume>13</volume><issue>3</issue><fpage>e67</fpage><pub-id pub-id-type="doi">10.2196/jmir.1867</pub-id></mixed-citation></ref><ref id="B5"><mixed-citation publication-type="journal"><name><surname>Rosenthal</surname><given-names>A</given-names></name><name><surname>Mork</surname><given-names>P</given-names></name><name><surname>Li</surname><given-names>MH</given-names></name><name><surname>Standford</surname><given-names>J</given-names></name><name><surname>Koester</surname><given-names>D</given-names></name><name><surname>Reynolds</surname><given-names>P</given-names></name><article-title>Cloud computing: A new business paradigm for biomedical information sharing</article-title><source>J Biomed Inform</source><year>2010</year><volume>43</volume><issue>2</issue><fpage>342</fpage><lpage>353</lpage><pub-id pub-id-type="doi">10.1016/j.jbi.2009.08.014</pub-id><pub-id pub-id-type="pmid">19715773</pub-id></mixed-citation></ref><ref id="B6"><mixed-citation publication-type="other"><name><surname>Armbrust</surname><given-names>M</given-names></name><name><surname>Fox</surname><given-names>A</given-names></name><name><surname>Griffith</surname><given-names>R</given-names></name><name><surname>Joseph</surname><given-names>A</given-names></name><name><surname>Katz</surname><given-names>R</given-names></name><name><surname>Konwinski</surname><given-names>A</given-names></name><name><surname>Lee</surname><given-names>G</given-names></name><name><surname>Patterson</surname><given-names>D</given-names></name><name><surname>Rabkin</surname><given-names>A</given-names></name><name><surname>Stoica</surname><given-names>I</given-names></name><name><surname>Zaharia</surname><given-names>V</given-names></name><article-title>Above the clouds: A berkeley view of cloud computing</article-title><comment>Technical Report No. UCB/EECS-2009-28</comment></mixed-citation></ref><ref id="B7"><mixed-citation publication-type="journal"><name><surname>Khazaei</surname><given-names>H</given-names></name><name><surname>Misic</surname><given-names>J</given-names></name><name><surname>Misic</surname><given-names>V</given-names></name><article-title>Performance analysis of cloud computing centers using M/G/m/m+r. queuing systems</article-title><source>IEEE Trans Parallel Distributed Syst</source><year>2012</year><volume>23</volume><fpage>5</fpage></mixed-citation></ref><ref id="B8"><mixed-citation publication-type="journal"><name><surname>Wang</surname><given-names>L</given-names></name><name><surname>von Laszewski</surname><given-names>G</given-names></name><name><surname>Younge</surname><given-names>A</given-names></name><name><surname>He</surname><given-names>X</given-names></name><name><surname>Kunze</surname><given-names>M</given-names></name><name><surname>Tao</surname><given-names>J</given-names></name><name><surname>Fu</surname><given-names>C</given-names></name><article-title>Cloud computing: A perspective study</article-title><source>New Generation Comput</source><year>2010</year><volume>28</volume><fpage>137</fpage><lpage>146</lpage><pub-id pub-id-type="doi">10.1007/s00354-008-0081-5</pub-id></mixed-citation></ref><ref id="B9"><mixed-citation publication-type="other"><collab>Kleinrock L</collab><source>Queueing Systems: Theory, vol</source><comment>Wiley-Interscience, 1975. Published in Russian, 1979. Published in Japanese, 1979. Published in Hungarian, 1979. Published in Italian 1992</comment></mixed-citation></ref><ref id="B10"><mixed-citation publication-type="other"><name><surname>Mao</surname><given-names>M</given-names></name><name><surname>Li</surname><given-names>J</given-names></name><name><surname>Humphrey</surname><given-names>M</given-names></name><article-title>Cloud auto-scaling with deadline and budget constraints</article-title><source>Grid Computing (GRID), 2010 11th IEEE/ACM International Conference</source><year>2010</year><fpage>41</fpage><lpage>48</lpage></mixed-citation></ref><ref id="B11"><mixed-citation publication-type="journal"><name><surname>Barham</surname><given-names>P</given-names></name><name><surname>Dragovic</surname><given-names>B</given-names></name><name><surname>Fraser</surname><given-names>K</given-names></name><name><surname>Hand</surname><given-names>S</given-names></name><name><surname>Harris</surname><given-names>T</given-names></name><name><surname>Ho</surname><given-names>A</given-names></name><name><surname>Neugebauer</surname><given-names>R</given-names></name><name><surname>Pratt</surname><given-names>I</given-names></name><name><surname>Warfield</surname><given-names>A</given-names></name><article-title>Xen and the art of virtualization</article-title><source>SIGOPS Oper Syst Rev</source><year>2003</year><volume>37</volume><issue>5</issue><fpage>164</fpage><lpage>177</lpage><pub-id pub-id-type="doi">10.1145/1165389.945462</pub-id></mixed-citation></ref><ref id="B12"><mixed-citation publication-type="other"><collab>WMWare Staff</collab><article-title>Virtualization overview. White paper</article-title><comment>[<ext-link ext-link-type="uri" xlink:href="http://www.vmware.com/pdf/virtualization.pdf">http://www.vmware.com/pdf/virtualization.pdf</ext-link>]. 2012-08-25</comment></mixed-citation></ref><ref id="B13"><mixed-citation publication-type="other"><name><surname>The OpenStack</surname><given-names>Project</given-names></name><article-title>OpenStack: The open source cloud operating system</article-title><comment>[<ext-link ext-link-type="uri" xlink:href="http://www.openstack.org/software/">http://www.openstack.org/software/</ext-link>]. 2012-08-25</comment></mixed-citation></ref><ref id="B14"><mixed-citation publication-type="other"><name><surname>Mell</surname><given-names>P</given-names></name><name><surname>Grance</surname><given-names>T</given-names></name><article-title>The NIST definition of cloud computing</article-title><comment>Gaithersburg: NIST Special Publication 800-145; 2011. 20899-8930</comment></mixed-citation></ref><ref id="B15"><mixed-citation publication-type="journal"><name><surname>Xiong</surname><given-names>K</given-names></name><name><surname>Perros</surname><given-names>H</given-names></name><article-title>Service performance and analysis in cloud computing</article-title><source>Proc IEEE World Conf Serv</source><year>2009</year><volume>1</volume><fpage>693</fpage><lpage>700</lpage></mixed-citation></ref><ref id="B16"><mixed-citation publication-type="other"><name><surname>Yang</surname><given-names>B</given-names></name><name><surname>Tan</surname><given-names>F</given-names></name><name><surname>Dai</surname><given-names>Y</given-names></name><name><surname>Guo</surname><given-names>S</given-names></name><article-title>Performance evaluation of cloud service considering fault recovery</article-title><source>Proc First Int’l Conf Cloud Comput (CloudCom’09)</source><year>2009</year><fpage>571</fpage><lpage>576</lpage><pub-id pub-id-type="pmid">22647629</pub-id></mixed-citation></ref><ref id="B17"><mixed-citation publication-type="journal"><name><surname>Ma</surname><given-names>N</given-names></name><name><surname>Mark</surname><given-names>J</given-names></name><article-title>Approximation of the mean queue length of an M/G/c queueing system</article-title><source>Oper Res</source><year>1998</year><volume>43</volume><fpage>158</fpage><lpage>165</lpage></mixed-citation></ref><ref id="B18"><mixed-citation publication-type="other"><collab>Tech</collab><article-title>What is Cloud Computing</article-title><comment>[<ext-link ext-link-type="uri" xlink:href="http://jobsearchtech.about.com/od/historyoftechindustry/a/cloud_computing.htm">http://jobsearchtech.about.com/od/historyoftechindustry/a/cloud_computing.htm</ext-link>]</comment></mixed-citation></ref><ref id="B19"><mixed-citation publication-type="other"><article-title>Amazon elastic compute cloud, user guide. API version ed., Amazon web service LLC or its affiliate</article-title><year>2010</year><comment>[<ext-link ext-link-type="uri" xlink:href="http://aws.amazon.com/documentation/ec2">http://aws.amazon.com/documentation/ec2</ext-link>]</comment></mixed-citation></ref><ref id="B20"><mixed-citation publication-type="other"><name><surname>Baker</surname><given-names>J</given-names></name><name><surname>Bond</surname><given-names>C</given-names></name><name><surname>Corbett</surname><given-names>J</given-names></name><name><surname>Furman</surname><given-names>JJ</given-names></name><name><surname>Khorlin</surname><given-names>A</given-names></name><name><surname>Larsonand</surname><given-names>J</given-names></name><name><surname>Leon</surname><given-names>JM</given-names></name><name><surname>Li</surname><given-names>Y</given-names></name><name><surname>Lloyd</surname><given-names>A</given-names></name><name><surname>Yushprakh</surname><given-names>V</given-names></name><article-title>Megastore: Providing scalable, highly available storage for interactive services</article-title><source>Proc Conf Innovative Data Syst Res (CIDR)</source><year>2011</year><fpage>223</fpage><lpage>234</lpage></mixed-citation></ref><ref id="B21"><mixed-citation publication-type="journal"><name><surname>Watson</surname><given-names>J</given-names></name><article-title>VirtualBox: bits and bytes masquerading as machines</article-title><source>Linux J</source><year>2008</year><volume>2008</volume><issue>166</issue></mixed-citation></ref><ref id="B22"><mixed-citation publication-type="other"><name><surname>Beloglazov</surname><given-names>A</given-names></name><name><surname>Buyya</surname><given-names>R</given-names></name><article-title>OpenStack neat: A framework for dynamic consolidation of virtual machines in OpenStack clouds – A blueprint</article-title><source>Technical Report CLOUDS-TR-2012-4, Cloud Computing and Distributed Systems Laboratory, The University of Melbourne</source><year>2012</year></mixed-citation></ref><ref id="B23"><mixed-citation publication-type="other"><name><surname>Beloglazov</surname><given-names>A</given-names></name><name><surname>Fotuhi</surname><given-names>S</given-names></name><name><surname>Alrokayan</surname><given-names>M</given-names></name><name><surname>Buyya</surname><given-names>R</given-names></name><article-title>Deploying OpenStack on CentOS using the KVM Hypervisor and GlusterFS distributed file system</article-title><source>Technical Report CLOUDS-TR-2012-3, Cloud Computing and Distributed Systems Laboratory, The University of Melbourne</source><year>2012</year></mixed-citation></ref><ref id="B24"><mixed-citation publication-type="journal"><name><surname>Burke</surname><given-names>P</given-names></name><article-title>The output of a queuing system</article-title><source>Oper Res</source><year>2010</year><volume>4</volume><fpage>699</fpage><lpage>704</lpage></mixed-citation></ref><ref id="B25"><mixed-citation publication-type="book"><name><surname>Burke</surname><given-names>PJ</given-names></name><source>The Output of a Queueing System</source><year>1956</year><publisher-name>New York: Bell Telephone Laboratories-New York</publisher-name></mixed-citation></ref><ref id="B26"><mixed-citation publication-type="journal"><name><surname>Jackson</surname><given-names>JR</given-names></name><article-title>Networks of waiting lines</article-title><source>Oper Res</source><year>1957</year><volume>5</volume><fpage>518</fpage><lpage>521</lpage><pub-id pub-id-type="doi">10.1287/opre.5.4.518</pub-id></mixed-citation></ref><ref id="B27"><mixed-citation publication-type="journal"><name><surname>Jackson</surname><given-names>JR</given-names></name><article-title>Jobshop-like queueing systems</article-title><source>Manag Sci</source><year>1963</year><volume>10</volume><fpage>131</fpage><lpage>142</lpage><pub-id pub-id-type="doi">10.1287/mnsc.10.1.131</pub-id></mixed-citation></ref><ref id="B28"><mixed-citation publication-type="journal"><name><surname>Nah</surname><given-names>F</given-names></name><article-title>A study on tolerable waiting time: how long are web users willing to wait?</article-title><source>Behavior and Information Technology</source><year>2004</year><volume>23</volume><issue>3</issue><fpage>153</fpage><lpage>163</lpage><pub-id pub-id-type="doi">10.1080/01449290410001669914</pub-id></mixed-citation></ref><ref id="B29"><mixed-citation publication-type="other"><name><surname>Hoxmeier</surname><given-names>JA</given-names></name><name><surname>DiCesare</surname><given-names>C</given-names></name><article-title>System response time and user satisfaction: an experimental study of browser-based applications</article-title><source>Proceedings of the Association of Information Systems Americas Conference</source><year>2000</year></mixed-citation></ref><ref id="B30"><mixed-citation publication-type="other"><name><surname>Shneiderman</surname><given-names>B</given-names></name><article-title>Designing the user interface: strategies for effective human-computer interaction</article-title><comment>Addison-Wesley Longman Publishing Co., Inc.; 1986. 0-201-16505-8</comment></mixed-citation></ref><ref id="B31"><mixed-citation publication-type="other"><article-title>Queue 2.0 Website</article-title><comment>[<ext-link ext-link-type="uri" xlink:href="http://www.win.tue.nl/cow/Q2/">http://www.win.tue.nl/cow/Q2/</ext-link>]. 2012-08-25</comment></mixed-citation></ref><ref id="B32"><mixed-citation publication-type="other"><article-title>Hesoft Group SCP</article-title><comment>[<ext-link ext-link-type="uri" xlink:href="http://www.hesoftgroup.com">http://www.hesoftgroup.com</ext-link>]. 2012-08-25</comment></mixed-citation></ref></ref-list></back></pmc></record>Pour manipuler ce document sous Unix (Dilib)
EXPLOR_STEP=$WICRI_ROOT/Ticri/CIDE/explor/TelematiV1/Data/Pmc/Corpus
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 000334 | SxmlIndent | more
Ou
HfdSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd -nk 000334 | SxmlIndent | more
Pour mettre un lien sur cette page dans le réseau Wicri
{{Explor lien
|wiki= Ticri/CIDE
|area= TelematiV1
|flux= Pmc
|étape= Corpus
|type= RBID
|clé=
|texte=
}}
| This area was generated with Dilib version V0.6.31. |  |