网络中的性能因素
有时,我只是想知道是否以处理用户请求的工作线程
为代价,添加一个带有单线程查询和更新数据库服务器的线程队列
是否会高效是否使用资源,以及它会如何影响应用程序的整体性能(以每秒回复数
为单位)?
然而,由于我只是一个业余爱好者,没有真正的商业项目,所以我通常会因为想太多而放弃。我研究但没有找到相关答案。
那么,在托管和非托管环境中编写高性能 I/O(特别是网络)应用程序时,还应该考虑哪些其他因素呢?
Sometimes I just go around in circles wondering whether adding a thread queue
with a single thread querying and updating a database server at the cost of a worker thread
processing user requests would be efficient resources usage or not, and how would it impact overall performance of the application in terms of number of replies/sec
?
However, since I am merely a hobbyist with no real business projects, I usually end up giving up because of too much thinking about it. I research but I find no relevant answers.
SO what might be other factors that one shall take into account when programming high performance I/O (networking specifically) applications in both managed and un-managed environments?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
对您来说值得研究的领域之一是操作系统概念。许多计算机科学学位都提供这方面的课程。
听起来您的机器上有一个假设的应用程序正在向数据库发出请求,并且您对线程化该假设的应用程序是否会提高其性能感兴趣。
作为一名性能测试人员,我可以告诉您系统性能完全取决于权衡和优先级。即您想要 UI 超级响应,还是想要使用绝对最少的系统资源?
在这种情况下你很幸运,你想要平衡的资源并不互相争夺。数据库方面就是我们所说的 I/O,线程方面就是 CPU。应用程序往往受 I/O 限制或 CPU 限制,有一些应用程序两者兼而有之。在 I/O 密集型应用程序中,在更快的 CPU 中切换不会加快速度太多,反之亦然。
如果您添加额外的线程,当且仅当您的网络有时间进行额外的网络 IO 时,这才会有帮助。添加额外的线程不会以无法处理的方式增加 CPU 的负载,因为请求将发送到数据库并且线程将阻塞。一旦请求返回到您的机器,就会抛出一个中断,并且您的线程将从等待队列中拉出。
真正的问题是:您希望数据库变得多好?
One of the areas that would be good research for you would be Operating Systems Concepts. Many Computer Science degrees offer a course in this.
Sounds like you have a hypothetical application on your machine making requests of a database and you are interested if threading this hypothetical application will increase its performance.
Having worked as a performance tester I can tell you system performance is all about trade offs and priorities. i.e. do you want the UI super responsive, or do you want to use the absolute minimum system resources?
In this case you are lucky, the resources you want to balance are not in contention for each other. The Database Side of things is what we call I/O and the threading side of things is CPU. Applications tend to be I/O bound or CPU bound, a few are both. In an I/O bound application switching in a faster CPU will not speed things up much, and vice-versa.
If you add additional threads this will help if and only if your network has time for extra network IO. Adding extra threads will not increase the load on the CPU in a way that it won't be able to handle, since the request will be made to the database and the thread will block. Once the request is returned to your machine an interrupt will be thrown and you thread will be pulled off of the waiting Queue.
The real question is: How nice do you want to be to your database?