[more of same
thomashartman1@gmail.com**20081014181551] hunk ./src/AppStateSetBased.hs 188
+-- bad performance for large unumbers of users (>1000, with 200 jobs/dummy user)
+-- maybe macid doesn't like serializing large quantities of data at once
+addDummyData dd = do
+  AppState ss (Users us) <- get
+  put $ AppState ss (Users (M.union us dd) )
+
+addDummyUser (un,uis) = do
+  AppState ss (Users us) <- get
+  us' <- M.insertUqM un uis us
+  put $ AppState ss (Users us' )
+
hunk ./src/AppStateSetBased.hs 218
+     , 'addDummyData
+     , 'addDummyUser
hunk ./src/Controller.hs 86
-               -- faster, insert all users at once
+               -- faster, insert all users and all jobs in one transaction
+               -- fast for small numbers of users, but slow for >1000
hunk ./src/Controller.hs 89
+               , dir "atomicinsertsalljobs" [ spStressTest  ("atomic inserts, all jobs at once",insertusAllJobs) rglobs] 
hunk ./src/ControllerStressTests.hs 40
-atomic_inserts = mapM_ insertu . M.toList . users
hunk ./src/ControllerStressTests.hs 41
+
hunk ./src/ControllerStressTests.hs 50
-        liftIO $ putStrLn $ fname ++ " stresstest, elapsedtime: " ++ stressTestTime
+        liftIO $ putStrLn $ fname ++ " stresstest, " ++ (show n) ++ " users, elapsedtime: " ++ stressTestTime
hunk ./src/ControllerStressTests.hs 90
--- insert a whole mess of users -- less realistic, but faster way
+
+-- insert a whole mess of users -- less realistic, but maybe faster way
hunk ./src/ControllerStressTests.hs 93
+
hunk ./src/ControllerStressTests.hs 95
-insertus = update . ( InitializeDummyData . users )
-   
+insertus us = update . ( AddDummyData . users ) $ us
+
+--insertuAllJobs :: (MonadIO m) => (UserName, UserInfos) -> Users -> m ()
+insertusAllJobs = mapM_ insertuAllJobs . M.toList . users 
+insertuAllJobs (u, uis) = do
+  update $ ( (AddDummyUser (u,uis)) ) 
+  liftIO $ putStrLn $ "insertuAllJobs, added user: " ++ (unusername u)
hunk ./src/ControllerStressTests.hs 104
+atomic_inserts = mapM_ insertu . M.toList . users
hunk ./src/ControllerStressTests.hs 110
-  liftIO $ putStrLn $ "added user" ++ (unusername u)
+  liftIO $ putStrLn $ "insertu, added user: " ++ (unusername u)
hunk ./src/MiscMap.hs 18
+  , Data.Map.union
hunk ./templates/macidstresstest.st 49
-   transactions. But, it's a good way to load a lot of data and see how this app performs -- say, with 100,000 users. (?)
-l
+   transactions. And it's only faster for small numbers of users: 
+
+<br>Hm... better than O(n) performance for small numbers of users, worse for larger.
+<br>one big insert stresstest, 20 users, elapsedtime: 5 secs
+<br>one big insert stresstest, 200 users, elapsedtime: 12 secs
+<br>one big insert stresstest, 1000 users, elapsedtime: 446 secs
+<br>with 200 users it was ok (12 seconds), but with 1000 users seems to be churning ram and still going after 2 minutes
+<br>Perhaps if you're inserting large amounts of data, better to break things up, eg 1 insert per user,
+<br>and insert includes inserting dummy jobs
+
+<p>Then there's <a href=/tutorial/stresstest/atomicinsertsalljobs/20>stresstest/atomicinsertsalljobs/20</a>.
+   Here, there is one insert per user, but all jobs get inserted at once. Can I insert 100000 users this way?
+
+
hunk ./todo 3
+  How much does more ram cost?
+    Linode has ~3GB ram servers available for $150/month. What about dreamhost?
+    scam offers of 8GB ram vps for $200/month but they're... well... scams
+ 
hunk ./todo 26
+  notes... after 1000 user insert (one big, but don't think it matters)
+    thartman@thartman-laptop:~/happs-tutorial>ls -lth _local/happs-tutorial_state/ | head
+    -rw-r--r-- 1 thartman thartman  22M Oct 14 14:21 events-0000000101
+    top: 
+	PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  SWAP COMMAND
+      23961 thartman  20   0  443m 185m 2132 S  0.0 38.1   1:24.28 257m happs-tutorial
+
+      PID   USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
+      23961 thartman  20   0  443m 185m 2132 S  0.0 38.1   1:24.28 happs-tutorial
+