diff --git a/devdocs/todo.txt b/devdocs/todo.txt index fbc07054..4da9b9cf 100644 --- a/devdocs/todo.txt +++ b/devdocs/todo.txt @@ -2,35 +2,6 @@ -Get stress test running, need to be sure - -XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -OLD BLOCK BEFORE IMPROVING TEST REALISM KEEPING FOR COMPARISON AFTER IMPROVING TEST REALISM - all tests 15 minutes, load is peak 1m near start of test about 4m in and 5min avg, cpu is eyeball avg near end of test when it's peaking, on 6 dollar droplet in nyc values are LOAD average from droplet graphs - This is a *shared* droplet so it's possible other users are affecting the overall responsiveness etc, not clear to me if that's the case but :shrugemoji: - - 2022-09-13 16:45:00 15 users 70% cpupeak, 1.35loadpeak, .5 end load cpu 23% mem 65% - 2022-09-13 17:07:43 30 users 68% cpupeak, 1.98 loadpeak, 1.3 end load cpu 43% mem 75% - 2022-09-13 17:26:59 60 users 86% cpupeak, 5.76 loadpeak, 3.85 endload, cpu 85%!, 78% mem peaked at end ** First Errors in the test output from jmeter, priors did not error out Peak errors (87%!) 4 minutes into test then drops off, caching? This is too many errors to be reliable. - 2022-09-13 19:06:14 10 users 78% cpupeak, 1.39 loadpeak, .1 end load, cpu 15%, mem 58% - 2022-09-13 19:26:33 50 users 75% cpupeak, 4.48 loadpeak but at end weirdly, peakmem 48% *Very minor errors 1.7%error was most then dropped, found at early peak load. All load ramped up smoothly over time unlike other runs that were opposite. also watching plex maybe affecting things - 2022-09-13 19:47:04 40 users 0 errors (trying to find error range) worst appdex .63 (quote), average appdex 0.910 - - 2022-09-13 21:30:07 40 users LONG LOAD 8 hours (28,800seconds) crash test see if it crashes or keeps chugging - no crash keeps chugging, super minimal errors looking like maybe when server rebooted spontaneously a few times which is weird, down for about 20 seconds each time - maybe the reboot is not the server booting but linux systemctl or dotnet restarting the service -XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - -TODO: Stress test todo: - - - Add wider range of random record counts to fetch suitable to large data - - Add customer creation with a full set of data if possible generate random notes text (jmeter lorem ipsum) - ${__RandomString(10,abcdefghijklmnopqrstuvwxyz,)} - - Add more types of objects fetched, look for objects not fetched before and add them - - Create a memo to a random user - - search picklist randomly doesn't have to return results bonus if random list type too - - download reports? (or would this eat up resources on my test machine, a download isn't really atest of any horsepower is it?) - TODO: Get minimum server size vs user count so can sell it properly stress test to get maximum users per server config before consistent errors creep in Try with minimal server, then go up a level and try again and see what the magic numbers are for usability and reliability @@ -66,8 +37,19 @@ TODO: Get teh amount of space a HUGE seeded database consumes TODO: SUBSCRIPTION CHANGES +private const string MAXIMUM_DATA_GB_FEATURE_NAME = "MaximumDataGB"; +If license doesn't have it and it's subscrkiption then the default is 20gb ATTACHMENT / DATA CAP have a maximum attachment / data cap size that can be configured for subscriptions Settable from license or defaults in subscription to a known value, i.e. basically 20gb but can be overriden if paid for more! +DB LOCATION - set location in AyaNova data folder in POSTGRES during boot new db creation process +Should alert users via job that periodically checks for reaching limit, we will shut them down , not ayanova but + Backup must check capacity and not run if getting too big to fit and send dire alerts to everyone if it can't run + alert once per week if between 80% and 90% + alert once a day if between 90% and 95% + close server lock out all but superuser if reaches 99% capacity, stop backup from running + + + STRIP OUT METRICS (maybe some of them for both types, just not working or accurate, the db and file size stuff is useful if working properly) OPS - subscriptions don't need almost all of ops nor should they have it, is any info leaking that shouldn't go through it remove with a machete (tied to build type) DOCS - ops section of docs not relevant to subscribers, add "PERPETUAL BUILD ONLY" maybe at top or something? @@ -81,6 +63,7 @@ todo: remove from public view but keep implemented the HUGE database size seedin Instead small, medium, large, huge do tiny, small, medium, large or rename huge to something less huge sounding like largest, or maybe just remove it from the docs and offerings and keep it as an internal test thing?? +todo: on a night run with full generation see how big the db actually gets, it's surprisingly time consuming to erase it right now during testing ......................... diff --git a/server/AyaNova/util/License.cs b/server/AyaNova/util/License.cs index 3b69b002..73c6e83f 100644 --- a/server/AyaNova/util/License.cs +++ b/server/AyaNova/util/License.cs @@ -68,6 +68,10 @@ namespace AyaNova.Core //ActiveCustomerUsers subscription license private const string ACTIVE_CUSTOMER_USERS_FEATURE_NAME = "ActiveCustomerUsers"; + //Subscription maximum data folder size (includes db and all files created by AyaNova or attached etc) + private const string MAXIMUM_DATA_GB_FEATURE_NAME = "MaximumDataGB"; + private const int DEFAULT_MAXIMUM_DATA_GB = 20; + //This feature name means it's a trial key private const string TRIAL_FEATURE_NAME = "TrialMode"; @@ -160,6 +164,14 @@ namespace AyaNova.Core } } + public long MaxiumDataGB + { + get + { + return GetLicenseFeature(MAXIMUM_DATA_GB_FEATURE_NAME)?.Count ?? DEFAULT_MAXIMUM_DATA_GB; + } + } + /// /// Check for the existance of license feature /// @@ -418,7 +430,7 @@ namespace AyaNova.Core #else build = "Perpetual", #endif - // activeTechUserCount = AyaNova.Biz.UserBiz.ActiveTechUserCountAsync().Result, + // activeTechUserCount = AyaNova.Biz.UserBiz.ActiveTechUserCountAsync().Result, activeCustomerContactUserCount = AyaNova.Biz.UserBiz.ActiveCustomerContactUserCountAsync().Result, activeInternalUserCount = AyaNova.Biz.UserBiz.ActiveInternalUserCountAsync().Result }