应用工程及用户数量
除了性能问题之外，基于 Web 的应用程序是否应该根据（并发）用户数量进行不同的构建？如果是这样，（例如）4、40、400 和 4000 个用户的主要区别是什么？
我特别感兴趣的是如何根据并发用户的数量使用日志记录、错误处理、设计模式等。
Apart from performance concerns, should web-based applications be built differently according to the number of (concurrent) users? If so, what are the main differences for (say) 4, 40, 400 and 4000 users?
I'm particularly interested in how logging, error handling, design patterns etc. would be be used according to the number of concurrent users.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不是这方面的专家..但这就是我的想法。
如果应用程序将由 4 个已知用户使用，则广泛使用设计模式、构建广泛的日志记录功能等可能不是很有必要 - 从某种意义上说，您投入的每一个额外的努力单位都会带来更少的回报。
但是，如果应用程序要被更多人使用，您就会担心可扩展性、安全性等。使用设计模式等可能更有意义。当然，我假设如果只有 4 个人使用某个应用程序，那么它可能不是非常关键的任务。
所以我认为你应该从简单开始，然后根据需要进行更改。然而，遵循良好的设计模式总是好的 - 理想情况下，您的设计允许您根据需要更改部件。
I am no expert in this..but here is what I think.
Using design patterns extensively, building extensive logging capability etc. may not be very necessary if the application is going to be used by 4 known users - in the sense that every extra unit of effort you put in brings in lesser rewards.
However, if the application is going to be used by more people, you have concerns such as scalability, security etc. Using design patterns etc may make more sense. Of course I am making the assumption that if its just 4 people using an app - it is probably not very mission critical.
So I believe you should start simple, and make changes as needed. However following good design patterns is always good - ideally your design allows you to change parts as needed.
aip.cd.aish 给出的答案给了我这样的想法：
我认为答案是估计给定情况下工程工作的成本与相对收益。
用户较少的应用程序给业务带来的价值也会减少，这种情况并不罕见，但您需要仔细查看个别案例。
事实上，在某些情况下，更少的用户就证明需要更多的工程工作。例如，如果您的应用程序由一些关键客户使用，除非您的产品提供比竞争对手更好的服务，否则他们会去其他地方，那么您可能有理由花时间在可靠的工程上。
具体想法：
日志记录：对于“小型”应用程序，您可能最好与用户实际交谈（...我知道...），而不是记录所有内容。对于“大型”应用程序，不加区分的日志记录可能意味着日志增长太快而没有多大用处。
The answer given by aip.cd.aish has given me this idea:
I think that the answer is to estimate the cost vs. relative benefit of engineering effort in a given situation.
It is not uncommon for apps with fewer users will add less value to the business, but you need to look carefully at individual cases.
Indeed, there are instances where fewer users justify more engineering effort. For example, if your app is used by a few key customers who will go elsewhere unless your offering offers a better service then your competitors, then you may be justified in spending time on solid engineering.
Specific ideas:
Logging: For "small" apps, you may be better off actually talking to users (...I know...) rather than logging everything. For "large" apps, indescriminate logging can mean that logs grow too quickly to be of much use.