6 ms·
PhalconPHP - High Perf PHP Framework as a C Extension
- pilif 14y agoEven 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.
- siegecraft 14y agoIt 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.
- brodd 14y agoThen you hit the database and the time spent in the framework is all of a sudden a rounding error.
- pytrin 14y agoWell put, the database is usually the bottleneck in web applications, not the language or code.
- jdub 14y agoA different perspective: If the database is the bottleneck in your web application, you have a problem in your code. :-)
- pytrin 14y agoNo, 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.
- jasonlotito 14y agoI 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.
- pytrin 14y agoCache 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.
- prodigal_erik 14y agoIf 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.
- jdub 14y agoSorry, 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!
- Negitivefrags 14y agoYou 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.
- robryan 14y agoYeah 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.
- Firehed 14y agoProbably 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.
- delian66 14y agoThe 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.
- pilif 14y agoAs 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.
- ZoFreX 14y agoIt 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.
- ppadron 14y agoThere is also YAF (Yet Another Framework)[1] by Laruence. It is being used at weibo.com [2]. Never tried it, but looks like a simplified Zend Framework. [1] http://pecl.php.net/package/yaf http://pecl.php.net/package/yaf [2] http://news.php.net/php.pecl.dev/9716 http://news.php.net/php.pecl.dev/9716
- dlsym 14y agoFalcon looks like a crossover between Rails and Zend. Yaf looks a little bit more zendish.
- latimer 14y agoWouldn't anyone who actually needs this level of performance sooner go for HipHop? It seems like you would get better performance with HipHop and still be able to use your framework of choice.
- KevBurnsJr 14y agoYou might want to read up on HPHP. I've found that it doesn't offer the level of performance benefits most people expect. Also there are a number of framework features you can't use with HPHP, like autoloaders.
- Jebus 14y agoIt was interesting, until I got to the benchmarks part. It's just another little framework trying to beat Symfony on a 'hello world' app, and obviously didn't even bother configuring it properly.
- tubbo 14y ago"Sending output on the screen from the controller is at times necessary" No, it's not.
- HyprMusic 14y agoI can't help but think if you're willing to go this far for performance, then you'd simply choose another language over PHP (or even HipHop). With this you loose the flexibility and transparency of having the framework in PHP. There have been many times when I've had to go routing through Zend framework to really understand how or why to do something a certain way.
- heretohelp 14y agoRooting. As in rooting around. Like for roots or tubers. Routing is something Netgear and Cisco do.
- dpacmittal 14y agoThat was very insightful. Thankyou.
- HyprMusic 14y agoThanks, I think it has become habit to use 'Zend' and 'Routing' together!
- nikic 14y ago1. Opened http://docs.phalconphp.com/en/latest/reference/tutorial.html http://docs.phalconphp.com/en/latest/reference/tutorial.html 2. Saw lots and lots of static method calls 3. Closed page again. This way of judging frameworks has never failed me.
- kyriakos 14y agohow's having a lot of static calls making it a bad framework?
- eckyptang 14y agoI think that might be because people who are used to writing typical object-oriented code somehow assume that an instantiation is required before you can do /anything/. There is nothing wrong with a static call under a lot of conditions (not stateful, no override requirements etc). The same people also tend not to complain about C paradoxically.
- kyriakos 14y agoSome things are just static by nature. There's no point instantiating to use their html helpers for example.
- nnq 14y ago...because you can use functions and namespaces instead? (no, it doesn't make it "bad", but it's a hint that somewhere behind it there might be some overarchitectured OO monster - I admit, it's just because I'm not that much of a fun of OOP and I don't want more objects and classes than it's strictly necessary for the "backbone" of a MVC application)
- pytrin 14y ago* You can't extend a static method call - ie, it will always refer to a specific class, you can't replace it with another without changing a lot of calls. * Lots of static calls are indicative of function classes - classes as namespaces for functions, and not a real OOP approach There's nothing wrong with static calls per-se, but lots of them is a code smell in most cases.
- kyriakos 14y agoI did spend the past hour reading through the documentation. Looks like a well-thought framework and has a couple of 'fully blown' examples. Which is good cause I hate it when I start using a library/framework only to find out hours later that its half baked. To be honest though I'd be more inclined to use PhalconPHP for its straight-forward no-bullshit documentation and real world examples rather than the fact that its written in C.
- nnq 14y ago...whenever I see a good framework build in PHP, a part of me wants to smash the developers' heads with a double clawed hammer (just for not doing something better with their lives if not for other reasons...) (I know, I know, downvotes expected, go ahead :) )
- Jakob 14y agoThe ”Number of included PHP files“ benchmark is likely flawed. In production mode Yii should use the file yiilite.php [0] which wraps most of the framework into one PHP file. [0] http://www.yiiframework.com/doc/guide/1.1/en/topics.performance#using-x-9x http://www.yiiframework.com/doc/guide/1.1/en/topics.performa...
- nikcub 14y agoThis is something that I was thinking about a long time ago. It turns out that the gain isn't worth it because of how good the bytecode caches are. The frameworks are slow in places because of some of the techniques used to make development faster and easier - such as autoload. autoload is notoriously difficult to bytecode cache It isn't a coincidence that the pitch here is against frameworks in PHP and not plain PHP itself. I'd like to see a benchmark against plain PHP, I bet there isn't much of a difference. If you really need to optimize this stuff just go into your PHP framework and rip out autoload and any fancy reflection stuff (extract, eval). Put in straight include() or require(). Use PHP for templating or a templating system that compiles to straight PHP which is include()'d. setup APC.. Saves you switching development environment, retraining developers, increasing dev time and I bet the difference in benchmarks would be pretty negligible.