If you have over 20 concurrent Evolution users and people print their email (which they do!), cupsd gets hammered and consumes a lot of resources. It appears that if you print once from Evolution, you continue to always request status information from cupsd repeatedly until you close the current session. Cupsd is unable to keep up with the requests fast enough and what happens is that the Evolution composer window gets horribly unresponsive. The letters appear in the text widget at about 1/5 the speed of what you can type.
Before the patch, here is what cupds looks like with around 40 concurrent users. Notice cupds consuming CPU time. At the time of the shot, no print jobs were in the queue.
I make the following change to the code and recompile:
diff gnome-cups-printer.c.orig gnome-cups-printer.c
38c38
< #define UPDATE_TIMEOUT 5000 --- > #define UPDATE_TIMEOUT 500000
diff gnome-cups-queue.c.orig gnome-cups-queue.c
16c16
< #define UPDATE_TIMEOUT 3000 --- > #define UPDATE_TIMEOUT 300000
I then replace the stock libraries and reboot and today with identical user load, cupsd barely shows and the slow typing issue is fixed.
The server is now ready for 200-300 concurrent users. I'm not sure why Evolution keeps polling cupsd after a print job has been submitted. This change makes no apparent changes to the print process. libgnomecups should be altered in a manner that scales better, or at a minimum allow an environmental variable to be read. That would eliminate the requirement for a patch and recompile.
4 comments:
Mr. Richards,
I really appreciate your blogging about all the issues you and Largo encounter with GNOME, and that you persevere. I know a few people who have encountered less significant problems and given up pretty readily. Do you find that Linux and GNOME, despite the problems you encounter, are making good progress? I suppose you still find them worth your while, since I have not read of plans to migrate away :)
Rice crispies,
Richard
Can you file bugs for both Evolution and libgnomecups? Evolution shouldn't poll cups so often and libgnomecups should have your patch in by default?
Richard: Thanks for the kind words. The biggest issue is that developers are bored with legacy equipment and versions of GNOME that are more than a few months old and no longer patch them. It's boring to them to support 8 bit and 16 bit because they have new video cards...but fail to remember that possibly other people have this hardware deployed in great numbers. And they also forget that OpenSuse 10.2 or SLED 10 might be the latest *supported* versions of GNOME that I can install. So it being in some future version doesn't help me right now. A basic set of features and QA specs should work in *every* version of GNOME in my view. GNOME is still working for us, and the SLAB really has made it a no brainer to continue its' use.
sejeff: I would gladly submit the change; what would be helpful to me is knowing for sure that it's a "bug". That timeout might be a feature that a person on a standalone computer uses. I'm wondering if it's maybe there to allow USB printers that are hot swapped into a laptop to immediately be known to GNOME. In our case, we don't use that feature. But others might, obviously.
You might want to check out http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=280718. The bug is closed, but I don't think the problem has gone away.
Post a Comment