NetTalk Central

Author Topic: printing slows the server  (Read 3312 times)

MyBrainIsFull

  • Full Member
  • ***
  • Posts: 134
    • View Profile
printing slows the server
« on: August 11, 2015, 06:43:33 PM »
Hi all, anyone noticed how printing slows the server down?  Looks like there is a timer hitting the server about ten times a second for a report.

I watched a user open up several tabs on a browser and have the same report on each, then went for coffee and came back to a different work station and repeated this,

I saw the server being hit hard by this, somehow they managed to close some reports but the choice of pdf or print remained for several instances and so kept slamming the server. They just walked off and did some other work. I had to use the task manager to kill them.

I either need better customers or a way of controlling the timer.

k

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11251
    • View Profile
Re: printing slows the server
« Reply #1 on: August 11, 2015, 09:56:27 PM »
Morning Kevin,

>>  anyone noticed how printing slows the server down?  Looks like there is a timer hitting the server about ten times a second for a report.

So the report is a "standard" Clarion report procedure - which is based on the Process class, which yes, uses events to work through the records. It typically adjusts the timer so that it generates "as fast as possible" while at the same time keeping the UI responsive.

The degree to which this slows down the server itself depends on a number of factors.

a) the time it take for the report to actually get generated. Small, fast reports are obviously faster than big slow ones.

b) the longer it takes, the more time (on a single core) the report eats up. Other threads on other cores go fast, other threads on the same core slow down. So a CPU with more cores is better able to handle this than a CPU with fewer cores.

>> but the choice of pdf or print remained for several instances

Choice of PDF or Print? This should not be coming up for reports at all (and should be considered a bug.) The reports should not open any user input on the server side.

>> I watched a user open up several tabs on a browser and have the same report on each, then went for coffee and came back to a different work station and repeated this,

Asking the server to perform the same task n times will take n times longer than asking it to do it once.
If they were indeed after the _1_ report then I guess the best thing is to find out whythey took the approahc they took, and what they were hoping to achieve.

>> I either need better customers or a way of controlling the timer.

The only effect of manipulating the timer would be to slow the report down. I'm not sure that would solve any problems though - and may increase them.

As an aside, it is of course possible to affect any server by giving it lots of gratuitous work to do. This is effectively a "denial of service" attack - although attack is a strong word. If the server itself is not up to supporting normal load, then obviously that has to be dealt with. But if the user is just trying to show they can slow the serer down, well that's not terribly useful to anyone, and is basically sorta like graffiti - sure, anyone can do it, it doesn't make you clever, but mature folk don't usually indulge in it. this is often mitigated in the simplest way - remove that user from the system, or curtail their rights.

I'm not suggesting this was a malicious act by the user - but it's worth finding out _why_ they did it. Perhaps they need a bunch of reports in the morning - in which case you could just pre-generate them and deliver them via email etc.

cheers
Bruce