You are looking at the Load Generators....Why are you not looking at the servers? You should have a minimum of three load generators involved in any given test, n-1 for primary load and one reserved for control load (one user of each type). If the control load and the primary load both experience the same issue (server stops at 450) then it is a server issue, not a load generator one. If the control load response times are highly differentiated from the primary load response times then you have a load generator issue where you are exceeding resources. Your logging should be at maximum log on error only during the test. Anything more and you are likely to engage the disk on your load generators as a speed brake in your test. This would not manifest as users being refused at above level 'x' (such as 450 in this case) but as slowed users. Also, watch your swap level. For some reason, all performance manufacturers have not marked their virtual user code as non-swappable, so in a situation where you do not have enough physical memory (but plenty of address space) to run your intended virtual user level then you can have a load generator swapping itself to death. How this is manifested is no different than too high a logging level, slowed users. Your control group of only one virtual user of each type on the control PC would be unaffected and would not show the slowed performance.
Now you know how much users your app can hold, and you need to fix the app. BTW, check that your pacing, think time, and other runtime settings match realistic load.