数据通信中的服务器处理速度
我正在尝试确定客户端设备（移动设备）和服务器之间通信的最有效方式是什么。
目前我有一个通用的 Web 服务，它使用反射来传递特定方向的请求。我找到了可以重用代码的区域，但这会导致在请求中发送更多参数。
是否会更有效：
a) 发送参数并重用代码。
或者
b) 向服务器发送最少数量的参数，并为每个不同的请求创建单独的方法。
这是我第一次创建移动应用程序，并且认为在这种情况下了解最有效的通信方式会很高兴。
任何回复将不胜感激。
I'm trying to decide what would be the most efficient way to communicate between client device (mobile) and server.
Currently I have a generic web service that uses reflection to pass requests in specific directions. I have found area where I can re-use code, but it would result in sending more parameters in the request.
Would it be more efficient to:
a) Send the parameters and re-use code .
or
b) Send the minimum number of parameters to the server and create separate methods for each different request.
This is my first time creating a mobile application and thought it would be nice to know the most efficient means of comms, under these circumstances.
Any reply is greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
确切的答案主要取决于带宽和延迟。尽管两者相关，但并不完全相同。
考虑极端情况：如果您的链路能够提供千兆字节每秒的带宽，但每个数据包需要 40 分钟，那么您显然会尽力减少对话框，并在每个数据包中发送比您需要的更多的数据，只是为了减少往返次数。
如果您有 110 波特率的串行链路，但延迟为 0.001 秒，那么发送尽可能少的数据并执行对话框来请求并仅接收所请求的信息是最有意义的。
这个决定几乎从来没有这么明显：大多数情况下我们有合理的带宽和足够合理的延迟，所以这个决定更难做出。根据我的经验，移动应用程序感觉它们的延迟非常差（我的手机刚刚向三个不同的站点返回 ping 时间在 4000 到 200 毫秒之间；平均为 300 毫秒），这就是为什么“移动网页”将页面分解为超过一页阅读起来非常糟糕——您可能会花更多的时间等待内容到达，而不是在某些网站上实际阅读。
但一旦传输开始，他们感觉足够快——下载兆字节的图像似乎并没有那么糟糕，至少对于我手里拿着、电池运行近一周而不需要充电的东西来说不是这样。
在不知道您所说的确切数字的情况下，我建议错误地使用更少的数据包发送更多的数据——尽可能避免往返暂停。如果一切都失败了，测量 - 找到平均延迟，计算您正在考虑的数据包大小，并计算与不同的人进行“对话”需要多长时间参数。
The exact answer depends mostly on bandwidth and latency. Though the two are related they are not identical.
Consider the extremes: if your link is capable of gigabyte-per-second bandwidth but every packet takes 40 minutes, you would obviously do best to minimize dialogs and send more data than you need to in every packet, just to reduce the number of round-trips it takes.
If you've got a 110 baud serial link but latency is 0.001 seconds, then sending as little data as possible and performing dialogs to ask for and receive only the information requested makes the most sense.
The decision is almost never this obvious: mostly we have reasonable bandwidth and reasonable-enough latency, so the decision is harder to make. In my experience, mobile applications feel like they have pretty poor latency (my phone just now returned ping times between 4000 and 200 milliseconds to three different sites; 300 ms was average) which is one reason why "mobile webpages" that break a page into more than one page are so horrible to read -- you can spend more time waiting for content to arrive than actually reading on some sites.
But once the transfers get going, they feel quick enough -- downloading megabytes for images doesn't seem so bad, at least not for something I hold in my hand and runs on batteries for nearly a week without re-charging.
Without knowing the exact numbers you're talking about, I'd recommend erring towards fewer packets sending more data -- avoid round-trip pauses wherever you can. If all else fails, measure -- find the average latency, calculate the packet sizes you're thinking about, and do the math on how long it would take to carry out the "conversations" with the different parameters.