Re: [Quickfix-users] how can i NOT generate a bigFIX.4.2-xxxxx.body file?

[<urb...@sb...>]

Dan,

As Oren pointed out, managing the message callback in Queue can be 
substantially beneficial.  As well, you want to be absolutely certain to 
dispose properly in all related functions, which in the end also makes 
substantial differences.  Switching to memory file mode for message store, 
may be reducing your cpu and wait demands for file writing some, but at a 
price of memory consumption and loss of messages on an interruption or power 
down.

In our experience, we have found that setting flags to be able to start with 
or without messaging / modes and then managing file maintenance on disk at 
rollover time, gave us the best balance, once we got disposals and other 
proper handling working.

Are you making proper use of caching to your hardrive with DMA and other 
drive write benefits enabled?

It sounds like your issues may be related to either not having trimmed down 
your operating system to be lean enough to act as a dedicated tool, or that 
your TCP stack may have many other activities happening that are reducing 
TCP performance, so shutdown any unwanted services, especially those using 
TCP without need for them.  10 msg / second is a "sleeper" compared to what 
QF can do when coded tightly and setup in a properly prepared environment to 
run hard, even under C# NET. ;)

Even if all you do is receive data, the day may come when you move on to 
forwarding or relay operation and so it's best to not only prepare well, but 
labor the system intentionally in those areas so when it is time to use 
them, they don't punish your performance unrealistically.  Iow design to the 
worst case demand, in the best case possible environment.


Mike


----- Original Message ----- 
From: "Dan Guo" <dua...@ya...>
To: "Djalma Rosa dos Santos Filho" <drs...@gm...>
Cc: <qui...@li...>
Sent: Friday, February 08, 2008 1:16 PM
Subject: Re: [Quickfix-users] how can i NOT generate a bigFIX.4.2-xxxxx.body 
file?


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Djalma,
> thank you. that is it!
>
> i guess since i am a client (not a brokerage), i do not need 
> re-transmission feature. i would expect my broker DO RETRAN on my behalf 
> (if i miss a msg and ask them to retrans from an older sequence #), not 
> the other around.
>
> Is my understanding correct?
>
> Dan
>
> ----- Original Message ----
> From: Djalma Rosa dos Santos Filho <drs...@gm...>
> To: "Qui...@li..." 
> <qui...@li...>
> Sent: Friday, February 8, 2008 1:10:28 PM
> Subject: Re: [Quickfix-users] how can i NOT generate a big 
> FIX.4.2-xxxxx.body file?
>
> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
>
> -----Inline Attachment Follows-----
>
>
> The .body file is one of the files used by the FileStore, it is useful 
> only if you want the engine to be able to respond to resend requests.
>
> When I want to get rid of this file, I use the MemoryStoreFactory and/or 
> put PersistMessages=N in the configuration file. Better performance, less 
> disk space consumption, but no message retransmission.
>
>
> On Feb 8, 2008 3:53 PM, Dan Guo <dua...@ya...> wrote:
>
> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello! I use QuickFix for our trading. I run multiple instances, each with 
> a FIX session.
>
> I notice in a typical day, each instance generates a huge log file named 
> FIX.4.2.xxxx(our firm name).body. It can be about 100MB each.
>
> I tried to use ScreenLogFactory(false, false, true). It however did not 
> decrease the log file size.
>
> ScreenLogFactory( bool incoming, bool outgoing, bool event ).
>
> Does anyone have similiar issue and have a solution?
>
> thank you very much,
> Dan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>
>
>
>
> -----Inline Attachment Follows-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users