apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david reid <da...@jetnet.co.uk>
Subject io abstractions #2
Date Thu, 29 Jun 2006 14:53:45 GMT
I managed to move connect functionality over, and then it took me no 
time to convert sockperf over to new api. with some mods to the app to 
allow for more tests per iteration, here are the results.

NB These were done against the same echod running using the current api.

Current API

APR Test Application: sockperf
Tests Complete!
       1024 byte block:
         100 iterations :          Average:    351
       4096 byte block:
         100 iterations :          Average:    472
      16384 byte block:
         100 iterations :          Average:  81524
      65536 byte block:
         100 iterations :          Average:   3422
     262144 byte block:
         100 iterations :          Average:  14361

APR Test Application: sockperf
Tests Complete!
       1024 byte block:
         100 iterations :          Average:    639
       4096 byte block:
         100 iterations :          Average:    632
      16384 byte block:
         100 iterations :          Average:  81753
      65536 byte block:
         100 iterations :          Average:   2009
     262144 byte block:
         100 iterations :          Average:  10227

Revised IO api

APR Test Application: sockperf
Tests Complete!
       1024 byte block:
         100 iterations :          Average:    324
       4096 byte block:
         100 iterations :          Average:    290
      16384 byte block:
         100 iterations :          Average:  83065
      65536 byte block:
         100 iterations :          Average:   2358
     262144 byte block:
         100 iterations :          Average:  10132

APR Test Application: sockperf
Tests Complete!
       1024 byte block:
         100 iterations :          Average:    581
       4096 byte block:
         100 iterations :          Average:    578
      16384 byte block:
         100 iterations :          Average:  83164
      65536 byte block:
         100 iterations :          Average:   2637
     262144 byte block:
         100 iterations :          Average:  12143

NB any idea why the 16k tests are so much slower? Is it an apr issue or 
an os one?

Basically the results show the sorts of variations we'd expect I think. 
They don't seem to point to truly horrible reduction in IO though.

I think that somehow people aren't really "on the same page" as I am, so 
I'll try and explain again what I'm aiming for. When fully implemented 
the IO abstraction will allow ANY app to create it's own type of 
apr_io_t - which can then be mised/matched with any other type of 
apr_io_t within the app. In my imagination the revised apr_ssl code 
simply creates apr_io_t's - there is no longer a notion of 
files/sockets/pipes or anything else. All the code currently under 
network_io and file_io goes away - replaced instead by code unser simply 
'io'. The api is extensible - deliberatly so.

I have the headers creating docs, so if people want me to put them 
online then I'm happy to do so. They should at least point to how it all 
fits together.

This seems to be what is needed and what people want. That's why I 
dropped the 'io' from the function names as there shouldn't be a need 
for any other forms of these functions. Will's suggestion that you 
should be able to call specific functions is utter lunacy with the 
abstraction I'm aiming for - if you even care then you're doing 
something wrong. That's not to say there aren't functions that will need 
to be called directly, but a function apr_xml_config_get(...) is 
different to simply reading the file, which would be done by apr_read().

Now,if people don't want this or don't see a need then I'm happy to walk 
away and forget it.

david

Mime
View raw message