Performance highlights

[migajek]

Hi,
I've been happily using Seq in multiple project over past couple of years. I'd love to see it in the upcoming project where I'm advising the architecture choices, however - for that to happen - I need to convince the people in charge of the project, main non-technical.
While the usability advantages of Seq are obvious, but hard to measure - are there any performance comparisons ran against the competitors?

[nblumhardt]

Hi Michał, thanks for dropping us a line!

Performance is usually pretty scenario-specific (data, hardware, usage patterns, features, ...) and because of differences in the way products are designed to be used, we don't maintain any general comparisons.

For example, Seq's usability springs in part from its full commitment to structured data, and the performance of even quite complex queries over structured data is important to us, but products that emphasize logs-as-text will blow us away in text search performance.

Because we don't index on ingest, Seq has great ingest performance, but background indexing has CPU requirements that might be otherwise higher than on systems that do index up-front.

Querying also has very different characteristics across systems; Seq incrementally searches in reverse-time order, so it can be faster to yield results from new ingest, while other systems might have better overall throughput across large time ranges.

I'm afraid this hasn't turned out to be a very useful answer to your original question :-) and I know you'll need to come up with some criteria of evaluation. If there's a specific metric that you expect to be particularly important for the new system (CPU or RAM usage, storage space, ingest, interactive search, archival search, etc.) let me know and I'll pass on whatever info I can.

Best regards,
Nick

[migajek]

Hi Nick,
thank you for the reply.
I fully understand the fact it's hard to compare and provide useful metrics on the performance, given the vast number of possible factors and scenarios. Therefore it actually is a useful answer, as it gives me the key points to focus on - primarily, to highlight the ingestion mechanism which doesn't index right away. As far as I understand the client's concerns, this is possibly the major one - to minimize the impact on the production system performance. While indexing requirements and query performance are important, in our case mainly for the devs' experience, they don't affect the system performance itself.

Thanks again! Should I have more specific inquiries from the client, I'll ask for the detailed numbers here.

Cheers
Michał

[nblumhardt]

That's great - good luck with the project, @migajek 👍

[richard-stafflink]

Wow! is it just me, or did Seq just get noticeably faster in the new version?
We just updated to 2024.3.13545 last night, and I'm pretty sure we didn't change anything but the version. Running on AWS in ECS (1 vCPU + 2GB), it's running on the smell of an oily rag.

Over 1 day

Over 3 days

[nblumhardt]

Looking good! I don't think there's a specific change in that version to explain the difference, but performance on tiny machines is hard to predict - if the difference remains noticeable once the instance has had a few days to warm up, it could be due to updated rustc or .NET/BCL versions. Cheers!