• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Performance and Memory
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Performance and Memory


  • Subject: Performance and Memory
  • From: Ian Joyner <email@hidden>
  • Date: Fri, 10 Feb 2006 16:55:31 +1100

I have another performance problem I have been trying to track down for a few days. Basically, I have groups, which are n:m with members through a join table. Members are 1:n with phone numbers. On the main screen for groups, we see a list of members with their telephones (nicely concatenated together into one column).

Now the performance problem was that when a group was selected, I got a whole lot of SELECTs executed (one for each member) to load the telephones. Originally, I had a flattened relationship in group, 'member_telephones', which I used to load all the phone numbers for members in one hit, and then a routine which got the right numbers for each member - pretty instantaneous, but with the drawback that if numbers were changed or added, they did not appear on the group screen (because of stale data problems with flattened attributes).

So, attempt 2 was to make a fetch spec in EOModeler that did a preload on the telephone records 'Group_Member.Member.Telephones' which along with setting 'Cache in Memory' on telephones loaded all these upfront, but then the selecting different groups became pretty instantaneous.

However, once the app has been used for a while, the client app seems to revert to getting the telephone objects from the server side. I don't see selects, but a lot of:

[2006-02-10 13:31:31 EST] <WorkerThread7> <WOInputStreamData>: Reading InputStream into byte data
[2006-02-10 13:31:31 EST] <WorkerThread8> <WOInputStreamData>: Reading InputStream into byte data
[2006-02-10 13:31:31 EST] <WorkerThread9> <WOInputStreamData>: Reading InputStream into byte data
[2006-02-10 13:31:32 EST] <WorkerThread10> <WOInputStreamData>: Reading InputStream into byte data
[2006-02-10 13:31:32 EST] <WorkerThread11> <WOInputStreamData>: Reading InputStream into byte data
[2006-02-10 13:31:32 EST] <WorkerThread12> <WOInputStreamData>: Reading InputStream into byte data
[2006-02-10 13:31:32 EST] <WorkerThread13> <WOInputStreamData>: Reading InputStream into byte data
[2006-02-10 13:31:32 EST] <WorkerThread14> <WOInputStreamData>: Reading InputStream into byte data


in fact one for each telephone number. Then surprisingly, for a group that has not been touched or loaded yet, performance reverts back to being good, without going back to the server.

It feels like a memory problem, because it's somewhat erratic and unpredictable where performance degredation will occur. If someone can think of another reason, please let me know, but my question is, how can I increase the memory allocated to a Java-Client app? Will - Xmsn and -Xmxn do this, and what are the default values anyway?

Some questions on the 'Reading InputStream into byte data': These seem quite slow, is there an optimization that could be done? Obviously, I'd like to avoid it altogether. Is there a way of finding out which particular objects are being read? This is obvious where the database is accessed because you see a SELECT before the InputStream stuff, but if you have cached set, EO gives you no indication as to what is being read.

Thanks
Ian Joyner
Sportstec
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Performance and Memory
      • From: Arturo Perez <email@hidden>
  • Prev by Date: Re: Some help with Optimization
  • Next by Date: Re: Newbie Key Value-coding and Subclasses Question
  • Previous by thread: Re: tomcat deployment
  • Next by thread: Re: Performance and Memory
  • Index(es):
    • Date
    • Thread