| Author |
Message
|
| scravr |
 Posted: Thu Jun 02, 2011 5:15 am Post subject: V7: BAR size |
 |
|
Partisan
Joined: 03 Apr 2003
Posts: 391
Location: NY NY USA 10021
|
HI,
Any idea what (in KB and/or MB) is considered as a:
1. Small BAR size
2. Medium BAR size
3. Large BAR size
to run in Exec Group on Windows and LINUX?
Thanks,
Mos |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Thu Jun 02, 2011 5:24 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Our bars are usually in the 50 ~ 150 MB range. Beware of a bug in the mqsicreatebar utility that bloats bar files. Delete .metadata folder before every build.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| scravr |
| Posted: Thu Jun 02, 2011 5:28 am Post subject: |
|
|
Partisan
Joined: 03 Apr 2003
Posts: 391
Location: NY NY USA 10021
|
Thanks for the delete tip...
Is any study made on what will be considered Small, Mid, Large.... |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jun 02, 2011 5:31 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I'm not sure why size is important. A bar file is a Jar file. A jar file is a zip. Therefore, a bar file is a zip file. When you deploy a bar file, source code files get exploded onto disk. There is no performance impact or advantage for bar files being small or large.
What are you concerned about?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 02, 2011 5:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Beware of a bug in the mqsicreatebar utility that bloats bar files. |
a) Which version(s) of WMB?
b) Is there a PMR?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Jun 02, 2011 5:57 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
Lancelots:
would be considered large in my book 
Why dont you share the size of the BAR file thats causing you concern?
Back in the day (a number of years ago on broker 5) we used to have issue with bar files of a few Meg in size (we had large message sets) as the deploy process got out of memory errors.
Are these just general questions or are you having specific issues?
Last edited by WMBDEV1 on Thu Jun 02, 2011 5:58 am; edited 1 time in total |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jun 02, 2011 5:57 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| Beware of a bug in the mqsicreatebar utility that bloats bar files. |
a) Which version(s) of WMB?
b) Is there a PMR? |
7.0.0.2 base (sans Ifix 1). Yes, a PMR was opened. The IBM solution workaround was to delete .metadata folder before every build.
The symptom is that building the same bar file time after time produced bar files that were not consistent in size. One time the bar might be 25 MB, another time it might be 250 MB. The bloating was the result of multiple dependencies being included erroneously by the mqsicreatebar utility. When .metadata directory is deleted every time, the results were more consistent.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 02, 2011 6:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| The IBM solution workaround was to delete .metadata folder before every build. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| scravr |
| Posted: Thu Jun 02, 2011 8:30 am Post subject: |
|
|
Partisan
Joined: 03 Apr 2003
Posts: 391
Location: NY NY USA 10021
|
this is just generic quation
like to know what is considered to be smal, mid, large.....
and how many BIG could be deploy to single exec. group. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jun 02, 2011 8:33 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Deployment of BAR file artifacts are only limited by available disk space. Therefore, you may deploy as many BAR files as you wish to any single execution group. There is no limit.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 02, 2011 8:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Deployment of BAR file artifacts are only limited by available disk space. |
And the amount of memory available to run them. Sooner or later even POWER7 AIX machines run out. Those of us mere mortals condemed to use more humdrum hardware will hit limits sooner.
| lancelotlinc wrote: |
| There is no limit. |
There's no enforced limit I'm aware of, i.e. the deploy will not fail with a "too many flows in EG" error.
The question of when 1 big flow is better than the functionality in n smaller flows is a complex design question. Likewise how many of what kind of nodes make the flow "big".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Thu Jun 02, 2011 11:29 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| scravr wrote: |
this is just generic quation
like to know what is considered to be smal, mid, large.....
and how many BIG could be deploy to single exec. group. |
There is no answer to this question as it is all relative to the resources available on your runtime server.
Just as you cannot say that an execution group can only handle X number of flows as a flow can be very simple or extremely complicated.
The same thing applies to how fast your flows process messages. Some people say they can process 10,000 transaction per second. We have some flows that process messages at a rate of 60,000 per hour and are very happy with that throughput. It all depends on how much you are asking the flow to do and how much time your flow has to wait for any external resources to respond.
The broker is a framework, how you use (or abuse) that framework will greatly impact the efficiency you get out of it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 02, 2011 12:57 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
User A creates bar files that are 100K in size. One day he creates a 500K bar file - WOW, that 500K bar file is huge.
User B creates bar files at are 75MB is size. One day he creates a 500K bar file - WOW, that 500K bar file is tiny.
Its all relative. Unless you get answers from dozens of users to establish some sort of baseline, any one answer you get is not very useful.
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Fri Jun 03, 2011 10:22 am; edited 1 time in total |
|
| Back to top |
|
|
| eugenek |
| Posted: Fri Jun 03, 2011 7:09 am Post subject: |
|
|
Newbie
Joined: 03 Jun 2011
Posts: 6
|
| lancelotlinc wrote: |
| Vitor wrote: |
| lancelotlinc wrote: |
| Beware of a bug in the mqsicreatebar utility that bloats bar files. |
a) Which version(s) of WMB?
b) Is there a PMR? |
7.0.0.2 base (sans Ifix 1). Yes, a PMR was opened. The IBM solution workaround was to delete .metadata folder before every build.
The symptom is that building the same bar file time after time produced bar files that were not consistent in size. One time the bar might be 25 MB, another time it might be 250 MB. The bloating was the result of multiple dependencies being included erroneously by the mqsicreatebar utility. When .metadata directory is deleted every time, the results were more consistent. |
The contents of the BAR file should always be consistent in terms of number and type of artifacts. If you see that it is different between compilations when the source does not change then I would like to see an example. I have not seen this kind of behavior yet. The size of the compiled artifacts may be slightly different but very very minor. I am not sure why it happens though. But it should not affect the compiled contents (should be the same).
I am only aware of the bloating issue with the BAR file that is caused by JAR files on the class path of the flow projects. But I am not aware of the PMR on this issue.
What is the PMR number or description that you are referring to? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Jun 03, 2011 8:15 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
The PMR was opened around March 2010. If you PM me, I can provide more details you can search the PMR database on.
The bloating occurs sometimes when there are complex dependencies between projects of a workspace. Like, Project A depends on Projects B , C, D, and E and Project E depends on Project B. Each invocation of mqsicreatebar in this scenario creates a randomly different sized BAR file and multiple duplicate includes. As the BAR file is rebuilt, the duplicate includes are different, which is why the size changes. I have observed the size to go from around 5 MB for a clean build to 280 MB when mqsicreatebar stumbles around including lots of duplicate stuff in one of these scenarios.
The workaround is sufficient, and while I do not work for that particular client any longer, I am satisfied with the answer IBM provides, which is to delete .metadata directory before every build. I sort of like that answer because it is most reliable to provide a consistently clean build run, especially in an automated environment like Hudson.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
