#1 Re: mORMot 1 » Benchmark PostgreSQL, SQLite and mORMot » 2022-05-07 05:33:08

@ttomas I made a new gist based on your proposal, which you can find here.
I run client on an another PC and use my PC as a server, but nothings changed.
And the number of client threads is irrelevant.

#2 Re: mORMot 1 » Benchmark PostgreSQL, SQLite and mORMot » 2022-05-04 10:51:22

Thank you very much, @ttomas.
I made a fresh gist and used your advice to benchmark, and mORMot created one connection per thread, but most of the time just one connection was sending requests to the PostgreSQL database.
This is the gist of a new benchmark.
Processes

#3 Re: mORMot 1 » Benchmark PostgreSQL, SQLite and mORMot » 2022-05-03 07:40:12

pvn0 wrote:

why exactly do you care if a batch transaction takes 50 ms?

Although 50ms is not a huge delay, PostgreSQL does not impose it across multiple connections, thus I'm not sure which is better: PostgreSQL or SQLite + mORMot.

pvn0 wrote:

Does your client application lock up and stop responding?

Yes, the client must wait until the action on the request is completed before allowing another request.

#4 Re: mORMot 1 » Benchmark PostgreSQL, SQLite and mORMot » 2022-05-02 18:05:31

Yes, In my application, it was important to guarantee that the database committed data before sending a confirmation message to the user.

#5 Re: mORMot 1 » Benchmark PostgreSQL, SQLite and mORMot » 2022-05-02 08:42:37

The issue with BATCH mode is that if I set a timer to open and close it every 100ms, the response time to the user to show that the data is truly committed will increase by about 50ms on average.
Although this may not seem like much, it makes choosing between PostgreSQL and SQLite more difficult, and it also makes me wonder whether there is a way to utilize mORMot with PostgreSQL without having to use BATCH mode and still obtain the same speed.

#6 Re: mORMot 1 » Benchmark PostgreSQL, SQLite and mORMot » 2022-05-01 07:10:36

Yes, I can use BATCH mode with a timer to open and close the transaction.
However, it causes a delay in the user's response, which is undesirable in my use case.
For the time being, I can't decide whether to use PostgreSQL directly or SQLite and mORMot together.
SQLite's performance and PostgreSQL's security are both in question.

#7 Re: mORMot 1 » Benchmark PostgreSQL, SQLite and mORMot » 2022-04-30 18:23:21

For my use case, BATCH mode is not usable as many users with many connections need the database.

When I tried the mORMot memory manager, it didn't make much of a difference (10%).

My main question is more about why I can get more from PostgreSQL in multi-connection design. Is it correct or is there something I should try to do with SQLite? Or as PostgreSQL numbers are like off+exclusive mode, there is a chance of losing data with PostgreSQL?

Two more questions:

- Using PostgreSQL with mORMot in multi connection/thread seems slower. Is there an option to change in mORMot to have the max speed? without BATCH, as it is not useful for my case.

- Do you know anything about https://www.sqlite.org/src/vdiff?branch … concurrent? Can it be useful in this case?

My whole target is to use the best multi connection/thread database and using is with mORMot if the max speed is viable.

#8 mORMot 1 » Benchmark PostgreSQL, SQLite and mORMot » 2022-04-30 11:47:49

tihory
Replies: 17

Hello, I'm trying to write an application that requires high-performance inserts from multiple clients using mORMot RestORM, so I created a benchmark to compare the performance of SQLite and PostgreSQL. However, because RestORM only uses a single connection to PostgreSQL, the speed of the application suffers greatly.

The source code for the benchmark and the outcome on my computer
The mormot2 and multithreadprocslaz packages are required to execute benchmark.

What is the proper way to use mORMot RestORM with PostgreSQL?

And what are the advantages of SQLite over PostgreSQL with mORMot if PostgreSQL + mORMot performance improves? As a server database, I believe PostgreSQL is safer.

However, it's worth noting that PostgreSQL's performance is equivalent to SQLite's with Sync Off. So, if PostgreSQL isn't thoroughly flushing data, there's a chance the data will be corrupted if there's a sudden crash.
Any input on this is welcome.

Board footer

Powered by FluxBB