• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Snail mode for simulating vast databases when using a small test database

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    #11
    Originally posted by woohoo View Post
    If your data is too generic then your queries may not be selective enough to use indexes and you may have performance issues you would not get in production. Or if your test data is too random then indexes may be used that would not in production.
    Contention due to data distribution is an issue to be aware of too. I've build a system before that ran like treacle through a sieve in test. it turned out that they were putting through hundreds of TPS using only 50 credit card numbers. When they added more credit card numbers it flew.

    Comment


      #12
      Originally posted by minestrone View Post
      Sticking data on the cloud won't fly for most organisations that have large databases.

      Also many companies have test and dev databases that are considerably smaller than production.

      I see the relevance of what owlhoot is suggesting.
      Yep. I've seen it time and again where projects have been developed on the latest flashy kit but expected to run well on lesser machines. Graphics designers using gigantic screens and bags of RAM not thinking about the poor users with their commodity gear is one example. With SQL, there's a similar danger that developers might have fancy disk arrays or SSDs to develop on but the end users have to live with existing kit which already has a workload.

      Originally posted by minestrone View Post
      "But this page worked so much faster when we tested it before the release" is not an uncommon complaint.

      Run the query on prod, stick that time 'estimate' into the DEV and UAT phases and give the users a real feel on how it will perform on prod.
      Sounds better.

      The idea of restricting server RAM and loading up a test database on some USB2 disks has merit
      Behold the warranty -- the bold print giveth and the fine print taketh away.

      Comment

      Working...
      X