Re: Re: cvs: php4 / TODO
| From: | John Donagher | Date: | Thu, 12 Oct 2000 14:31:08 +0000 |
| Subject: | Re: Re: cvs: php4 / TODO | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-34810@lists.php.net to get a copy of this message | ||
Hi Chuck-
I work for Intacct. We've built an accounting application similar to (but better than)
Quickbooks. One of the big issues we've been running into is performance due to the serial
execution path of the application. Every time a script is requested, our database abstraction layer
(written in PHP as well) has to be initialized, the schema layout has to be initialized (we have a
data structure which represents our schema layout for use in automatic query generation), and our
60K security mappings file has to be executed. This is not just simple true/false authentication,
but rather definable by each company's administrator, per user function, and granular enough to
allow different combinations of add/edit/delete permissions. So what I'm trying to get across
is that our code isn't unnecessarily bloated, but in reality things that need to be initialized
only once are instead initialized every time any script is requested.
I've been writing PHP for almost 2 years, and I'd usually be the last one to suggest
moving away from it. It was definetly a great choice in the beginning, when the application was much
smaller, we only had 5 programmers, and Oracle was the bottleneck. The language is easy for new
developers to learn, and the variety of extensions available allows for very fast development.
Unfortunately, we've reached the point where we need to look at moving data access, sessions,
and some of the other heavyweight code into some sort of stateful objects, that don't have to
be initialized on every script request.
Since this is new to me, I'm unsure of what the options are. The obvious choice is some sort of
application server using Java beans for data access and sessions, but I'm curious to see if any
other large-scale PHP projects have hit this wall, and what they did to get past it.
As a side note, I wouldn't expect PHP to change just to accomodate really large applications,
and when you think about where PHP sits in the process of an Apache request, it already does an
amazing job.
John
On Thu, 12 Oct 2000, Chuck Hagenbuch wrote:
> Quoting Sebastian Bergmann <sb@phpopentracker.de>:
>
> > - PHP Application Server
>
> What does this entail?
>
> > - Native support for Load Balancing
>
> What does this mean besides using a database backend for sessions, and
> round-robin dns or similar?
>
> > - more sophistication and a performance tuneup (to be useful on large
> > scale applications) for PHP's object model
>
> I'd love to see this, sure, especially the performance tuneup. Also, I think
> some of the core guys said that they'd be willing to implement namespaces at
> some point; I'd love to see that.
>
> > - support for large scale development
> > (options comparable to the "use strict" and "-w" modes of perl)
>
> Can you be more specific? error_reporting(E_ALL) is standard development
> procedure for me, and helps a fair amount...
>
> -chuck
>
> --
> Charles Hagenbuch, <chuck@horde.org>
> must... find... acorns... *thud*
>
>
--
John Donagher
Application Engineer
Intacct Corp. - Powerful Accounting on the Web
408-395-0989
720 University Ave.
Los Gatos CA 95032
www.intacct.com
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
mQGiBDnCZ1oRBACFgkFCV6p3dWic1qm1FLhip5beIyzZSt+ccTDYQQdPZA/t5H+k
PZ7ZFBIUrXz/oEqwQwlEKlg8JQqg7hgtcL+xrIJ0BInLeSJG4lvvB551g59Thr7/
OsdxNVxKci775+K+GkdAz4xcULMuB+QE7t665Ri46EAS8ALos5UG6DGmhwCguD0v
1cxwy/KlKr+oi4sWM9caueED/RmjiSD3vmBZQt6PMisVe1AmkEf6cJoemduCSJxu
0eMz/LIeu+CqfpuJH2N/dZ3hRj9xMSHF4l71wKqV99zhm58kDGwG1u3yVzULPDqz
0yL+8nunlkoOUyn3zOnh3Zmz4POFVMZQ5oian3QkLllUwly5JCi5tWULxZ2vOkb0
zzjuA/4jigNxYV4NAyCl+wAbnyzk9/Iz8EHv4/0Ex8ytlcMtvBJKa9HjJxlyIl74
yOILHk3+GSAdM0b3ZmbavpoCpebinOMBhqEVBwCI4VUIAqf86gx+2dKBGxfKPnU4
Xxvqs/BOl/EbeJjyd4uieYndGRaWg+kYXqZ7SxrlFN24fohnd7QgSm9obiBEb25h
Z2hlciA8am9obkB3ZWJtZXRhLmNvbT6IVgQTEQIAFgUCOcJnWgQLCgQDAxUDAgMW
AgECF4AACgkQIt6tVu6+jd3SHwCgjssFktMXf8NjE9JBR+sJ2gDIsW8An0CFNdFd
dU+DJYC6ogYP9AsVfM27uQENBDnCZ2MQBAD8E0qe1gBKjtoRmyiyORtwhOz/2XZE
mqiZN2NouAUWRRZd4dHggFAA1jUsp2MVIZZQyY9ajNVy3Oaxj5kYz8LR5GItxxcD
jC8RFXKM40ZfTJeR7fH6eJa689w+le71Tt4ALyN4xcjSWuksr8795AhHFjonDi8D
rgGIq6GtWvi/KwADBgQAmeBbcjPzhqR2M8TdvEyNfVTQSSp/RNoTjNNWpHui8V0p
kiQ49tbsqeMjXGToGgMugfmrX77JidXyuVjgYjT9xUdaaA25qKAR75M9izDliT7Y
h5L+QZTAw0/5X9go7XK3WI3LYfFrp4TP0veXgSWxDqccqsRzWKW7IoXsliTCbVqI
RgQYEQIABgUCOcJnYwAKCRAi3q1W7r6N3YIcAKCkJMTPLu6tOPnXPl2s3xmnSawy
BACeOx83WlBhVScYWo+BUzntJ6ks4T0=
=OkJU
-----END PGP PUBLIC KEY BLOCK-----