Is there any performance or benchmark information for Prosys OPC UA available?
How can you test the maximum performance of OPC UA variable updates, method calls and event updates?

There’s no performance or benchmark information publicly available for Prosys OPC UA SDK. This is mostly because of the diversity of applications where SDK is used. However, we have made some performance related tests for development purposes internally.

we would like to know how many events, OPC UA method calls or variable updates can be handled per second, where the client and server are on different hosts in the local network.

In normal situations the OPC UA communication will probably not be the performance bottleneck of your application. At least hundreds of events, method calls or variable updates can be handled per second.
That said, it is possible that certain applications need special performance consideration. One example of a system which needed special performance consideration regarding subscriptions is detailed in this blog post: http://www.prosysopc.com/blog/…..ed-server/

for example up to about a 50Kb array of numeric values: How fast could the client get the data from the server, assuming a fast network and hosts?

Call times for read-method usually are something in the range of one millisecond. However, accurate results may only be acquired by benchmarking the specific system at hand.
In this specific case you could try measuring the call time of client applications read()-method when reading that 50kb array. Java’s System.nanoTime() can be used to benchmark method call times as long as the drawbacks of micro benchmarking are taken into account.
With subscriptions you have two metrics that you probably are interested in: the time it takes to deliver value from server to client and the total throughput of the connection. If you want to analyse the performance of subscriptions, I would advice you to start by timestamping values when they are received at the client application and then comparing these with source timestamps of same data. This way the time to deliver notification values from server to client can be estimated. Remember however that publishing interval affects this value. If timestamps show that delivering values to client application takes longer and longer, then the throughput of the subscription may not be adequate and notification buffers will be filled at some point.

It seems that only arrays of objects (Number) are supported, and not primitive types (Integer). Does that make much difference?

This probably won’t be the bottleneck of performance within your application. However if you are interested in the performance of different data types you could try using OPC UA ByteString (byte []) as your data type and see if that has any effect on your applications performance.

“Acknowledge on Subscription 10: 1 – Bad_SequenceNumberUnknown”

This error message states that server application has already deleted the subscription message that client application is acknowledging. SubscriptionManager class contains method public void setMaxRetransmissionQueueSize(int maxRetransmissionQueueSize) which can be used to set the number of notification messages to keep in the retransmit queue. This can be set in your server application like this:

When sampling interval is set from client application with

then the server application will use fastest possible sampling rate. Current minimum in the SDK is 1 millisecond. However, this value can be set to 0 on the server side, which disables sampling interval completely (every value is reported).

If you have some existing application and you’re interested in what is the actual sampling interval that the server application uses, you can see what the CreateMonitoredItemsResponse contains in it’s revisedSamplingInterval field.