Date: 10/12/00
- Next message: Sebastian Bergmann: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Previous message: Alexander Barkov: "[PHP-DEV] UdmSearch"
- In reply to: Chuck Hagenbuch: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Next in thread: Ron Chmara: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Reply: Ron Chmara: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 <email protected>>:
>
> > - 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 <email protected>>
> 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-----
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
- Next message: Sebastian Bergmann: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Previous message: Alexander Barkov: "[PHP-DEV] UdmSearch"
- In reply to: Chuck Hagenbuch: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Next in thread: Ron Chmara: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Reply: Ron Chmara: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

