Post by EMS SolutionsThanks Karl,
I have finished my testing and it looks like Windows 2003 Server and
Windows XP offer much more room to move when GDI handles are concerned
compared to Windows 2000. I did manage to find hard limits on repeated tests
of each O/S.
Post by EMS SolutionsNote that I used the application KillNT.exe from
http://www.fawcette.com/archives/premier/mgznarch/vbpj/2000/02feb00/ap0200/ap0200.asp
Post by EMS SolutionsThis was very useful in proving the upper GDI object limits of each O/S.\
See below for results.
Thanks very much for all your assistance. You were a great help and I
think we've got a good result.
Post by EMS SolutionsPost by Karl E. PetersonPost by EMS SolutionsIf I fire up a few of the GDI hungry apps, flick between the many
screens available within the application and watch the GDI handles
grow and grow, you can guarantee a serious GDI failure at around
10,000 GDI handles. Every time! That's a pretty firm limit in my
book.
16K should be the upper limit. How are you finding that number?
You are right - it was 16K and not 10K sorry. Interesting that using more
than around 14,000 in W2K and 40,000 in W2003/XP causes forms to overlap and
not refresh properly as the O/S struggles with all the GDI's.
Post by EMS SolutionsPost by Karl E. PetersonPost by EMS SolutionsI will test
this on a Windows 2000 Terminal Server, then re-test with the same
server loaded with Windows 2003 Server. I'll let you know the
results. Basically I just want to be sure the GDI limitation is
noticeably higher on Windows 2003/XP.
Please let us know!
Windows 2000 definitely has a GDI object limit per user of 16,000 handles.
I could repeatedly 'break' the O/S once I exceeded this number of handles.
Anything below this was fine. I noted that in a Windows 2000 Terminal Server
situation, there is no server-wide GDI Object limit. That is, many users can
login to the Terminal Server and use an undetermined amount of GDI objects
in total (I saw a combined excess of 80,000 GDI's on W2K and W2003 servers),
however no SINGLE user can take more than their 16,000 limit within a
session without failure. System failure after exceeding the GDI limit is
also isolated to the Terminal Server session and not server wide, which is
nice.
Post by EMS SolutionsI then re-tested everything on Windows 2003 Server and found the upper
limit for a single user is definitely 65,536 GDI objects. Again the server
has no apprent limit for total number of GDI's for all users combined. Looks
like upgrading to Windows 2003 Terminal Server and Windows XP is the answer
for us and our clients to avoid these errors.
Post by EMS SolutionsPost by Karl E. PetersonPost by EMS SolutionsJust to frighten you all - our app which seems to tip the O/S over
the edge can consume as many as 6,000 GDI handles on it's own! Our
development team are telling me there is not a great deal else we can
do with VB6 and the amount of Grids and Forms needed in the
specification. Ie, we need this many handles to provide the
functionally rich application and also give good performance when
switching between screens. We use a few 3rd party Grids, Tree Views
and List Bars, so perhaps there is nothing we can do... Let me know
if you think otherwise. I agree from a network Admin point of view
that perhaps the O/S is not to blame, but the application's hungry
GDI usage.
Saying there's nothing you can do is a total cop-out. There's lots you can do, but
it wouldn't be easy, especially with similar performance. I don't think I could
recommend an app that was written like this. Then again, if the customer specifies a
pig, who am I to deliver a greyhound?
Hehe... this app definitely isn't a greyhound! It was pretty much customer
specified and now we are seeing the poor results... We are looking at ways
to improve it and the bulk of the GDI memory usage has been traced back to
our extensive use of functionally rich grids (using TrueDBGrid 7.0). These
grids can be sorted, grouped coloured and there are around 12 of them in
this one app! Removing these grids from the exe has seen an 80% improvement
in GDI usage and also a dramatic memory usage reduction. There is more work
to do here but at least these findings have given us a workaround with the
O/S to prevent the errors we were seeing by hitting the GDI limits on W2K.
Post by EMS SolutionsPost by Karl E. PetersonLater... Karl
--
[Microsoft Basic: 1976-2001, RIP]
Thanks for the feedback.
I was mistaken (Hear that Karl. <smile>).
M$'s definition of "unlimited" was exactly what they were saying - "The
individual limits impossed by 'Earlier' platforms have been removed". But
that didn't mean there aren't "new" limits - only expanded bigger ones.
Hoisted by Micro-Speak and marketing.
I am really glad to see the work you did with TS applications. The phenomena
you mentioned had a lot to do in obscuring my view of what the limits really
were. Most 'huge' apps I have worked with were TS.
As for your observation on the TrueGrid, I also use it, and did occasionally
start to run into difficulty. We 'resolved' (work-around?) the problem by
reducing the number of Grid controls and heavily abusing the few remaining.
Quite often completely reconfiguring them on the fly. This had the expected
result - we made the app a little leaner and reduced the memory footprint,
but introduced delays when we switched context. (Damn trade-offs.)
Thanks again for sharing your results - I won't be so foolish the next time.
Well on "limits" anyway - there is still plenty of other areas and facts I
can stumble over. When it comes to being adamantly wrong - little discourges
me from doing my best. <g>
-ralph