This commit is contained in:
@@ -3,36 +3,6 @@
|
||||
|
||||
|
||||
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
|
||||
To gather:
|
||||
APPDEX average ( 0.85 or higher is the goal)
|
||||
APPDEX worst / route
|
||||
ERROR
|
||||
CPU peak percentage during test
|
||||
MEM peak percentage during test
|
||||
LOAD peack 5 minute load value during test (not super relevant but maybe in conjunction with other values a good representative)
|
||||
|
||||
|
||||
TODO: Get teh amount of space a HUGE seeded database consumes
|
||||
get the rough stats i.e. how many wo, how many quotes, how many customers users etc, just to get a feel for it
|
||||
Test with this size data once have the stress test fixed up to be more realistic
|
||||
11k customers
|
||||
1814 outside users
|
||||
500 headoffices
|
||||
3k workorders (about 11.5 per working day based on 260 working days per year)
|
||||
1k projects
|
||||
200 csr
|
||||
10k parts
|
||||
1k PO's
|
||||
48k inventory transactions
|
||||
500 part assemblies
|
||||
200 warehouses
|
||||
5k vendors
|
||||
200 service rates
|
||||
100 travel rates
|
||||
750 internal users
|
||||
Size on disk = 590mb on test server, so 1gb is about the size of a years worth of data for a small company maybe?
|
||||
|
||||
|
||||
|
||||
@@ -44,16 +14,22 @@ DOCS - ops section of docs not relevant to subscribers, add "PERPETUAL BUILD ONL
|
||||
METRIC WE DO NEED
|
||||
just a simple value showing storage space available for subscribers maybe usage over time?
|
||||
but surface outside of OPS tree in menu, in admin? backup?
|
||||
|
||||
todo: should alert users if low on disk space in dedicated subscription volume
|
||||
|
||||
todo: remove from public view but keep implemented the HUGE database size seeding as it's not really huge at all, more like small data for a years worth of a small company
|
||||
customers are huge but work orders are relatively light, would need to be double I think to come close to huge
|
||||
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: Seeding, maybe just offer one size of seeding for trialers, there's no real use to us to offer more levels for marketing or testing
|
||||
people just want to try all features, v7 only had 20 workorders
|
||||
Keep ability for us for load testing etc, but don't offer it in the UI
|
||||
|
||||
|
||||
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
|
||||
note this is important to see over time how big it gets with a continual heavy load
|
||||
|
||||
todo: test devops as production server with automated backups, upload a range of attachments, simulate crash and restore etc, run load test then backup etc see disk space consumption and make sure
|
||||
backup works adn restore works as this is obvsiouly critical.
|
||||
|
||||
TODO: Make soem SSH keys pre uploaded to DO for customers in actual usage, can't use the same key for all customers so maybe document the process of
|
||||
how to make a key quickly and do that
|
||||
.........................
|
||||
reorganize below and then whatever is most urgent
|
||||
|
||||
|
||||
Reference in New Issue
Block a user