phpgroupware-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Phpgroupware-users] PHPGW is Dang Slow


From: Tomasz Spyrczak
Subject: RE: [Phpgroupware-users] PHPGW is Dang Slow
Date: Wed, 16 Jul 2003 18:01:36 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello people!

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden 
> Behalf Of Chris Weiss
> Sent: Wednesday, July 16, 2003 3:26 PM
> To: address@hidden
> Subject: RE: [Phpgroupware-users] PHPGW is Dang Slow
> ohhh, this is gonna be a problem.  IIRC this table is used for DB 
> sessions and
> doens't get used at all for php4 sessions.  Apps can store 
> whatever they want in
> here.  For Email, the entire message list (minus body's) of the 
> current folder is
> stuffed in here, think 5000 messages is NOT gonna fit in 1000 
> characters.  it
> /needs/ to be text.

Thanx for the info. Still, variable lenght of the "content" field in
this table is the major cause of some very nasty slowdowns. So it
seems that one should use PHP4 then.

> Most of the things that are text are that way by design and not 
> because someone was
> being lazy.  Also, many RDBMS's only support up to varchar(255) 
> so that's all we can
> depend on, and if we need more than 255, or in the case of app 
> session more than 8k
> (dunno about pg but that's MSSql's max varchar) then text is it.
> 
> seems in this one case using php4 sessions would fix your login
> slowdown.  

And that's the f'ing problem. But not for the PostgreSQL, MS SQL,
Oracle nor any other "professional" or "enterprise" ;-) RDBMS' out
there that can handle varchar fields of "infinite" lenght - for
example my favourite Postgres 7.2 can handle varchars up to 1GB. So
if there are users who use such databases, they should be able to
utilize them in full, shouldn't they? Anyway, imho the
interconnection between "text" fields and the database performance is
a very, very serious issue. And (imho again) phpGW team should at
least take it into consideration in future developement of phpGW.

> Also, 128Meg of RAM is sorta the "bare minimum" for an apache web 
> server, not
> counting a database or HTTPS or running anything other than 
> static HTML on top of
> it.  I'm guessing your swapping, no I'd put money on it your 
> swapping, which will
> definatly cause slow downs because the database won't have 
> anywhere to cache to.
> I'd recomend at least 256meg for a small phpgw install.  Heck, I 
> personally wouldn't
> put less than 512Meg in /any/ kind of server.  swap = bad!

And here Chris I strongly disagree whit you. One can run phpGW
perfectly on a machine with 128 megs of RAM only. One just has to
know how to do that ;-) Here are some tips:

1. Install it on a dedicated server. It is rarely a problem to do
that when you use it on a LAN only.
2. Stop unused daemons - like sound, samba, cups, telnet or any other
shit that comes preinstalled in every major Linux distro lately.
3. Reduce the number of Apache instances kept in the server memory.
Default setting in most distros is 10 Apache instances - way too much
if you have a dedicated phpGW server with up to 50 users. It is rare
when more than 2 instances are needed. Also take care about the
number of mgetty instances - who needs more than 1 virtual console,
when one always uses ssh?

So by meeting these guidelines I've managed to set up a Pentium
150MHz with 64MB (yeah - sixty four) with apache 1.3, php4,
postgresql (mandrake 9 distro) and APC. And it was a perfecty usable
phpGW install. The funny thing is that with several users the average
swap file usage was about 0 (zero). You knwo how they say: 640 kb
ought to be enough for everyone ;-) Of course it was an experiement,
but one should know it is doable and fully usable :-)

Best regards
Tomasz Spyrczak
address@hidden

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPxVowsbMsgKq/FYXEQIGPwCeOcGylA6XI34A8Iaitbgt3aIFp1kAoPl7
08BmtAvXPeYGSXMXpZZPbLNQ
=mB7Q
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]