博客 (99)

与 2.X 不同的是,待审核的主题和回复是分开两张表存放的:

pre_forum_thread_moderate

pre_forum_post_moderate


字段 status 值含义:

0:未审核

1:已忽略

不在该表中的为已通过。


xoyozo 5 年前
5,387

按这两篇文章部署即可:

ASP.NET Core 缓存(Cache)之 Redis 缓存

ASP.NET Core 会话状态(Session State)


存储内容示例:

image.png

图中,

第 1 项为浏览器 A 中,在 Session 中设置键 count 值为 1 的结果;

第 2 项为浏览器 B 中,在 Session 中设置键 count 值为 3 的结果;

而第 3 项为设置 Cache 键 count 值为 8 的结果。


xoyozo 5 年前
5,611

按这两篇文章部署即可:

ASP.NET Core 缓存(Cache)之 SQL Server 缓存

ASP.NET Core 会话状态(Session State)


存储内容示例:

image.png

图中,

第 1 项为浏览器 A 中,在 Session 中设置键 count 值为 3 的结果;

第 3 项为浏览器 B 中,在 Session 中设置键 count 值为 1 的结果;

而第 2 项为设置 Cache 键 count 值为 5 的结果。

xoyozo 5 年前
4,227

ASP.NET Core 缓存 Caching 提供了包括但不限于以下几种存储方式:

内存缓存:https://xoyozo.net/Blog/Details/aspnetcore-memory-cache

SQL Server 缓存:https://xoyozo.net/Blog/Details/aspnetcore-sql-cache

Redis 缓存:https://xoyozo.net/Blog/Details/aspnetcore-redis-cache

MySQL 缓存:https://xoyozo.net/Blog/Details/aspnetcore-mysql-cache


本文介绍内存缓存

Memory Caching

1.新建一个 ASP.NET Core 项目,选择 Web 应用程序,将身份验证 改为 不进行身份验证。

2.添加引用

Install-Package Microsoft.Extensions.Caching.Memory

3.使用

在 Startup.cs 中 ConfigureServices

public void ConfigureServices(IServiceCollection services)
{
    services.AddMemoryCache();
    // Add framework services.
    services.AddMvc();
}

然后在

public class HomeController : Controller
{
    private IMemoryCache _memoryCache;
    public HomeController(IMemoryCache memoryCache)
    {
        _memoryCache = memoryCache;
    }

    public IActionResult Index()
    {
        string cacheKey = "key";
        string result;
        if (!_memoryCache.TryGetValue(cacheKey, out result))
        {
            result = $"LineZero{DateTime.Now}";
            _memoryCache.Set(cacheKey, result);
        }
        ViewBag.Cache = result;
        return View();
    }
}

这里是简单使用,直接设置缓存。

我们还可以加上过期时间,以及移除缓存,还可以在移除时回掉方法。

过期时间支持相对和绝对。

下面是详细的各种用法。

public IActionResult Index()
{
    string cacheKey = "key";
    string result;
    if (!_memoryCache.TryGetValue(cacheKey, out result))
    {
        result = $"LineZero{DateTime.Now}";
        _memoryCache.Set(cacheKey, result);
        //设置相对过期时间2分钟
        _memoryCache.Set(cacheKey, result, new MemoryCacheEntryOptions()
            .SetSlidingExpiration(TimeSpan.FromMinutes(2)));
        //设置绝对过期时间2分钟
        _memoryCache.Set(cacheKey, result, new MemoryCacheEntryOptions()
            .SetAbsoluteExpiration(TimeSpan.FromMinutes(2)));
        //移除缓存
        _memoryCache.Remove(cacheKey);
        //缓存优先级 (程序压力大时,会根据优先级自动回收)
        _memoryCache.Set(cacheKey, result, new MemoryCacheEntryOptions()
            .SetPriority(CacheItemPriority.NeverRemove));
        //缓存回调 10秒过期会回调
        _memoryCache.Set(cacheKey, result, new MemoryCacheEntryOptions()
            .SetAbsoluteExpiration(TimeSpan.FromSeconds(10))
            .RegisterPostEvictionCallback((key, value, reason, substate) =>
            {
                Console.WriteLine($"键{key}值{value}改变,因为{reason}");
            }));
        //缓存回调 根据Token过期
        var cts = new CancellationTokenSource();
        _memoryCache.Set(cacheKey, result, new MemoryCacheEntryOptions()
            .AddExpirationToken(new CancellationChangeToken(cts.Token))
            .RegisterPostEvictionCallback((key, value, reason, substate) =>
            {
                Console.WriteLine($"键{key}值{value}改变,因为{reason}");
            }));
        cts.Cancel();
    }
    ViewBag.Cache = result;
    return View();
}


Distributed Cache Tag Helper

在 ASP.NET Core MVC 中有一个 Distributed Cache 我们可以使用。

我们直接在页面上增加 distributed-cache 标签即可。

<distributed-cache name="mycache" expires-after="TimeSpan.FromSeconds(10)">
    <p>缓存项10秒过期-LineZero</p>
    @DateTime.Now
</distributed-cache>
<distributed-cache name="mycachenew" expires-sliding="TimeSpan.FromSeconds(10)">
    <p>缓存项有人访问就不会过期,无人访问10秒过期-LineZero</p>
    @DateTime.Now
</distributed-cache>

这样就能缓存标签内的内容。


L
转自 LineZero 5 年前
7,656

错误如下:

image.png

解决方法:

在“解决方案资源管理器”中点击项目右键,选择“编辑项目文件”

image.png

手动添加内容:

<PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.3" />

image.png

完成。如果编译出错,关闭项目并重新打开项目再试。

转自 听雨的人 5 年前
7,164

Orbi 型号命名规则:

套装:RBK

主体:RBR

分身:RBS、RBW 等


套装对比:


小米 Mesh

RBK13

RBK20

RBK30

RBK40

RBK50

CPU

高通 IPQ4019 四核 717MHz

四核 710MHz

ROM

128MB

-

-

-

-

-

内存 RAM

256MB DDR3

512MB

闪存 Flash

-

256MB

4GB

包装内容

2 个(不分子母)

1 个 RBR10

1 个 RBS10

1 个 RBR20

1 个 RBS20

1 个 RBR40

1 个 RBW30 插墙式

1 个 RBR40

1 个 RBS40

1 个 RBR50

1 个 RBS50

速度

AC1300 双频

1300Mbps 电力线

1000M 有线

AC1200 双频段 

2.4GHz 300Mbps+5GHz 866Mbps

三频

AC2200 本体

AC2200 分身

 (866回程+866+400Mbps)

三频

AC3000 本体

AC3000 分身

(1733回程+866+400Mbps)

本体端口

每个主机 3 个 WAN/LAN 自适应以太网端口

1 WAN & 1 LAN

1 WAN & 1 LAN

1 WAN & 3 LAN

1 WAN & 3 LAN & 1 USB 2.0

分身端口

-

2 LAN

-

4 LAN

4 LAN & 1 USB 2.0

天线

4根

6根

以太网回程

支持
(互联网 → 主 mesh → 交换机 → 子 mesh)


支持
(RBW30 无 LAN 口,不能组成有线回程)

Daisy Chain Topology 菊花链

支持

Beamforming 波束成形

支持

MU-MIMO

支持

802.11k/v 快速漫游

支持

802.11r 快速漫游

不支持

802.11ax(Wi-Fi 6)

不支持

AP 模式

不支持


支持

关闭 WiFi 双频合一

原厂不支持,小米和 RBK50 可通过修改实现,分离后有线回程可能会失效

IPv6

支持

带机量

248






覆盖范围

-

418 平方米

250 平方米

200 平方

250 平方米

350 平方米

官网价

999

229.99 美元

-

-

-

-

京东自营

999


RBK20:949~1999
RBK23:1399~2999

RBK30:1499~1999

RBK40:2699

RBK50:2499~2999
RBK53:3499~3999

京东旗舰

-


RBK20:999
RBK23:1499

RBK30:2099

RBK40:2799

RBK50:2599
RBK53:3599

天猫旗舰店

999


RBK20:999
RBK23:1299

RBK30:1399

-

RBK50:2799
RBK53:3799

其它天猫店

969 苏宁易购


-

RBK30:1288

RBK40:1699

-

优势

管理功能丰富。

配合米家APP 设置小米智能家居设备入网时,无需手动输入密码,入网更便捷。

网口盲插,不分子母。后续再扩展两个分身时可直接购买套装充当两个分身,相对于 Orbi 购买两个分身要节省成本。


三频。

性能稳定。

大内存


分体价格:

  • 本体 RBR20:599

  • 本体 RBR40:999

  • 本体 RBR50:999 活动

  • 分身 RBS20:699

  • 分身 RBW30 插墙:999

  • 分身 RBS40:1099

  • 分身 RBS50:1449

  • 分身 RBS50Y 室外:未知


价格采自2019年8月


主体/分身 匹配:

  • 分身 RBS20 可作为 RBR20, RBR40 or RBR50 的卫星

  • 分身 RBW30 可作为 RBR40 or RBR50 的卫星

  • 分身 RBS40 可作为 RBR40 or RBR50 的卫星

  • 分身 RBS50 可作为 RBR50 的卫星

  • 分身 RBS50Y 可作为 RBR50 or RBR40 or SRR60 的卫星


image.png


  • RBK13 = 1个 RBR10 + 2个 RBS10

  • RBK20 = 1个 RBR20 + 1个 RBS20

  • RBK23 = 1个 RBR20 + 2个 RBS20

  • RBK30 = 1个 RBR40 + 1个 RBW30

  • RBK33 = 1个 RBR40 + 2个 RBW30

  • RBK40 = 1个 RBR40 + 1个 RBS40

  • RBK43 = 1个 RBR40 + 2个 RBS20

  • RBK44 = 1个 RBR40 + 3个 RBS20

  • RBK50 = 1个 RBR50 + 1个 RBS50

  • RBK53 = 1个 RBR50 + 2个 RBS50


扩展阅读:Mesh 路由器有线回程布线方案

xoyozo 5 年前
16,015

完整操作步骤如下:

  1. 安装 NuGet 包:Microsoft.AspNet.Web.Optimization

  2. 打开 Views 目录(如果是应用于区域,则为区域的 Views 目录)中的 web.config,在 <namespaces /> 节点中添加

    <add namespace="System.Web.Optimization" />
  3. App_Start 目录中创建类文件 BundleConfig.cs,更改其命名空间为应用程序的默认命名空间(即移除 .App_Start),创建方法:

    public static void RegisterBundles(BundleCollection bundles)
    {
        bundles.Add(new StyleBundle("~/虚拟路径(不能有点)").Include("~/CSS文件路径"));
        bundles.Add(new ScriptBundle("~/虚拟路径(不能有点)").Include("~/JS文件路径"));
    }

    虚拟路径应避免与页面访问路径相同。Include 可包含多个文件,效果是合并输出,注意引用的顺序。

  4. 打开 Global.asax,在 Application_Start() 事件中添加代码

    BundleTable.EnableOptimizations = true; // 该设置使在开发模式中实现压缩代码,不设置则仅在发布后压缩代码
    BundleConfig.RegisterBundles(BundleTable.Bundles);
  5. 视图页面中引用样式表或脚本

    @Styles.Render("~/CSS虚拟路径")
    @Scripts.Render("~/JS虚拟路径")

    使用 Render 的好处是,ASP.NET 会自动给引用地址加上参数,可在更改脚本或样式表内容后更改这些参数使浏览器缓存立即失效。

如果你的项目中已经安装并使用 Bundle,那么只需要参考第 4 步,将 BundleTableEnableOptimixations 设为 true

以下是一些常见异常的解决方法:


The name 'Styles' does not exist in the current context

The name 'Scripts' does not exist in the current context

解决:参步骤 2。


引用的样式表或脚本不存在(报 404 错误)

解决:步骤 3 中的虚拟路径不规范。

xoyozo 5 年前
5,292

传统的 LIKE 模糊查询(前置百分号)无法利用索引,特别是多个关键词 OR,或在多个字段中 LIKE,更是效率低下。本文研究对文章进行分词以提高检索的准确度和查询效率。


根据自己的编程语言选择一款合适的中文分词组件,我在 ASP.NET 平台下选择了 jieba.NET。


设想的步骤:

  1. 分别对文章标题、标签、正文进行分词,保存到一张分词表上。该表把“文章 ID”和“词语”设为联合主键,用 3 个字段记录该词语分别在标题、标签、正文中出现的次数,另外还可以按需要添加文章分类 ID、文章创建时间等字段。

  2. 当用户输入关键词进行检索时,先将关键词分词,在分词表中用 in 语法查询到所有相关的记录;

  3. 使用 group by 语法对查询结果按文章 ID 分组;

  4. 关键在排序上,理想的排序是:

    a. 先按搜索关键词中不同词语的出现量排序,即:若搜索关键词分词后是 3 个词语,那么全部包含这 3 个词的文章优先,只匹配其中 2 个词语的其次;

    b. 再按搜索关键词在文中累计出现的次数排序(考虑权重),即:我们先假定标题和标签的分词权重为 5(意思是一个分词在标题中出现 1 次相当于在正文中出现 5 次),那么累加每个分词在标题、标签、正文的权重次数,得分高的优先;

    c. 再进一步考虑文章的发布时间,即将文章的发布时间距离最早一篇文章的发布时间(或一个较早的固定日期)相隔的天数,乘以一个系数加入到权重中,这个系数按不同文章分类(场景)不同,比如新闻类的大一点,情感类的小一点)。乘以系数时一篇文章只加权一次,不要加权到每个分词。

    d. 根据需求还可以加入文章热度(阅读数)的权重。


根据上述逻辑对一个有 18 万篇文章的内容管理系统进行改造,循环所有文章进行分词统计,得到一张包含 5 千万条记录的分词表(系统中部分文章只有标题、标签和外链,没有正文,否则更多)。

由于查询中包含 in、group by、count、sum、运算等,再若分类是无级限的,即文章分类 ID 也是 in 查询,然后分页,即使创建索引,效率也只能呵呵了。


简化:

不对正文进行分词;

不按权重进行排序;


那么分词表的记录数降到 250 万条,同样用 in 查询分词,先按搜索关键词中不同词语的出现量排序,再按发布时间排序,分页后获得一页的文章 ID 集合,再去文章表中 in 获取详细信息(注意保持一页中的排序)。

添加相关索引后,查询一个包含 3 个分词的关键词仅需十几毫秒。因为 in 的内容比较离散,所以索引的利用率比较高。



xoyozo 6 年前
4,397

本文讲述使用网页开发适用于宴会、活动、年会现场 LED 大屏幕显示抽奖、抢楼、游戏、视频等互动界面,通过在浏览器中打开后 F11 全屏投影到大银幕上。


设计思路:

  1. 为了保证最佳的显示效果,设计稿的尺寸按大屏幕的“宽高比”来做(本文以4米*3米的大银幕为例,设计稿以800*600像素为例)。

  2. 由于电脑的视频输出分辨率很有可能与大银幕的宽高比不同,那么我们全屏投影后会界面会有变形,但是投影设备接收到电脑视频信号后再全屏显示到大银幕时,界面又会变回正常。

  3. 按设计稿的尺寸开发网页,并使用 CSS3 的 scale 实现整体伸缩,目的是自适应窗口尺寸来全屏显示内容,无留白、无裁切。整体拉伸的要求是文字、图片、背景、间距、iframe 等所有元素以统一的比例拉伸,无错位。

  4. 网页上通过 JS 设置一些快捷键来实现页面展示内容的切换。

  5. 若投影设备功能有限或操作员水平有限等原因导致无法顺利设置输入输出分辨率时,网页可设置 x 轴和 y 轴两个方向的伸缩系数、定位偏移量等,更灵活地实现完美投影需求。


开发要点:

  • 网页尺寸按设计稿来定(以 800x600 为例)。

  • 使用 CSS3 的 transform 的 scale 来实现缩放,以电脑显示器分辨率 1920x1080,宽放大 1920/800 倍,高放大 1080/600 倍,即可将设计稿全屏展示到电脑显示器上。为了更灵活,我们使用窗口大小来代替显示器分辨率,这样不管怎么改变窗口大小或者全屏,设计稿都能完整地显示在窗口上。

  • 在页面初始化和窗口尺寸变化时重新调整设置上述比例。


代码参考:

xoyozo 6 年前
8,965

这是一篇可能解决困扰了 .NET 程序猿多年的文章!

首先,使用 Visual Studio 2019 创建一个 ASP.NET WEB 应用程序,直接选用了 MVC 模板。

直接发布项目,默认的设置如下图:

image.png

对于小型项目,按默认设置发布基本可满足正常运行,首次运行打开第一个页面基本在 5~6 秒(视服务器配置),其它页面的首次打开也基本在 1~2 秒完成,非首次瞬间打开。

一旦项目功能变得复杂,文件增多,会导致发布后首次运行打开第一个页面 30 秒以上,其它页面的首次打开 10 秒左右,非首次瞬间打开。

这是因为项目在发布时没有进行预编译,而是在用户访问网页时动态编译,一旦应用程序池回收,或项目文件改动,都会重新编译,再次经历缓慢的“第一次”,这是不能忍的。

于是咱们来研究一下“预编译”。

在发布页面勾选“在发布期间预编译”,这时发布会在“输出”窗口显示正在执行编译命令(编译时间会比较长):

image.png

该选项对发布后的文件结构和内容影响不大,因此对首次执行效率的提升也不大,重要的在后面。

在“高级预编译设置”窗口中:

image.png

我们针对预编译选项和合并选项分别做测试。

不勾选“允许更新预编译站点”,会致 bin 目录中生成许多 .compiled 文件,而所有 .cshtml 文件的内容都是:

这是预编译工具生成的标记文件,不应删除!

如果是 Web From 网站,.aspx/.ashx 等文件内容同上。

尝试打开网站页面,你会发现,除了项目启动后的第一个页面仍然需要 1~2 秒(无 EF),其余每个页面的首次都是瞬间打开的(EF 的首次慢不在本文讨论范围)。这让我对预编译有一种相见恨晚的感觉!

这里偷偷地告诉你,把 Views 目录删掉也不影响网页正常打开哦~为什么不让删,咱也不敢问,咱也不敢删。

目的达到了,有一些后遗症需要解决,比如 bin 目录内杂乱无章。

选“不合并。为每个页面和控件创建单独的程序集”,结果是 bin 多出许多 App_Web_*.dll 文件。

选“将所有输出合并到单个程序集”,填写程序集名称。这时会发现“输出”窗口执行了命令:

image.png

如果程序集名称跟已有名称冲突,会发生错误:

合并程序集时出错: ILMerge.Merge: The target assembly '******' lists itself as an external reference.

查看 bin 目录,.compiled 文件还在,但 App_Web_*.dll 合并成了一个程序集。FTP 的“不合并”也是把所有 App_Web_*.dll 上传一遍,所以不存在相对于“合并”的增量发布优势。

是不是勾了“视为库组件删除(AppCode.compiled 文件)”.compiled 文件就会不见?意外之外,情理之中,bin 没有什么变化。

继续选择“将各个文件夹输出合并到其自己的程序集”,呃,bin 中文件数不降反增。

最后选择“将所有页和控件输出合并到单个程序集”,同样程序集名称不能冲突。结局令人失望,bin 中仍然一大堆 .compiled 和 App_Web_*.dll。


整理成表格:

1
允许更新预编译站点

aspnet_compiler.exe -v / -p \Source -u \TempBuildDir 

重复发布后 bin 目录文件数:不会增多(页面不进行预编译)

2

不允许更新预编译站点,不合并

aspnet_compiler.exe -v / -p \Source \TempBuildDir 

重复发布后 bin 目录文件数:.compiled 不会增多,App_Web_*.dll 增多

3

不允许更新预编译站点,不合并。为每个页面和控件创建单独的程序集

aspnet_compiler.exe -v / -p \Source -c -fixednames \TempBuildDir 

重复发布后 bin 目录文件数:不会增多(编译后的文件名固定,FTP 方式的部分 App_Web_*.dll 文件可能实现增量上传)

4

不允许更新预编译站点,将所有输出合并到单个程序集,不勾选“视为库组件”

aspnet_compiler.exe -v / -p \Source -c \TempBuildDir 

aspnet_merge.exe \TempBuildDir -o 程序集名称 -copyattrs AssemblyInfo.dll -a

重复发布后 bin 目录文件数:不会增多(.compiled 固定名称,App_Web_*.dll 合并为一个)

5

不允许更新预编译站点,将所有输出合并到单个程序集,勾选“视为库组件”

aspnet_compiler.exe -v / -p \Source \TempBuildDir 

aspnet_merge.exe \TempBuildDir -o 程序集名称 -copyattrs AssemblyInfo.dll -a -r 

重复发布后 bin 目录文件数:不会增多(.compiled 固定名称,App_Web_*.dll 合并为一个)

6

不允许更新预编译站点,将每个文件夹输出合并到其自己的程序集,前缀

aspnet_compiler.exe -v / -p \Source -c \TempBuildDir 

aspnet_merge.exe \TempBuildDir -prefix 前缀 -copyattrs AssemblyInfo.dll -a  

重复发布后 bin 目录文件数:.compiled 不会增多,App_Web_*.dll 增多

7

不允许更新预编译站点,将所有页和控件输出合并到单个程序集

aspnet_compiler.exe -v / -p \Source -c \TempBuildDir 

aspnet_merge.exe \TempBuildDir -w 程序集名称 -copyattrs AssemblyInfo.dll -a  

重复发布后 bin 目录文件数:.compiled 不会增多,App_Web_*.dll 增多

bin 目录下,页面的程序集文件(App_Web_*.dll)增多的原因是编译后的文件名不固定,发布到会导致残留许多无用的程序集文件。

相比较,如果第 3 种能实现 FTP 稳定的增量上传的话是比较完美的(还有一个缺点是:如果页面有删除,目标 bin 内对应该页面的 .compiled 和 .dll 不会删除,这跟“允许更新预编译站点”是一个情况),那么第 4 种 或第 5 种也是不错的选择(同样有缺点:执行合并比较慢)。

测试一个有 300 个页面的项目,compiler 用时约 2 分钟,merge 用时约 5 分钟,发布用时约 4 分钟。

这里有个槽点,执行预编译和合并是佛系的,CPU 和磁盘使用率永远保持在最低水平。

所以如果是要经常修改的项目,那么建议选择“不合并”的第 3 种发布方式:

微信图片_20190715160035.png

“视为库组件(删除 AppCode.compiled 文件)”:移除主代码程序集(App_Code 文件夹中的代码)的 .compiled 文件。 如果应用程序包含对主代码程序集的显式类型引用,则不要使用此选项。


补充:

  • 不允许更新预编译站点发布后,因为前端页面没有内容,因此无法单独修改发布(单独发布一个页面后,在访问时不会生效!),只能全站发布,耗时较长;bin 目录有变动将导致使用 InProc 方式存储的 Session 丢失。

  • 预编译的另一个优点是可以检查 .aspx / .cshtml 页面 C# 部分的错误(特别是命名空间和路径引用)。

  • 改为预编译发布后,可以将服务器上残留的 .master / .ascx / .asax 删除,但不能删除 .aspx / .ashx /.config 等。

  • VS 发布到 FTP 经常会遗漏一些页面文件,不合并时会遗漏独立文件,合并后也会遗漏合并后的 .dll 的文件,合并的好处就是方便检查是否完全上传发布。

  • 慎选“在发布前删除所有现有文件”!一旦勾选发布,世界就清静了,所有网友上传的图片附件以及网站运行产生的其它文件,消失得无影无踪。不管发布到文件系统还是发布到 FTP 都一样。当然,如果是先发布到文件系统,再通过 FileZilla 等 FTP 软件上传到服务器的,建议勾选此项。

  • .NET Core 应用程序部署:https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index

  • 由于上传文件时 bin 目录文件较多,理论上 bin 目录内的文件有任何改动都会重启应用池,而且 VS 是单线程上传的,导致期间网站访问缓慢,服务器 CPU 升高,我的做法是:发布到文件系统,再使用专用 FTP 工具上传,上传用时约半分钟(如果大小不同或源文件较新则覆盖文件)。还嫌慢?那就打包上传,解压覆盖。

  • 关于本文研究对象的官方解释:高级预编译设置对话框

  • 出现“未能加载文件或程序集“***”或它的某一个依赖项。试图加载格式不正确的程序。”的问题时,先用改用 Debug 方式发布会报详细错误,一般是 .aspx 等客户端页面有 C# 语法问题,注意提示报错的是 /obj/ 目录下的克隆文件,应更改原文件。排除错误后关闭所有页面,再使用 Release 方式发布。

xoyozo 6 年前
11,214