程序启动时验证您的配置文件路径

最新推荐文章于 2024-09-11 10:28:06 发布

gryrtheee

最新推荐文章于 2024-09-11 10:28:06 发布

阅读量153

点赞数

文章标签： p2p 网络协议网络

本文链接：https://blog.csdn.net/gryrtheee/article/details/124595958

版权

你还记得那次你花了一整天试图修复一个问题，却发现你输入了错误的配置设置吗？是的。而且不止一次。

避免这一点并不简单，因为不仅是你，你所使用的框架也应该小心。但是让我概述一下我的建议。

总是在应用程序启动时验证您的配置。这涉及三件事:

首先，检查您的配置值是否正确。测试数据库连接URL、文件路径、数量和时间段。如果一个目录丢失，一个数据库不可访问，或者您已经指定了一个非数字值，而该值应该是一个数字或一段时间，您应该立即知道，而不是应用程序已经使用了一段时间。

其次，确保设置了所有必需的参数。如果需要某个属性，如果尚未设置该属性，则失败，并出现有意义的异常，而不是空的NullPointerException(例如throw new IllegalArgumentException("database.url is required"))

第三，检查配置文件中是否只设置了允许的值。如果配置未被识别，立即失败并报告。这会让你不用花一整天的时间去寻找为什么要设置“请求时间”监视t "属性没有效果。这适用于有缺省值的可选属性，并带有向预定义的允许属性列表添加新属性的额外步骤，并且可能忘记这样做而导致异常，但这不太可能浪费超过一分钟的时间。

最后一个建议的简单实现是这样的:

https://www.meipian.cn/46iou5za

Properties properties = loadProperties();

for (Object key : properties.keySet()) {

if (!VALID_PROPERTIES.contains(key)) {

throw new IllegalArgumentException("Property " + key +

" is not recognized as a valid property. Maybe a typo?");

}

实现第一个有点困难，因为它需要一些逻辑——在您的通用属性加载机制中，您不知道属性是数据库连接url、文件夹还是超时。所以你必须在知道每个属性用途的类中做这些检查。您的数据库连接处理程序知道如何使用数据库url，您的文件存储处理程序知道什么是备份目录，等等。这可以与所需的属性验证相结合。在这里，像这样的图书能会派上用场，但不会解决所有问题。

这不仅对开发有用，而且对试图配置本地服务器的项目新手也有用，最重要的是——在生产中，您可以立即发现这个版本中是否有错误配置。

最终，我们的目标是，如果所提供的配置有任何问题，就尽可能早地失败，而不是花费几个小时来查找输入错误、丢失值和意外不运行的服务。

https://www.meipian.cn/46iou5za

负载测试并不简单。这不仅仅是下载的问一些场景，然后运行。嗯，可能就是这样，但如果是这样，你就很幸运了。听起来像是“显而易见的船长在讲话”，提醒你一些可能会浪费时间的事情是有好处的。

所以，当你运行测试时，最终你会遇到一个瓶颈，然后你必须找出它在哪里。它可以是:

客户端瓶颈——如果您的负载测试工具使用HttpURLConnection，客户端发送的请您必须从那里开始，并确保足够多的请求离开您的负载测试机器
网络瓶颈——检查您的出站连接是否允许所需数量的请求到达服务器
服务器机器瓶颈——检查您的(很可能)linux服务器允许打开的文件数量。例如，如果默认值是1024，那么您最多可以有1024个并发连接。所以增加它(limits.conf)
应用服务器瓶颈——如果处理请求的线程池太低，请求可能会一直等待。如果其他一些微小的配置开关(例如，是否使用NIO，这值得另文讨论)有错误的值，这可能会降低性能。您必须熟悉服务器的性能相关配置。
数据库瓶颈——检查数据库的CPU使用情况和响应时间，看看是否是它降低了请求的速度。数据库配置不当，或者数据库服务器太小/太少，显然是一个瓶颈
应用程序瓶颈——您必须自己调查这些问题，可能需要使用一些性能监控工具(但是在选择工具时要小心，因为有许多“新的、酷的”，但是不稳定且无用的工具)。我们可以把这种类型一分为二:
- 框架瓶颈——如果你正在使用的框架有问题。这可能是一个web框架，一个依赖注入框架，一个actor系统，一个ORM，甚至是一个JSON序列化工具
- 应用程序代码瓶颈——如果您误用了工具/框架，有阻塞代码，或者刚刚编写了具有不必要的高计算复杂性的可怕代码

您必须不断地监控机器的CPU、内存、网络和磁盘I/O使用情况，以便了解何时遇到了硬件瓶颈。

一个重要的方面是能够用足够多的请求轰炸你的服务器。单台机器不够用并非不可能，特别是如果你是一家大公司，你的产品一开始就可能吸引很多客户，并且/或者提出请求也需要一些处理能力，例如加密。因此，您可能需要一个机器集群来运行负载测试。您使用的工具可能不支持这一点，因此您可能需要手动协调集群。

https://www.douban.com/doulist/150186338/

作为负载测试的结果，您必须考虑让连接等待多长时间是有意义的，以及何时拒绝它们。这由客户机上的连接超时和服务器上的注册超时(或池借用超时)控制。查看结果时也要记住这一点——太慢的响应或被拒绝的连接实际上是一回事——您的服务器无法满足请求。

https://movie.douban.com/doulist/150186338/

如果你在AWS上，有一些细节。撇开自动缩放不谈(至少在一些运行中您应该禁用它)，您需要记住ELB需要预热。运行几次测试来预热ELB(许多请求会失败，直到它正常)。此外，当使用负载平衡器并且长期连接保持打开时(例如，或者您使用WebSocket)，负载平衡器可能会让从其自身到其背后的服务器的连接永远打开，并在新的长期连接请求到来时重用它们。

总的来说，负载(性能)测试和分析并不简单，有许多可能的问题，但是在发布之前你必须做一些事情。嗯，除非你不指望超过100个用户。下次我这样做时，我会参考我自己的文章，以确保我没有遗漏什么。