Hi Antti,

Try to lock database with nbackup and check the peformance with locked database - in this case all writes will go to delta file sequentially.
If your assumption is true and Premium Storage does not work good with random writes, you will see less decrease of performance.

Also, there are other options to deal with such performance problem - please contact me directly.

вторник, 30 августа 2016г., 19:18 +03:00 от Antti Nivala antti.nivala@... [firebird-support] firebird-support@yahoogroups.com:

 

Hi,

 

We've experimented with the performance of Firebird in virtual machines in Microsoft's Azure cloud. With Azure VMs, any durable data needs to be placed in "data disks", and essentially that means network-connected storage that is inherently slower than e.g. local SSD disks.

 

When testing our application's operations with a Firebird database that's on such a "data disk", the performance is roughly 6x slower than when the database is on the VM's local, temporary-only disk. The temporary disks obviously are not good for real use so this is for performance comparison only.

 

When we do the same test with SQL Server (e.g., SQL Server Express Edition), the performance difference between the temporary local disks and the durable data disks is significantly smaller. SQL Server seems to perform pretty much as fast with the data disk with our application's operations.

 

The way I'm explaining this difference to myself is that Firebird's way of making the transactions durable is not well suited for this kind of environment where the disk has latency. As far as I understand, Firebird needs to make a lot of page writes to the disk to different locations (as the transaction is touching multiple tables), and this is probably poison in a situation where the disk has latency. On the other hand, SQL Server, as far as I understand, only needs to write to its transaction log file to make the transaction durable, which is probably an advantage in this kind of hardware setup.

 

Do you think these general observations/reasons for the slow performance with Firebird with Azure data disks are correct?

 

Is there anything obvious that we could do to make Firebird work fast in Azure VMs (requiring durability of the transactions, of course, so turning forced writes off doesn't sound like an option)?

 

I can't think of anything myself, but I wanted to ask before completely disregarding the option of running Firebird in Azure VMs.

 

More info on Azure Premium Storage data disks here:

https://azure.microsoft.com/en-us/documentation/articles/storage-premium-storage/

 

Antti