[imp] horde/imp migration problems, cpu bound on solaris

[Vasilios Hoffman]

I'm going to try the php accelerator -- I've done everything else
applicable that the http://cvs.horde.org/co.php/horde/docs/PERFORMANCE
docs mention (oh, and mcrypt).

Another suggestion was to take a look at my php.ini and see if there's
anything there.  the only things different from the php.ini-dist that I
changed were:

469c469
< upload_max_filesize = 20M
---
> upload_max_filesize = 2M
642c642
< mysql.default_socket = "/tmp/mysql-port3406.sock"
---
> mysql.default_socket =
807c807
< session.save_path = "2;/usr/local/imp3.2/cache/session_data"
---
> session.save_path = /tmp
864c864
< session.bug_compat_warn = 0
---
> session.bug_compat_warn = 1

but I'll read the 1000 lines or so and see if there's anything that could
make a difference, but I would be surprised if the drastic change I was
looking for is there (albeit happily surprised!)

thanks for the feedback,

-V

On Wed, 9 Apr 2003, Charlie Reitsma wrote:

> look for the thread in the archives "single machine vs. load balancing." Pretty
> much Ion Cube's php accelerator made horde/imp usable for me on a Sun Netra X1
> with single CPU. Load balancing across multiple machines helps a great deal
> also.
>
> Quoting Vasilios Hoffman <vhoffman01 at wesleyan.edu>:
>
> > Hi folks,
> >
> > We've a 4 processor sun e450 (4x400mhz US-II) with 4 gb of ram.  It's been
> > running an older version of horde/imp for webmail.  from what I can
> > dig out of the current setup we're looking at:
> >
> > apache 1.3.12
> > mysql 3.21.33
> > php 4.1.2
> > horde 1.0.11
> > imp 2.0.11
> >
> > Nobody's really touched it for years (since 2000 it looks like) and
> > they've enough problems that it became ample time for an upgrade.  Note
> > that I'm also a recent hire, so I wasn't around when they first set it up.
> >
> > I went through all the trouble of setting up a new Imp/Horde:
> >
> > apache 1.3.27
> > mysql 4.0.12
> > php 4.3.1
> > horde 2.2.1
> > imp 3.2.1
> > turba 1.2
> >
> > compiled w/ gcc 3.2.2 (first gcc 2.95.3 and then again w/ 3.2.2) and it
> > has the bells and whistles (imap support, ldap support, hashed php
> > sessions, imapproxy, whatever else I could find and throw at it that it
> > seemed to want).
> >
> > Now, previously Horde/Imp was I/O bound -- those flat text inboxes scale
> > poorly and every page reload would drag lots of I/O off the server.  Was
> > hoping imapproxy would aleviate that somewhat, plus we switched to a
> > hashed /var/mail and newer imap, pop, and other servers which should help
> > a bit.  Ultimately going to move away from flat inboxes, but one step at a
> > time.
> >
> > The new Horde/Imp.... CPU bound.  Ridiculously so.  Bringing up the login
> > page eats up 1% of the cpu, and a single login takes up to 8% of the
> > processor AND takes seconds to execute.  Seconds.  Like 4 or 5, not 1.
> > We tried a test on the machine, and about 35 concurrent connections would
> > cripple the CPU.  I/O was fine, memory was fine, but the load jumped over
> > 50 and the machine was rendered unusable.
> >
> > I can't believe that php or the new Horde/Imp setup is unusable with 35
> > connections on a 4-processor sun enterprise server.  I realize there is
> > more php to process... but... even 1 user is too slow!!
> >
> > and it's definately php -- if I compile php as a DSO, I can watch libphp
> > during a login in top and truss, and it's chugging along with 5-8% of the
> > processor and no I/O.
> >
> > So is this normal?  Is this the performance everybody else is getting?
> > Should I be talking to the php folks, or is it something specific to the
> > horde code?  Is there anything I can do to speed up the php processing?
> > I looked at the php readme's,etc, and I've configured the pants off it and
> > every other application involved and I don't think I missed anything
> > obvious.
> >
> > Any feedback would be appreciated.  If there's some easy php profiler I
> > can use to find out where it's spinning it's wheels, that would be great
> > as I'd rather not profile it by hand.  I'm hoping it's something I can
> > fix, and not just all the new functionality slowing things down
> > significantly.
> >
> > If it's just the new code, than please tell me what kind of machine you
> > all think could reasonably process say, ~100 active users, give or
> > take.... because currently, we can.  It's slow when it peaks like that,
> > the load can hit 10 or 12, but it's usable enough.  I can't imagine the
> > new horde/imp cuts that down to 0, I must be configuring something wrong,
> > etc.
> >
> > Thanks in advance,
> >
> > -V Hoffman
> >
> > Vasilios Hoffman
> > Junior Unix Administrator
> > Wesleyan University
> > voice (860) 685-3142
> > fax (860) 685-2401
> >
> >
> >
> > --
> > IMP mailing list
> > Frequently Asked Questions: http://horde.org/faq/
> > To unsubscribe, mail: imp-unsubscribe at lists.horde.org
> >
>
>
> Charlie Reitsma
> Systems Engineer
>
> --
> IMP mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: imp-unsubscribe at lists.horde.org
>