Re: [Quickfix-developers] QuickFix performance?

[Oren M. <or...@qu...>]

One thing to note for the C# API, make sure you are disposing all  
your messages.  The ones you send as well as the ones you receive.   
This will make a BIG difference in high throughput systems.

--oren

On Dec 19, 2007, at 10:05 PM, Djalma Rosa dos Santos Filho wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Rick,
>
> I don't know if this is the same, but we are also suffering with
> low-throughput message receiving when using quickfix in a C# GUI
> application in the moment when there is a remote connection sending
> thousands of messages. Because of this, we're planning to modify the
> application's architecture by adding some stuff like MVC, queues and
> threading pools to try to maximize the throughput. The current
> application design is inefficient and I believe in some reasons for
> that, things related to the way how Quickfix is working and some TCP
> socket issues...
> But, in order to know if maybe this is the same with you, let me ask
> you some questions for clarification.
> When you say that you could isolate quickfix performance, what exactly
> do you mean? Nothing in fromApp() ?
> Are you processing all messages in the context of the quickfix thread?
> How heavy is this message processing?
> Are you using the message cracker?
>
> Djalma
>
>
> On Dec 19, 2007 12:59 PM, Rick Lane <ric...@gm...> wrote:
>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
>> html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Greetings,
>>
>> Is there any documentation regarding the performance (e.g. message
>> throughput capabilities) of QuickFix?  I'm running into issues  
>> where it
>> seems that I'm receiving messages too slowly (I emailed the list a
>> couple days ago regarding fill notifications -- namely, if I place an
>> immediate-fill order for, say, 1000 contracts, it takes nearly 2.5
>> seconds to receive all of the fill notifications).  This may have
>> something to do with the CME (perhaps on the environment on which I'm
>> testing they throttle fill notifications) but I don't believe this is
>> the case.  I've pretty much eliminated any other threading/etc.  
>> that my
>> application is doing to try to isolate the performance solely to
>> QuickFix and I'm still seeing the same results.
>>
>> Has anyone run into this before, and is there some advice as to why
>> these notifications might be taking so long to be processed?
>>
>> Thanks,
>> RL
>>
>> --------------------------------------------------------------------- 
>> ----
>> SF.Net email is sponsored by:
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services
>> for just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ 
>> marketplace
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
> ---------------------------------------------------------------------- 
> ---
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ 
> marketplace
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>