我有一个客户端 - 服务器应用程序我正在尝试优化。 我建立了一个psydo-client来攻击我的服务器api。 我在一个盒子上运行客户端&另一个服务器。 我试图根据每个本地系统的本地系统时钟来关联记录时间的两个事件之间的某些事件的时间。 客户端发送请求并记录该时间。 服务器接收该请求并记录该时间。 服务器执行它处理表单/发送响应,记录该时间。 客户端记录完成接收响应的时间。
最终,我尝试做的是通过客户的请求发送和响应接收来衡量吞吐量。
我是否因为尝试有意义地关联两个系统上的时钟而错过了什么?这甚至可能吗?如果是这样怎么办?你如何衡量/改善这个吞吐量?
目前,我的客户正在告诉我,对于19,000多笔交易,我每秒钟收到25个请求 - 发送到响应 - 或者平均间隔为0.04秒。 但是服务器上的两个时间戳告诉我,我在转换一个事务,请求收到响应 - 平均回复率为0.020秒(按比例增加容量〜最大值:50个事务/秒) 含义1/2从开始到结束的时间是数据'在线' (表示Vince Vaughn)。 如果我必须将线路上的时间视为固定而且只能优化服务器周转时间,并且假设我可以将其减少到0,那么我的最大througt-put可以不超过每秒50个事务。 我认为这可以减少到1/100。对于1G网络来说,只有50个交易/秒似乎疯狂,其中一个数据包只运行一个交换机并且整个长度大约为50'电缆。
那么如何关联两个系统时间? 你如何测量这个吞吐量?
答案 0 :(得分:2)
这是一个非常酷的测试 - 你的技术听起来像是一个很好的解决方案。
您是否正在保存日期&时间答案在哪里?可能是时差(分别为0.04和0.02秒)是由于长期如何'记录那些日期需要吗?例如,如果您保存到数据库,并且可能需要一些时间来完成插入/更新,因为类似于带有索引的大表等等?
EDIT 我尝试使用WCF服务器进行下面的模拟&客户端在同一台机器上运行 - 消除WCF本身因任何原因可能会变慢。看起来情况并非如此,所以我只建议尝试查看事件记录是否可能导致延迟,或者网络设置确实存在一些奇怪的延迟
我的服务器代码:
public interface IServiceWCF
{
[OperationContract]
DateTime TestConnectionSpeed(DateTime messageSentFromClientTime, out DateTime messageReceivedAtServerTime, out int millisecondsBetweenClientSentAndServerReceived);
}
public class ServiceWCF : IServiceWCF
{
public DateTime TestConnectionSpeed(DateTime messageSentFromClientTime, out DateTime messageReceivedAtServerTime, out int millisecondsBetweenClientSentAndServerReceived)
{
messageReceivedAtServerTime = DateTime.Now;
TimeSpan span = messageReceivedAtServerTime - messageSentFromClientTime;
millisecondsBetweenClientSentAndServerReceived = (int)span.TotalMilliseconds;
return DateTime.Now;
}
}
我的客户代码
int millisecondsBetweenClientSentAndServerReceived;
DateTime clientSent = DateTime.Now;
DateTime serverReceived;
DateTime serverSent = wcfService.TestConnectionSpeed(clientSent, out serverReceived, out millisecondsBetweenClientSentAndServerReceived);
DateTime responseReceived = DateTime.Now;
TimeSpan span = responseReceived - serverSent;
int millisecondsBetweenServerSentAndClientReceived = (int)span.TotalMilliseconds;
Console.WriteLine("Message sent from client at {0} - server received {1} milliseconds later at {2} - server response sent at {3} - was received at client {4} milliseconds later at {5}",
clientSent,
millisecondsBetweenClientSentAndServerReceived,
serverReceived,
serverSent,
millisecondsBetweenServerSentAndClientReceived,
responseReceived);
答案大多非常快 - 1毫秒 - 见示例输出:
Message sent from client at 3/24/2017 3:56:22 PM - server received 1 milliseconds later at 3/24/2017 3:56:22 PM - server response sent at 3/24/2017 3:56:22 PM - was received at client 1 milliseconds later at 3/24/2017 3:56:22 PM
答案 1 :(得分:0)
去过那里,这就是我做的。
让客户端记录请求发送的时间并将其发送到服务器。
当服务器收到服务器时,服务器会计算客户端报告的TimeSpan
以及服务器自己的DateTime.Now
。
让服务器记录相对于TimeSpan
或DateTime.Now.
减去 (tsVariable);
的时间
您可以(略微*)将服务器视为“客户端”的录制时间。时钟。
您需要Subtract
区别,因为如果服务器的时钟比客户端略高一点,则减去差异以使服务器{{1} }更接近地反映客户端的相对DateTime.Now
。在这种情况下,TimeSpan将是(+)正值。如果服务器的时钟稍微落后于客户端,那么TimeSpan将是( - )否定的。但仍然减去DateTime.Now
。这将是所谓的"减去负数"这与将TimeSpan
添加到相关客户TimeSpan
的服务器DateTime.Now
相同。
当响应返回到客户端时,让客户端再次记录它自己的时钟以记录收到的最终响应。服务器无需向客户端报告其时间。
*下方是客户端首次开发报告给服务器的时间与服务器收到该报告时的时间之间的滴答,然后计算DateTime.Now
未知任何一边。但我不得不相信这并不是过分重要的,或者至少不是在务实的意义上。
我玩的另一个场景是让客户首先获得服务器的时间。这应该是尽可能超级提取。
让客户计算TimeSpan
,在记录和报告服务器中使用它,......你可能会发现这种努力水平并没有带来很多好处。
一个HIGH-END选项是第三个系统为您录制另外两个系统的时间,它将不断记录两个系统之间的时间差异,并且它自己的时钟和/或调整时钟。两个系统。