Hacker News Reader

Comment by pilif | Hacker News Reader

Even with a really complicated framework, when considering APC, I doubt that the time spent in the framework is at all significant when compared with the time required for the application itself.

They know that too probably which is why their benchmark in the embedded slides is completely meaningless (just a simple hello world)

When you switch to C for the framework code, what you gain in speed, you lose in flexibility, customizability and ease-of-deployment.

That said, a quick look at their documentation shows a nice framework that doesn't enforce too much structure while still providing the necessities that plain PHP doesn't.

View on HN

It seems more likely that you'd spend more time in the framework. After all, it gets used on every single request, whereas your time-consuming app-specific code is probably only a few core pages of your site.

Then you hit the database and the time spent in the framework is all of a sudden a rounding error.

Well put, the database is usually the bottleneck in web applications, not the language or code.

A different perspective: If the database is the bottleneck in your web application, you have a problem in your code. :-)

No, you still have a problem in your database. Running a database smoothly with large datasets is the main performance problem for web applications. As fast as you can get with smart DB architecture, DB calls still take the bulk of the time compared to code running time.

I think the point is the problem isn't with the database, but with the code not cacheing results. This isn't some new problem. The database shouldn't be the problem because you should be cacheing results.

Cache is a not a solve-all solution. It is useful only for commonly used data, otherwise you just transfer the database problem to a caching problem.

If you squint, every database problem is a caching problem. The only reason we store the relations in their up-to-date form is that it's too expensive to continually replay the transaction log from the beginning of time.

Sorry, but that simply isn't true for plenty of applications, particularly if they happen to be built on relatively slow platforms like PHP, Ruby, Python, etc. That's even before we get to the bulky frameworks built on top of those!

If your data store structure and queries (SQL or otherwise) are designed to perform and scale, you can get in and out very quickly (milliseconds or less), after which you'll spend most of your time turning the data into something useful.

(That's even before we talk about caching so you don't have to talk to the data store at all...)

Facebook didn't write HipHop (and reduce CPU utilisation by 50%) because their database queries were slow!

You are using the term bottleneck incorrectly, and it's a very common error.

A bottleneck is something you get when you have multiple concurrent actions and one of them is slowing down the actions of the others. No matter how fast the other actions get, the slowest one is the bottleneck.

Framework overhead is not a bottleneck at all, it's just overhead. If your framework takes 10ms to load, it doesn't matter if your database is taking 200ms or 2ms to return it's result, you still pay the extra 10ms for the framework loading. This is because the 10ms is not concurrent with anything, you just pay it at the start regardless.

Now you can argue that the 10ms is not significant when compared to the 200ms your spending in your database, but this is an entirely different kind of argument.

Yeah I don't really see the point with your average web app requests, if anything is so intensive as for this framework to make a difference it is likely better done in the background rather than as part of a user request.

Granted it may well be good for common functions required in intensive background processes.

Probably due to the garbage SQL the framework generated for you, or the write-through cache it failed to provide.

Yes, it's true that a simple request router will probably not add a lot of overhead, whether it came from a framework or was something you rolled yourself (there's only so many ways to parse a URL). The real overhead comes from the other stuff the framework does, and chances are the heavy lifting will be in an ORM and a couple helper functions with badly written regular expressions.

Disclaimer: I haven't looked at the code for this framework, but that's pretty common among all of them.

The point of making a benchmark of a 'Hello World' is to show the overhead of a framework, compared to a simple PHP <?="Hello World"?> equivalent.

Such a benchmark, gives you a sense of how bloated/(or feature rich depending on your point of view) a given framework is, and also a rough view of the hardware resources (mainly RAM and/or CPU), which you will need to deploy a site based on it.

Thus said, it would be usefull for them to put a simple PHP baseline shown in the slides too.

As brodd says below: the moment you do something useful the percentage of time wasted by the framework becomes so small that it's in many cases not worth optimizing there.

It would still be useful to know the constant amount that the framework would add to any request. If it's 50ms, cool. If you do a hello, world and it comes out to hundreds of milliseconds, that's a lot less cool.

Reply on news.ycombinator.com