<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Bulut-tabanlı Ortamda Yürütülen Bir Yazılım Perfor- mans Testi Deneyimi</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Ali Yamuç</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Ethem Cem Özkan</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Burak İbrahim Sevindi</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Hakan Şimşek</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Turan Bahattin Özen</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="editor">
          <string-name>Anahtar Kelimeler: Performans Testi, Yüksek Performanslı Yazılım Sistemle-
ri, Bulut-tabanlı Ortamda Performans Testi, Yazılım Performans Mühendisliği</string-name>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>TÜBİTAK BİLGEM YTE</institution>
          ,
          <addr-line>Çukurambar Mah. 1478. Cad. No: 22 Çankaya ANKARA</addr-line>
        </aff>
      </contrib-group>
      <fpage>550</fpage>
      <lpage>555</lpage>
      <abstract>
        <p>Özet. Bu bildiride, TÜBİTAK BİLGEM Yazılım Teknolojileri Araştırma Enstitüsü (YTE) tarafınca geliştirilmeye devam edilen yüksek performans, erişilebilirlik ve ölçeklenebilirlik gereksinimleri olan bir takip ve izleme projesi için bulut-tabanlı ortamda yürütülen yazılım performans test deneyimleri paylaşılmaktadır. Bu kapsamda böyle yüksek performans, erişilebilirlik ve ölçeklenebilirlik gereksinimleri olan yazılım sistemleri için performans testinin gerekliliği ve önemi üzerinde durulmaktadır. Daha sonra performans testi yürüttüğümüz projenin gereksinimlerine değinilerek; problemin zorluğu vurgulanmaktadır. Son olarak; performans test ortamının Amazon Web Services (AWS) üzerinde hazır edilmesi, performans testlerinin koşturulması, ölçevlerin (metrics) toplanması, analiz ve ayarlama (tuning) faaliyetlerinde bu projede edinilen deneyimler, sağlanan kazançlar paylaşılmakta ve ileriye yönelik hedeflere değinilmektedir.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>gibi performans ölçevleriyle tanımlanabilir. Çıkan iş oranı birim zamanda
tamamlanan işlemlerin sayısını, cevap süresi istemciden bir isteğin alınmasından istemciye
cevap dönülmesine kadar geçen süreyi, kaynak kullanım verimliliği (CPU, bellek,
disk I/O, ağ I/O vb.) ise kullanılan sistem kaynaklarının miktarını ve verimliliğini
tanımlamaktadır.</p>
      <p>
        Performans gereksinimlerinin doğrulaması ölçüme dayalı ve deneysel bir yaklaşım
olan performans testi yürütülmesinin yanı sıra analitik performans modelleriyle veya
bunların karma kullanımlarıyla da gerçekleştirilebilir. Analitik performans
modelleriyle ile mimari tasarımı daha gerçeklemeden, performans hedeflerinin sağlanıp
sağlanamayacağının değerlendirilmesi yapılabilir ve farklı ödünleşim (trade-off)
analizlerinde bulunarak olası yanlış mimari tasarım kararlarından kaynaklanabilecek büyük
maliyetlerden kurtulmak mümkün olabilir. Yazılım performans testinde yazılım
sistemi belli bir zaman dilimi boyunca belli bir iş yüküne tabi tutularak çıkan iş oranı,
cevap süresi, kaynak kullanım verimliliği gibi performans ölçevleri toplanır, sonuçlar
analiz edilir. Daha maliyetli bir yöntem olmasına rağmen ürün-ortamına yakın bir
performans test ortamının kullanılmasıyla gerçek performans ölçevlerinin sonuçları
alınır ve ürün ortamında bir sürpriz ile karşılanması önlenmiş olur. Performans
modellerini sağladığı esneklik ve maliyet faydasına rağmen içerebileceği yanlış
varsayımlar gerçekten uzaklaştırabilme olasılığına sahiptir. Bundan dolayı tüm bu teknik
ve yaklaşımları bir mühendislik disiplini içerisinde birbirlerini destekleyecek şekilde
kullanmak son yıllarda öne çıkan önemli bir konudur ve yeni bir mühendislik disiplini
olarak Smith [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] tarafından yazılım performans mühendisliği olarak ortaya atılmıştır.
Yazılım performans mühendisliği; performans problemlerini gidermek, yazılım
sistemlerinin performansını değerlendirmek ve iyileştirmek için yazılım geliştirme
süreci boyunca kullanılan sistematik, niceliksel ve analitik yaklaşımlardan oluşan yazılım
mühendisliği aktiviteleri içermektedir.
      </p>
      <p>
        Yazılım performans mühendisi, performans kaygısı yüksek olan sistem
operasyonlarını (kullanım durumları) tüm sistem operasyonlarından indirgeyebilir. Seçilen bu
operasyonların göreceli olarak ağırlıklandırılması, operasyonel profili [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ] oluşturur.
Operasyonel profile dayanarak performans test senaryoları çeşitli iş yükü modelleriyle
oluşturulur. Performans testi, iş yükü modelleri kullanılarak sistemin tamamı veya bir
kısmı üzerinde gerçekleştirilir. Farklı iş yükü modellerine göre farklı performans test
türleri oluşmaktadır. Bunların her biri farklı türdeki performans sorunlarını
giderebilir. Ortaya çıkarabildiği performans sorunlarıyla birlikte bu performans türlerinin
bazıları şunlardır:
 Yük Testi – Spesifik ve beklenen bir yük altında sistem davranışının
belirlenmesini sağlar.
 Stres Testi - Uzun bir süre yükün dramatik bir şekilde artarak sistemin
kırılma noktalarının belirlenmesini sağlar.
 Ani Yük (Spike) Testi – Yükteki dramatik ani değişimlere karşı sistemin
nasıl davrandığının belirlenmesini sağlar.
 Dayanıklılık (Endurance/Soak) Testi - Beklenen bir yükün sürekli
uygulanarak zaman içerisinde ortaya çıkan kaynak sızıntılarının belirlenmesini
sağlar.
 Ölçeklenebilirlik Testi - Artan iş yüküne göre bağlı olarak sistemin daha
fazla kaynağı doğrusal olarak artan bir şekilde kullanabildiğinin
belirlenmesini sağlar.
      </p>
      <p>
        Performans test türleri farklı ihtiyaçlara binaen ve keşfedilmesi istenen olası farklı
performans sorunları için daha fazla çeşitlendirilebilir ve bundan ötürü literatürde
daha pek çok performans test türü raporlanmıştır [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ]. Performans testini daha olgun
bir şekilde yürütebilmek için mümkün olduğunca farklı performans test türlerinden
faydalanmak gerekmektedir. Çünkü her biri performans gereksiniminin doğrulanması,
en zayıf eleman (darboğaz) tespiti, kaynak sızıntısı, ölçeklenebilirlik problemi gibi
farklı sorunlara, farklı perspektiflerden dokunmaktadır.
      </p>
      <p>Bildiri şu planlamadan oluşmaktadır. Bölüm 2’de geliştirilen takip ve izleme
projesinin performans gereksinimleri anlatılacaktır. Bölüm 3’de uyguladığımız performans
test süreci anlatılacaktır. Bölüm 4’de hazırladığımız bulut-tabanlı performans test
ortamı tanıtılacaktır. Bölüm 5’de performans testlerini koşarken, ölçevleri toplarken
ve analiz faaliyetlerinde edinilen deneyimler paylaşılacaktır.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Performans Gereksinimleri</title>
      <p>TÜBİTAK BİLGEM YTE tarafınca geliştirilmesi devam eden, vatandaş odaklı
hizmetler sunan ve yüzbinlerce kullanıcılı bir takip ve izleme sistemi projesinde
performans testlerini gerçekleştirdik. Bu projede özellikle takip ve izleme ile alakalı bir
modül, makine-makine etkileşiminin çok yüksek boyutlarda olmasından dolayı
oldukça yüksek performans gereksinimlerine sahiptir. Sistem çeşitli firmaların üretim
bantlarıyla entegre olacağından ve üretimin 7/24 devam edeceği varsayıldığından,
sistemin yüksek erişilebilirlikte olması gerekmektedir. Geliştirilmesi devam eden bu
yazılım sistemi, canlıya alındığında ilk yıllarda 19000 işlem/saniye iş çıkarma
yeteneğine sahip olması gerekirken, ileriki yıllarda en az 30000 işlem/saniye oranlarına
hızlıca çıkacağı öngörülmektedir. Bu yüzden yazılım sisteminin performans
gereksinimlerini karşılamasının yanı sıra, kesintisiz olarak kullanımda kaldığı zaman
boyunca ölçeklenebilmelidir. Ayrıca, bu modüldeki işlemlerin müşteri memnuniyeti
açısından cevap süresi maksimum 1 saniye olmalıdır. Tüm bu gereksinimler daha dar
kapsamlı olan, mevcut kullanımdaki takip ve izleme sistemlerinin değerleri göz önüne
alınarak ve uzman görüşlerine dayanılarak hesaplanmıştır.</p>
      <p>Bu performans, ölçeklenebilirlik ve erişilebilirlik gereksinimleri bir kurumsal bilgi
sistemi için oldukça eşine az rastlanabilecek, oldukça zorlu bir problemi ortaya
koymaktadır. Bu problemin üstesinden gelebilmek için yazılım geliştirme sürecinin erken
safhalarında başlayarak performans testleri tanımlanmış süreçlere uygun bir şekilde
yürütülmektedir.
3</p>
    </sec>
    <sec id="sec-3">
      <title>Performans Test Süreci</title>
      <p>Performans test sürecinde öncelikle performans gereksinimleri tanımlanır. Daha
sonra, performans testlerini yürütmek için hedeflenen ürün ortamına yakın bir test
ortamı tanımlanır ve hazırlanır. Uygulamanın operasyonel profiline göre gerçekçi ve
kilit senaryolar tanımlanır. Test verisi olarak fonksiyonel testlerde kullanılan veriler
kullanılır fakat dinamik olarak çokça üretilmesi gereken test verileri için betiklerin
hazırlanması gerekir. Dış servis bağımlılıklarını kırmak için sanal servisler
oluşturulur. Performans test tasarımı seçilen bir performans test aracıyla gerçeklenir.
Oluşturulan performans test betikleri yerel geliştirme ortamında düşük bir yükte
çalıştırılarak doğrulandıktan sonra, gerçek test ortamına aktarılır. Testin koşturulması esnasında
çevrimiçi olarak sistem kaynakları (CPU, Network I/O, Disk I/O), sunucu günlükleri
(log), cevap süresi ve çıkan iş oranı izlenerek, olası performans sorunları anlık tespit
edilmeye çalışılır. Test bitiminden sonra tüm ölçevler toplanarak kaydedilir ve
sonuçlar konsolide edilerek analiz edilir. Analiz esnasında istenilen tüm ölçevlerin kabul
edilen limitler içerisinde olduğuna ve hiçbir eşik değerinin aşılmadığına ve istenen
tüm bilgilerin toplandığına emin olunduğunda, ilgili performans testi bu
konfigürasyonda tamamlanmış olur. Eğer bir sorun gözlemlenirse darboğaz unsurlar tespit
edilmeye çalışılır. Eldeki bulgulara göre gereken hata raporları açılır ve iyileştirici
aksiyonlar planlanır. Yapılan ayarlama faaliyetlerinden sonra iyileşme olup olmadığını
anlamak için yeniden test yapılır. Buna göre gerçekleşen ilerlemeleri kayıt altına
alarak dayanaklar oluşturulur. Bu projede uygulanan bu test süreci, edinilen deneyimlere
göre sürekli olarak iyileştirilmeye devam etmektedir.
4</p>
    </sec>
    <sec id="sec-4">
      <title>AWS üzerindeki Performans Test Ortamı</title>
      <p>
        Takip ve izleme projesi sahip olduğu yüksek performans gereksinimlerinden dolayı
performans testlerini yürütmek için yüksek sunucu kapasitesine ihtiyaç duyulmuştur.
Böyle yüksek kapasiteli ortamı geleneksel bir ortam yerine bulut ortamlarda
hazırlamak; farklı teknolojilerin, konfigürasyonların ve yazılım tasarımlarının denenebilmesi
esnekliğini maliyet etkin bir şekilde sağladığı görülmüştür. Bu konuda bazı çalışmalar
[
        <xref ref-type="bibr" rid="ref16 ref17">16, 17</xref>
        ]; AWS’nin sağladığı hizmet kalitesinin ve maliyetinin alternatif bulut
hizmetlerine ve kurum içi sahipliğe göre daha iyi olduğunu niceliksel olarak göstermiştir.
Ayrıca, AWS üzerinde kurum içi bilgi birikimine sahip olunması ve ortamın
betiklerle tanımlanarak kolay yönetilebiliyor olmasından dolayı AWS tercih edilmiştir.
      </p>
      <p>Performans test ortamı 2 ayrı ortamdan oluşmaktadır. İlki takip ve izleme
sistemini, diğeri ise yükleri oluşturan JMeter ortamını içerir. Performans test aracı olarak
JMeter v2.13; açık-kaynak ve ücretsiz olması, kullanım kolaylığı, her ortamda
çalışabilir olması, güçlü bir topluluğu ve dokümantasyonu olmasından dolayı tercih
edilmiştir. Bulut-tabanlı ortam üzerinde performans testi yapılırken sunucuların
oluşturulması, gerekli ağ ayarlarının yapılması, sunucular üzerine ilgili programları
kurulması, testlerin çalıştırılması ve en son bu sunucuların silinmesi işlemlerinin yapılması
gerekmektedir. Bu işlemlerin her performans testi öncesi el ile yapılması maliyetli ve
hataya açık bir işlem olacağı için performans test ortamı AWS Cloudformation aracı
kullanılarak, betikler ile otomatik olarak oluşturulmaktadır. JMeter ortamı, GitHub
(https://github.com/oliverlloyd/jmeter-ec2) üzerinde bulunan JMeter-EC2 adlı açık
kaynak kodlu proje kullanılarak AWS üzerinde oluşturulmaktadır.</p>
    </sec>
    <sec id="sec-5">
      <title>Edinilen Deneyimler</title>
      <p>Performans testlerini yürütmek için öncelikle geliştirilmekte olan sistemin mevcut
dış sistem entegrasyonlarını sanallaştırmamız gerekti. Sanal servisler, geliştirilmekte
olan sistemin performans testleri sırasında dış sistemlere olan bağımlılıklarını kırmak,
dolayısıyla sistemin gerçek performans seviyelerini elde edebilmek için
gerekmektedir. Buradan yola çıkarak, sanal servisleri oluşturmak için Kurumsal Hizmet Veri
Yolundan istifade edilmiştir. Uygulamanın operasyonel profili, alan uzmanlarına
danışılarak belirlenmiş ve senaryolar oluşturulmuştur.</p>
      <p>Performans testleri AWS ortamında koşarken, sadece AWS’in sunduğu ölçevleri
kullanabildik. Bu ölçevlerden de sadece CPU ölçümünün sağlıklı olarak alınabildiği
ve diğer sistem kaynaklarıyla ilgili ölçevlerin toplanmasında AWS’den kaynaklı
sorun görülmüştür. İlgili sunucuların günlük analizleri her bir sunucunun ilgili dosyaları
elle kontrol edilerek yapılmış, otomatik ve konsolide bir günlük yönetimi ihtiyacı
görülmüştür. Çıkan iş oranı ve cevap süreleri ancak test bitiminde JMeter’ın sonuç
dosyasından alınabildiği için anlık olarak analizin çok sağlıklı bir şekilde
yapılamadığı tespit edilmiştir.</p>
      <p>Performans testlerinde ileride ortaya çıkması durumunda düzeltme maliyetinin
oldukça yüksek olacağı, performansla ilgili hatalar raporlanarak çözümler aranmıştır.
Raporladığımız hatalar kabaca şöyle sınıflandırılabilinir.</p>
      <p> Eş-zamanlı programlama hataları. Optimistik kilit arızaları (optimistic lock
failure), yarışma durumuna (race condition) bağlı veri tutarlılığı problemleri.
 Veritabanı sorgularındaki optimizasyon problemleri (Lazy loading yerine
eager loading yapılması gibi).
 Bazı iş kuralları uygulamanın istemci tarafında işletilirken, sunucu tarafında
yapılmaması ile ilgili hatalar.
 HTTP/JSON servis arayüzlerinin eksik, fazla ve hatalı parametreleri ve
dönen cevap mesajlarının anlaşılmayan hata mesajları içermesi gibi hatalar.
6</p>
    </sec>
    <sec id="sec-6">
      <title>Sonuç</title>
      <p>Bu bildiride, TÜBİTAK BİLGEM YTE tarafınca geliştirilmeye devam edilen takip
ve izleme sistemi projesi için gerçekleştirilen performans testlerinin niçin yapılması
gerektiğini, nasıl bir süreçle yürütüldüğünü, nasıl bir performans test ortamında
gerçekleştirildiğini ve performans testleri esnasında edinilen deneyimleri paylaştık.
İleride düzeltilmesi zor olan pek çok performansla ilgili hata daha geliştirme safhasında
müdahale edilerek çözülmüş ve ciddi bir maliyetten böylelikle sakınılmıştır. Mevcut
altyapıdaki izleme, ölçev toplama, günlük yönetimi, daha kaliteli çevrimiçi ve
çevrimdışı analiz ihtiyacı gibi alanlarda iyileştirme yapabildiğimiz takdirde geliştirilen
yazılım sisteminin performans, ölçeklenebilirlik ve erişilebilirlik hedeflerine daha
kolay bir şekilde ulaşabileceği ve ürün müşteriye teslim edilmeden istenilen
fonksiyonel olmayan kalite hedeflerine zamanında ve bütçesinde erişilebileceği
görülmüştür. Bundan dolayı, daha nitelikli bir şekilde performans testlerini yürütmek için
uygulama performans yönetimi araçlarının geliştirilmesi veya hazır araç kullanılması
zaruret olarak görülmüştür. İlerleyen günlerde daha nitelikli bir şekilde performans
testleri, analizi ve sorun çözümlemesi yapabilecek noktada olmayı ve analitik
performans modellerinden de istifade edildiğinde, daha verimli ve etkin bir şekilde yazılım
performans yönetimi yapabilmeyi hedefliyoruz.</p>
    </sec>
    <sec id="sec-7">
      <title>Kaynaklar</title>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1. Software Engineering Institute, “
          <article-title>Ultra-Large-Scale Systems: The Software Challenge of the Future”</article-title>
          , Carnegie Mellon University, Pittsburgh 2006
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Bass</surname>
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nord</surname>
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wood</surname>
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zubrow</surname>
            <given-names>D.</given-names>
          </string-name>
          , “
          <article-title>Risk Themes Discovered Through Architecture Evaluations”</article-title>
          ,
          <source>IEEE/IFIP Conference on Software Architecture (WICSA'07)</source>
          ,
          <fpage>6</fpage>
          -
          <lpage>9</lpage>
          Jan. 2007
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Weyuker</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vokolos</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          , “
          <article-title>Experience with performance testing of software systems: issues, an approach</article-title>
          ,
          <source>and case study” Trans. Softw. Eng. cilt 26 sayı 12 s.1147-1156</source>
          ,
          <year>2000</year>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Syer M. D.</surname>
          </string-name>
          ,
          <string-name>
            <surname>Shang</surname>
            <given-names>W.</given-names>
          </string-name>
          , Jiang
          <string-name>
            <given-names>Z.M.</given-names>
            ,
            <surname>Hassan</surname>
          </string-name>
          <string-name>
            <surname>A. E.</surname>
          </string-name>
          , “
          <article-title>Continuous validation of performance test workloads”</article-title>
          ,
          <source>Automated Software Engineering, s. 1-43</source>
          ,
          <year>2016</year>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5. HealthCare.gov, https://en.wikipedia.org/wiki/HealthCare.gov/ Erişim Tarihi:
          <volume>16</volume>
          /05/2016
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6. Cheng, J., “
          <article-title>Steve jobs on MobileMe”</article-title>
          . http://arstechnica.com/apple/2008/08/steve-jobs
          <article-title>-onmobileme-the-</article-title>
          <string-name>
            <surname>full-</surname>
          </string-name>
          e-mail/ Haber Tarihi:
          <year>2008</year>
          ,
          <string-name>
            <given-names>Erişim</given-names>
            <surname>Tarihi</surname>
          </string-name>
          :
          <volume>16</volume>
          /05/2016
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7. SiliconBeat:
          <article-title>Firefox download stunt sets record for quickest meltdown</article-title>
          . http://www.siliconbeat.com/
          <year>2008</year>
          /06/17/firefox-download
          <article-title>-stunt-sets-record-for-quickestmeltdown/ Haber Tarihi:</article-title>
          <year>2008</year>
          ,
          <string-name>
            <given-names>Erişim</given-names>
            <surname>Tarihi</surname>
          </string-name>
          :
          <volume>16</volume>
          /05/2016
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Benoit</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          , “
          <article-title>Nasdaqs blow-by-blow on what happened to Facebook” http://blogs</article-title>
          .wsj.com/deals/2012/05/21/nasdaqs-blow
          <article-title>-by-blow-on-what-happened-</article-title>
          <string-name>
            <surname>tofacebook</surname>
          </string-name>
          / Haber Tarihi: 2012 Erişim Tarihi:
          <volume>16</volume>
          /05/2016
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Williams</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          , “
          <article-title>Amazon web services outage caused by memory leak and failure in monitoring alarm</article-title>
          ” http://techcrunch.com/
          <year>2012</year>
          /10/27/amazon-web
          <article-title>-services-outage-caused-bymemory-leak-and-failure-in-monitoring-</article-title>
          <string-name>
            <surname>alarm</surname>
          </string-name>
          / Haber Tarihi:
          <year>2014</year>
          ,
          <string-name>
            <given-names>Erişim</given-names>
            <surname>Tarihi</surname>
          </string-name>
          :
          <volume>16</volume>
          /05/2016
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Howell</surname>
            Jr.,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dinan</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          , “
          <article-title>Price of fixing, upgrading obamacare website rises to $121 million”</article-title>
          , http://www.washingtontimes.com/news/2014/apr/29/obamacare-website
          <article-title>-fix-willcost-</article-title>
          <string-name>
            <surname>feds-</surname>
          </string-name>
          121-million/ Haber Tarihi:
          <year>2014</year>
          ,
          <string-name>
            <given-names>Erişim</given-names>
            <surname>Tarihi</surname>
          </string-name>
          :
          <volume>16</volume>
          /05/2016
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Harris</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          , “IT downtime costs $
          <volume>26</volume>
          .5 billion in lost revenue” http://www.informationweek.com/it-downtime-costs-$
          <fpage>265</fpage>
          -
          <string-name>
            <surname>billion-</surname>
          </string-name>
          in
          <string-name>
            <surname>-</surname>
          </string-name>
          lost-revenue/d/did/1097919 Haber Tarihi:
          <year>2011</year>
          ,
          <string-name>
            <given-names>Erişim</given-names>
            <surname>Tarihi</surname>
          </string-name>
          :
          <volume>16</volume>
          /05/2016
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Bondi</surname>
            <given-names>A. B.</given-names>
          </string-name>
          , “
          <article-title>Foundations of Software and System Performance Engineering: Process, Performance Modeling</article-title>
          , Requirements, Testing, Scalability, and Practice”,
          <source>AddisonWesley Professional</source>
          ,
          <year>2014</year>
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Smith</surname>
            <given-names>C.</given-names>
          </string-name>
          , “Software performance engineering”,
          <source>Performance Evaluation of Computer and Communication Systems, Lecture Notes in Computer Science cilt.729 s. 509-536</source>
          ,
          <year>2005</year>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Musa J.D.</surname>
          </string-name>
          , “
          <article-title>Operational Profiles in Software-Reliability Engineering”</article-title>
          ,
          <source>IEEE Software, cilt.10 sayı 2 s.14-32</source>
          ,
          <year>1993</year>
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Black</surname>
            <given-names>R</given-names>
          </string-name>
          ., Mitchell J.,
          <source>“Advanced Software Testing</source>
          Vol.
          <volume>3</volume>
          ”, Rocknook Computing,
          <year>2011</year>
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Marathe</surname>
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Harris</surname>
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lowenthal</surname>
            <given-names>D. K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Supinski</surname>
            <given-names>B. R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rountree</surname>
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schulz</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Yuan</surname>
            <given-names>X.</given-names>
          </string-name>
          ,
          <article-title>“A Comparative Study of High-Performance Computing on the Cloud”</article-title>
          ,
          <source>Proceedings of the 22nd Int. Symp. on High-Performance Parallel and Distributed Comp., s.239-250</source>
          ,
          <year>2013</year>
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Zhai</surname>
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Liu</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zhai</surname>
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ma</surname>
            <given-names>X.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chen</surname>
            <given-names>W.</given-names>
          </string-name>
          , “
          <article-title>Cloud Versus In-house Cluster: Evaluating Amazon Cluster Compute Instances for Running MPI Applications”</article-title>
          ,
          <source>Proceeding SC '11 State of the Practice Reports, no 11</source>
          ,
          <year>2011</year>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>