[Note: the problem described here is a significant jump in CPU usage
whenever a text input box in Publisher 2000/XP is active and waiting for
input. This is installed on a Terminal Server, and when 4-5 people have
Publisher open the system slows to a crawl.]
--
Please respond in the newsgroup. I've still got unread email from the
week Win95 was released, if that tells you anything.
http://www.bittnet.com/winremote
http://www.bittnet.com/scripting
"Peter Ashby" <pas...@vhhs.sa.edu.au> wrote in message
news:1aa0f01c230b3$c8a68270$19ef2ecf@tkmsftngxa01...
> Thanks for the thoughts Alex
>
> I've tried switching off all options such as spelling and
> grammar.
Looking through the posts, it appears you did also update to the latest
client...
> The problem ONLY occurs when a text input box is active
> waiting for keyboard input. It does not occur if the text
> box itself is highlighted - ie right click on the frame.
> It does not occur when importing graphics or wordart or
> anything else.
>
> It seems similar (same) as the keyboard polling problem
> with MSDOS programs. Surely this can't be the problem!
My first response was "of course not!" Now that I think about it, there
may be something going on where it continually checks the box for
updates. It shouldn't do this, but it's possible that bad code which is
not noticeable on most single-user systems could have slipped by,
particularly if it is not something that would crop up on every install.
> Is there anyone else with this problem?
Based on personal experience and newsgroup posting histroy in the TS
groups, it appears the Publisher is not a commonly used TS application;
this would explain the low number of posts about any Publisher on TS
issues. I've included the publisher NG since it may be a known issue on
any install of Publisher.
By the way, could you follow up with some specs on your server?
Specifically the following:
+ RAM
+ CPU speed and quantity
+ Drive size and available space on the system drive
> Peter
>
I, as well as a friend in the Microsoft Publisher division, have been able
to reproduce this EXACT CPU spike with Publisher 2002 and 2000 (we
reproduced this about a ½ a year ago) using the exact same scenario with the
text frame. There has not been any solution to this CPU spike, and the spike
is not present on ALL systems. The only thing I can do is ping him (my
friend) and see if there has been any updates.
--
Brian Kvalheim
Email: mspub...@msn.com
Microsoft Publisher MVP
For FAQ's, Templates and More:
http://www.mvps.org/publisher
<Alex K. Angelopoulos (MVP)> wrote in message
news:#h7M3cSMCHA.1468@tkmsftngp13...
I know this doesn't solve your CPU Spike questions, but this IS indeed a
known issue that does not have a KB article, does not have a known work
around, and is bugged at a possible fix for a future version.
--
Brian Kvalheim
Email: mspub...@msn.com
Microsoft Publisher MVP
For FAQ's, Templates and More:
http://www.mvps.org/publisher
<Alex K. Angelopoulos (MVP)> wrote in message
news:#h7M3cSMCHA.1468@tkmsftngp13...
Probably because the stupid programmer is using something like the old "on keystroke" loop
to get the keyboard entry.
STUPID programming ... most people would expect "better" from Micro$oft.
"Brian Kvalheim [MVP]" <mspub...@msn.com> wrote in message
news:#rnlvFcMCHA.2052@tkmsftngp08...
You would have no idea what Microsoft are using or doing, as you do not know
what you are doing.
--
Publisher Template and Sample files
http://www.users.bigpond.com/auslandline/publisher
Serif PagePlus Template and Sample files
http://www.users.bigpond.com/auslandline/serifpageplus
No.1 Oxymoron - Microsoft works
How can you be sooooooo WRONG!
"°MS°Publisher°" <no_private_c...@here.com> wrote in message
news:Oi#rfTeMCHA.1596@tkmsftngp13...
Sorry RSD, but that is not what was said..see below.
"The problem ONLY occurs when a text input box is active "waiting" for
keyboard input.The problem ONLY occurs when a text input box is active
waiting for keyboard input."
Road Side Delivery at least has Sarah to keep him warm and fuzzy feeling.
It occurred to me that the performance effects of the CPU spike may not
have been tested in a Terminal Services environment - as Peter was
saying, it seems to crop up by the 4-5 user mark but not before. Having
seen how TS "steers", I could see how a process which spikes a CPU but
drops very quickly in the presence of other user activity might make
itself much more of a pig in a TS environment. That might be worth
passing on to Rich; I'm going to do a Publisher XP install on a test TS
system when time permits and see what happens to performance if I try to
replicate the problem.
I will follow up with details when I have them.
--
Please respond in the newsgroup so everyone may benefit.
http://www.bittnet.com/winremote
http://www.bittnet.com/scripting
"Brian Kvalheim - [MVP]" <dontres...@email.com> wrote in message
news:uk44h#jMCHA.2340@tkmsftngp08...
> It occurred to me that the performance effects of the CPU spike may
not
> have been tested in a Terminal Services environment - as Peter was
> saying, it seems to crop up by the 4-5 user mark but not before.
Having
> seen how TS "steers", I could see how a process which spikes a CPU but
> drops very quickly in the presence of other user activity might make
> itself much more of a pig in a TS environment. That might be worth
> ... I'm going to do a Publisher XP install on a test TS
> system when time permits and see what happens to performance if I try
to
> replicate the problem.
>
> I will follow up with details when I have them.
>
Did it, and here's what I see.
I did a plain vanilla install of Publisher 2002 on Win2K TS; the only
customization I made was to remove the "Microsoft Office" starter from
the startup group.
I set up a remote check of the following performance counters: %
Processor Time, Interrupts/sec, Pages/Sec, and Avg Disk Queue Length,
sampled every 2 seconds.
I next did 5 simultaneous logins and launched Publisher. I was unable
to replicate pegging the CPU or forcing out of control activity on any
other counters with active text boxes waiting for input. What DID peg
the CPU, but not produce any strain on performance in other sessions,
was having the Quick Publications view open - with even one session
sitting on that screen, the CPU would remain at 100% utilization. Even
with 4 highlighting quick pubs, a 5th session had no extra lag in other
activity. This was on a system with only 160 MiB of RAM and a 233 MHz
CPU.
TO make it even more curious, there was a weird asymmetric drop when I
began closing out sessions. After dropping 2 of the 4 sessions sitting
on the Publisher opening screen, the CPU suddenly dropped to about 5-10%
use or less, even though it had "stuck" at 100% with only 1 Publisher
session open!
--
Brian Kvalheim
Email: mspub...@msn.com
Microsoft Publisher MVP
For FAQ's, Templates and More:
http://www.mvps.org/publisher
<Alex K. Angelopoulos (MVP)> wrote in message
news:#qxpA$kMCHA.2404@tkmsftngp11...
--
Brian Kvalheim
Email: mspub...@msn.com
Microsoft Publisher MVP
For FAQ's, Templates and More:
http://www.mvps.org/publisher
<Alex K. Angelopoulos (MVP)> wrote in message
news:#qxpA$kMCHA.2404@tkmsftngp11...
The implication is that this issue is a possible secondary effect of
some kind, possibly involving tuning or application/install interaction.
So we have *HALFWAY* answered Peter's original question:
> Is this a problem only on my system or universal -
It is not universal. That doesn't mean it's only his system, though.
Peter, could you also take a look through the event logs to see if
anything bizarre shows up? Also, what service pack levels are you at?
Since he appears to post through a web interface (his responses don't
include the Publisher group) I will repost his answers... I am inclined
to think we want to look at platform issues as a possibility, since some
of the packs you can apply to TS handle rare application performance
problems.
--
Please respond in the newsgroup so everyone may benefit.
http://www.bittnet.com/winremote
http://www.bittnet.com/scripting
"Brian Kvalheim [MVP]" <mspub...@msn.com> wrote in message
news:OZvuqNlMCHA.1936@tkmsftngp12...
--
Brian Kvalheim
Email: mspub...@msn.com
Microsoft Publisher MVP
For FAQ's, Templates and More:
http://www.mvps.org/publisher
<Alex K. Angelopoulos (MVP)> wrote in message
news:ewJuXKmMCHA.2400@tkmsftngp11...
By the way, you do want to install the licensing enhancements (it calls
it a security fix, but it's also the licensing hotfix) ASAP. It will
probably have absolutely no effect on the Publisher problem, but it
corrects other potential problems:
http://microsoft.com/windows2000/downloads/critical/q307454/default.asp
> The major glitch I get in the system event log with TS is
> the following
> event 1103
> An internal communication error occurred. Redirected
> printing will no longer function.
> When I delve further into the error the suggestion is that
> I reinstall terminal services. This is not a trivial
> exercise since I will have to install all of the software
> again.
> I would prefer another approach if possible.
And that's not the source of this problem anyway... :(
> Publisher continues to show excessive server usage - it
> will flatline the server at 100% with 3 TS clients
> connected to a text box. Take the focus off and the usage
> drops to nothing. All other OfficeXP apps are working
> without a hitch.
A I mentioned, I am unable to replicate the problem. I can get high CPU
use at times, but not from having a text box active. I've tried it with
5 simultaneous users on a low-RAM/slow CPU system with no noticeable
effect.
In each case I went in, created a new document, inserted a text box and
then clicked in it to activate; with 4 such sessions at once, I still
had no problems in the 5th.
The next thing I can think of is to try "trimming" options in Publisher.
Make sure no Office applets are autostarting from the startup folder,
even try disabling live spellchecking (although that usually has no
significant effect).
If that does not work, it may be possible to start investigating
profiling Publisher on your system, but that can get a little more messy
so I would think we want to try checking features first.
> Regards Peter