首页 文章 精选 留言 我的

精选列表

搜索[性能分析]，共10000篇文章
优秀的个人博客,低调大师

知识卡片 回归性能度量 Log Loss

对数损失 Log Loss 又称交叉熵损失 cross-entropy loss，两者名称不同，其实是等价的 ，常用于评价逻辑回归和神经网络。 什么是逻辑回归 Logistics Regression？ 与线性回归估计出Y的是一个连续型的计量数值不同，逻辑回归其实是一个分类方法。在二元逻辑回归中应变量Y是0和1，Y属于分类数据，估计结果是一个概率，自变量是可以包含多个对因变量有影响的因素，可以是连续也可是分类数据；通过逻辑回归，得出每个自变量的权重以及一个事件发生的概率。 二类分类问题的Log Loss: 注：pr 是按照回归模型得出的概率 举例说明： 假设有四个测试样本，y_true 列表是样本的真实值，y_pred 列表中有四个元素，每个样本元素有两个数值，分别表示不同类标签(0和1)的预测概率，其和为1。y_pred中的第一样本的两个元素[.9, .1] 表示样本1有90%的概率属于标签y=0, 10%的概率属于标签y=1;依次计算每个样本的逻辑损失，以e为底数算对数值，样本求平均得出Log Loss。 多类分类的交叉熵（cross-entropy loss）损失： 交叉熵公式中，N为测试样本总数，Yi,k 表示第 i 个样本中的第 k 个标签的真实值。pi,k 表示预测值。 举例说明： 好文章，我在看❤ 本文分享自微信公众号 - DataScience（DataScienceTeam）。如有侵权，请联系 support@oschina.cn 删除。本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
2020-08-22
优秀的个人博客,低调大师

性能调优-Java SDK 调优

环境准备 使用 Java 1.8 及以上版本。 查看版本执行命令java -version查看Java版本 下载SDK 直接通过 GitHub 下载 安装SDK，在Maven项目中加入依赖项（推荐方式） <dependency> <groupId>com.aliyun.oss</groupId> <artifactId>aliyun-sdk-oss</artifactId> <version>2.8.3</version> </dependency> 初始化的参数设置 日志调优参数 一般情况下不会开启日志功能，很多用户都是开启日志 log4j 后写变慢了；网上有很多关闭的方法可以找下开源的处理文档关闭掉，如果用户配置了log4j的属性文件， 需要在那个
2020-04-20
优秀的个人博客,低调大师

Kubernetes 1.16 与 1.14性能对比

测试环境 阿里云 ACK 1.16.6 3master 3worker(4c 8g) 独占版, kubemark 模拟 100 个 node； 阿里云 ACK 1.14.8 3master 3worker(4c 8g) 独占版, kubemark 模拟 100 个 node。 测试指标 PodstartuplatencySaturate(饱和测试) 在 1 个 namespace 下创建 replicas 为 3000 的 deployment,记录每个 pod 所需时间，按照时间大小排序后得到（50 90 99 百分点结果）。 Podstartuplatencylatency(存量测试) 在已创建 3000 个 pod 的场景下，连续创建 500 个 replicas 为 1 的 deployment，测试 pod 的创建时间。 吞吐量 在创建 pod 的过程中，测试每秒创建的 pod 个数。 api 响应时间 在整个测试过程(创建 pod，删除 pod)中，api-server 收到请求到响应的时间汇总，按 verb、resouce、scope、percentage 区分。 实验结果 PodstartuplatencySaturate(ms) 1.16 PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup 50 0 1000 1044.237 1749.131 1749.184 90 0 1000 1640.885 2401.273 2401.273 99 0 1000 2126.116 2958.44 2958.44 1.14 PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup 50 0 1000 1083.588 1836.33 1838.244 90 0 1000 1790.928 2610.571 2611.449 99 0 2000 2852.53 4303.789 4303.789 对比: 空载下运行3000个pod,50%pod启动时间1.16相比1.14快5%左右。 90%的pod启动时间，1.16启动时间提升3%-10%，99%的pod启动时间上1.16提升最大，速度提升25%-50%。在最坏情况下，1.16的效果明显好于1.14. Podstartuplatency(ms) 1.16 PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup 50 0 1000 1004.569 1727.642 1727.662 90 0 1000 1692.732 2414.719 2429.138 99 0 1000 2124.746 2892.659 2897.378 1.14 PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup 50 0 1000 1046.108 1772.073 1774.335 90 0 1000 1772.192 2613.083 2613.083 99 0 1000 2260.846 2959.74 2959.74 对比 在存量测试下，50% pod 启动时间上， 1.16 效率提升 3%；90% 和 99% pod 的启动时间上，1.16 效率提升 5%。总体来说 1.16 效果略微好于 1.14。 吞吐量(个数) 版本 average 50 90 99 1.14 19.354 20 20 23.6 1.16 19.354 20 20 24.2 对比 在创建 pod 过程中，50%、90% 和平均情况下，1.14 和 1.16 创建 pod 吞吐量相同； 99 分位点情况，1.16 提升 3%。在最坏情况下，1.16 的效果优于 1.14。 api 响应延时(ms) 1.14 Resource Scope Verb Perc50 Perc90 Perc99 pods namespace DELETE 25.279 45.502 54.906 pods namespace GET 25.17 45.307 49.837 pods namespace LIST 25 45 49.5 （Pod） Resource Scope Verb Perc50 Perc90 Perc99 nodes cluster PATCH 25.41 45.74 78.87 nodes cluster LIST 25 45 49.5 nodes cluster GET 25 45 49.5 （Nodes） 1.16 Resource Scope Verb Perc50 Perc90 Perc99 pods namespace DELETE 25.432 45.779 76.445 pods namespaces GET 25.018 45.033 49.536 pods namespaces LIST 25 45 49.5 （Pod） Resource Scope Verb Perc50 Perc90 Perc99 nodes cluster PATCH 25 45 49.5 nodes cluster LIST 25 45 49.5 nodes cluster GET 25 45 49.5 （Nodes） 对比 统计整个创建 Pod 和删除 Pod 过程中 api 响应时间，将其根据时间大小排序后对 pod 和 node 操作选取时间最长的三项进行对比。 对比可以发现，对 pod 和 node 操作的 api 时间，1.14 和 1.16 基本一致： 最坏情况下（99 分点）对 pod 的 delete 操作时间，1.14 相比 1.16 要快 30% 左右； 对 node 的 PATCH 操作，1.16 相比 1.14 要快 40% 左右； 对于其它 apicall（如 LIST 和 GET）二者并没有明显差距。 总结 总体来说，1.16 版本相对于 1.14 版本的主要提高在无状态 Pod（Pod 不用挂载 configmap、secret 等 volume）的创建速度上： 1.16 和 1.14 的 pod 创建时间都满足 Kubernetes sig-scalability 定义的 SLA(（99% 的已拉取好镜像的pod 启动时间在 5s 内）； 但在最差情况下（99 分位点），1.14 版本的 Pod 创建速度接近 5s，表现差于同指标下 K8s 1.16 的 3s。 说明 1.16 版本更适用于对 pod 创建速度有要求（如弹性业务）的场景。
2020-03-03
优秀的个人博客,低调大师

PHP 高性能 Excel 扩展 1.2.7 发布

为什么使用 php-ext-xlswriter xlswriter是一个PHP C扩展，可用于在Excel 2007+ XLSX文件中写入多个工作表的文本，数字，公式和超链接。 它支持以下功能： 100％兼容的Excel XLSX文件 完整的Excel格式 合并单元格 自动筛选 图表 数据验证和下拉列表 工作表PNG / JPEG图像 用于写入大文件的内存优化模式 适用于Linux，FreeBSD，OpenBSD，OS X，Windows 编译为32位和64位 FreeBSD许可证 唯一的依赖是zlib 更新内容： 修复 循环导出多个文件段错误 新特性 读取xlsx文件 新增图表类型（圆环图、面积图、直方图） 单元格边框样式（薄边框风格、中等边框风格、虚线边框风格、虚线边框样式、厚边框风格、双边风格、中等虚线边框样式、.......) 基准测试 测试环境: Macbook Pro 13 inch Intel Core i5 16GB 2133MHz LPDDR3 Memory 128GB SSD Storage. 导出 两种内存模式，导出100W行数据，单行27列，每个单元格19个中文字符 常规模式: 耗时 29S，内存占用 2083MB； 固定内存模式: 耗时 52S, 内存占用 <1MB； 读取 读取 100W 行数据，每行1列，单元格数据为int 全量读取: 耗时 3S, 内存占用 558MB； 游标读取: 耗时 2.8S, 内存占用 <1MB；
2019-09-09

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册