6月30日更新 这个问题使基准测试更加清晰,Mythz找到了一个问题并解决了: ServiceStack benchmark continued: why does persisting a simple (complex) to JSON slow down SELECTs?
写/读速度是否合理?
在使用OrmLite进行试验时,我将进行测试以将所有当前数据/对象从我们自己的实现中转换为保存到数据库,然后切换到OrmLite。
但是,我做了一个简单的基准测试/速度测试,比较了当前的序列化和写入db以及从db读取和反序列化。
我发现ServiceStack比我们目前的运行速度慢得多(我们目前仅使用FastSerializer序列化对象,然后将byte []数据写入BLOB字段,因此它的读写速度很快,但是当然有明显的缺点)。
我所做的测试是使用Customer类,该类具有很多属性(用于我们的产品中,因此它是在当前版本中每天都使用的一个类)。
如果我创建了1万个此类对象,然后测量将它们持久保存到MySql数据库中的时间(序列化+写入db),结果为:
更新
由于“当前实现”在作弊(它只是向数据库BLOBing一个byte []),我实现了一个简单的RelationDbHandler,它以常规方式通过一个简单的SQL查询来持久保存10 000个对象。结果将添加到下面。
写入10000个对象:
当前实施时间:33秒
OrmLite(使用.Save):94秒
关系方法:24.7秒
读取1万个对象:
当前实施时间:1.5秒
OrmLite(使用Select <>):28秒
关系法:16秒
我正在SSD磁盘上本地运行它,而CPU或磁盘上没有其他负载。 我希望我们当前的实现会更快,但不会那么快。
我在ServiceStack网页(https://github.com/ServiceStack/ServiceStack/wiki/Real-world-performance)上阅读了一些基准测试资料,但是大多数链接都已失效。显而易见,读取25000行需要245毫秒,但我不知道行的样子。
问题1:是否有我可以阅读的更多基准信息?
问题2:下面指定了Customer对象。神话认为上面的写/读时间合理吗?
测试案例: 这是OrmLite创建表后在数据库中显示的Customer对象。我仅填充5个属性,一个是“复杂”属性(因此,只有一个字段在行中具有JSON序列化表示法),但是由于所有字段均已写入,因此我认为这没什么大不了的吗?
使用OrmLite保存的代码:
public void MyTestMethod<T>(T coreObject) where T : CoreObject
{
long id = 0;
using (var _db = _dbFactory.Open())
{
id = _db.Insert<T>(coreObject, selectIdentity: true);
}
}
从表中全部读取的代码:
internal List<T> FetchAll<T>()
{
using (var _db = _dbFactory.Open())
{
List<T> list = _db.Select<T>();
return list;
}
}
答案 0 :(得分:0)
使用Insert()
插入行。 Save()
将检查现有记录是否存在并进行更新(如果存在),并且还会填充“自动增量”主键(如果已创建)。
也有InsertAsync()
个API,但Oracle的官方 MySql.Data 软件包没有适当的异步实现,在这种情况下,使用https://github.com/mysql-net/MySqlConnector可以通过安装获得更好的结果的
ServiceStack.OrmLite.MySqlConnector NuGet软件包并使用其MySqlConnectorDialect.Provider
。
使用.NET Core,它将使用最新的8.x MySql.Data NuGet包,也将获得更好的性能。
注意:https://github.com/tedekeroth/OrmLiteVsFastSerializer中的结果不可比较,这实际上是将MySql作为NoSQL Blob存储与OrmLite中具有多个复杂类型斑点字段的准关系模型进行比较。
在我的测试中,我还注意到吞没了一些序列化异常,这会对性能产生负面影响,您可以通过在Startup上进行配置来使异常冒泡:
OrmLiteConfig.ThrowOnError = JsConfig.ThrowOnError = true;