Usage of PHP-Frameworks

[Arwed Schmidt]

Hello,
to me, the speed Zend Framework took from me was too much, so I've
made some benchmarks and got to this:

- Never use the complete Frameworks. I'm currently writing a tool for
extracting Zend Framework Code to a new file with the components //
classes // (and even methods) you want to. There will also be a
"required"-Functionallity so you can easily get everything you need.

- Try to stick everything in 1-3 Files; includes oder requires are
quite costly, depending on your filesystem (especially security
features)

- You _can_ save microseconds by deleting comments. <-- not 100% sure
about this might be a benchmark error.

Short post - but I hope you can use it; port it to other Frameworks.

Yours,
Arwed

[Arwed Schmidt]

To make 1st point more clear: I'm putting about 50 classes in one .php-
File which I include, or if the script is complex directly into the
head where I want to use it.

PS: Anyone having an interest in my internal tool to be made freely
avaiable to others ?

[Bruno Vieira]

Hi there!

I'm using Zend framework in a project too. I would like to try your tool and check if it helps on the performance of my application.

Thank you!
Bruno.

--
Bruno Vieira
----------------------------------
http://docamandro.com
http://bokinos.blogspot.com

[Den Golotyuk]

Have you tried this tool: http://eaccelerator.net/

It supposed to solve "many includes" problem because it does
intermediate code caching.
Also it speeds up sites with huge code volumes greatly.

Den

[Brian Lee]

Hi Arwed,

Do you have some reports and detailed analysis on this?

I am really interested to see why this is the case.

I am also interested to test your tool, so if you need some testers,
you got one here.

Brian

[datasage]

PHP Frameworks by themselves can add a lot of overhead, but well
designed frameworks save quite a bit of development time. In
application development that is where the real costs are. Even with
optimization, you can still throw more hardware for performance for
less than hiring a developer.

But you can do a few things to mitigate performance issues of
frameworks.

- Bytecode caches, like APC and other similar tools can sort of "pre-
compile" and cache the processed code to reduce processing time with
later requests. These tools sometimes have issues with how you include
external files.

- require_once/include_once is expensive. When using this function,
php will search each path in your include_paths directive, until it
finds a matching path. Avoid this when possible.

- Include with absolute paths when possible - PHP will cache these
includes internally.

- Limit the number of path in the include paths directive.

- Depending on your application, you may want to consider using
memcached to cache data from certain kinds of queries. Or even views
or partial views if it changes infrequently.

- Caching is good, but it does not fit every application. Look for
instances where data is fairly static or changes less frequently.

Dan Johansson

[jimbo]

Hi Arwed,

Very interesting post.

I'm not sure I agree with your premise: "Never use the complete
Frameworks".

We use a Framework we've been developing here for a few years and on
average it makes page requests faster, not slower... and I agree
wholeheartedly with datasage too - they can make development a lot
faster and cheaper.

How can frameworks make things faster?

1) Caching. ( Personal choice is xcache for PHP - take a look at
that ). Sure, you can cache without a framework but, at least in our
case, because the framework understands the request, what modules
should be used in the response, the session state etc. etc. it can
intelligently determine whether to leverage the cache to expedite the
response. Caching can include raw chunks of html, sql selects ( that
we compile, so are worth caching ), sql response data, session data
etc.. anything that costs you to produce...

2) Solving common problems. If you're developing everything by hand
you're potentially having to solve the same issues again and again and
you're relying on the person doing that to be able to write fast code
that doesn't memory leak. Abstracting things allows you to leave the
speed and memory consumption in the hands of those who know what
they're doing.

3) Rolling out improvements. If you build lots of sites with the
same framework ( as we do ) then when you make improvements they can
be rolled out under all your sites without having to alter any of the
sites themselves. This is only possible if you've abstracted your
site code from the layer underneath - the framework. Recently we
made a big improvement to our flight-weight data model which sits
underneath most of everything else... we improved both raw-speed and
memory consumption and waste. One set of updates to the servers made
all of our sites a hell of a lot faster without changing any client
code.

Finally, as datasage says above - totally agree that use of Frameworks
can lower the cost to employ people.

There's an interesting interview of the guys at Digg here:
http://boagworld.com/podcast/144-scale

... where they discuss the fact that they employ pretty standard
architectures and frameworks so that they can get lots of cheap,
talented people to build cool stuff without having to spend the first
6 months of a new person's employment training them up.

Your tool sounds very interesting though.

I've two similar PHP5 classes if you're interested;

1: Benchmark: Pretty basic, call from wherever and it builds up a
tree-structure of where you're spending cycles; prints it out as a
little html tree or to error_log

2: Memory: Call from wherever; looks for memory consumption and
catches objects that aren't getting destroyed correctly ( PHP5 still
doesn't destroy circular references properly ( AFAIK ) )

All the best,

Jimbo