Subject | Re: Firebird Remote Protocol |
---|---|
Author | Roman Rokytskyy |
Post date | 2005-12-07T16:00:45Z |
Hi,
Thanks for the info. So let's check how we can improve this:
is 65ms
was 50ms + 59ms + 49ms + 83ms (not sure here, the protocol here and at
the end of the message are different), new delay would be ~60ms
(assuming the 50ms latency and 10ms for the execution)
back the first portion of data, old delay was 83ms + 100ms (?), new
delay would be ~80-90ms.
hand this example is not 100% fair, since in my applications prepared
statements are used, in this case the number of roundtrips is reduced
significantly. However, in order to support applications relying on
simple statements we might introduce new isc_dsql_exec_immed3 that
would take SQL as input and return combined outXSQLDA + data as
output... Ugly, but...
Roman
Thanks for the info. So let's check how we can improve this:
> The server is FB1.5 and isql. Executing a simple query.1. start transaction, we cannot avoid it, old delay is 65ms, new delay
is 65ms
> Client --> Server (20 bytes) # 29 (op_transaction)2. Introduce new method to prepare and allocate SQL string, old delay
> Server --> Client (32 bytes) # 9 (op_response)
was 50ms + 59ms + 49ms + 83ms (not sure here, the protocol here and at
the end of the message are different), new delay would be ~60ms
(assuming the 50ms latency and 10ms for the execution)
> Client --> Server (8 bytes) # 62 (op_allocate_statement)3. Introduce new statement to execute prepared statement and return
> Server --> Client (32 bytes) # 9 (op_response)
> Client --> Server (76 bytes) # 68 (op_prepare_statement)
> Server --> Client (3504 bytes) # 9 (op_response)
> Client --> Server (24 bytes) # 70 (op_info_sql)
> Server --> Client (48 bytes) # 9 (op_response)
> Client --> Server (20 bytes) # 69 (op_set_cursor)
> Server --> Client (32 bytes) # 9 (op_response)
back the first portion of data, old delay was 83ms + 100ms (?), new
delay would be ~80-90ms.
> Client --> Server (24 bytes) # 63 (op_execute)4. Release statement. No chance to optimize.
> Server --> Client (32 bytes) # 9 (op_response)
> Client --> Server (32 bytes) # 65 (op_fetch)
> Server --> Client (32 bytes) # 66 (op_fetch_response)
> Client --> Server (12 bytes) # 67 (op_free_statement)5. Commit transaction. No chance to optimize.
> Server --> Client (32 bytes) # 9 (op_response)
> Client --> Server (8 bytes) # 30 (op_commit)Having said that, we are still far behind the others. On the other
> Server --> Client (32 bytes) # 9 (op_response)
hand this example is not 100% fair, since in my applications prepared
statements are used, in this case the number of roundtrips is reduced
significantly. However, in order to support applications relying on
simple statements we might introduce new isc_dsql_exec_immed3 that
would take SQL as input and return combined outXSQLDA + data as
output... Ugly, but...
Roman