I know there already are a lot of posts floating on the web regarding this topic.
However, many people tend to focus on different things when talking about it. My main goal is to create a scalable web application that is easy to maintain. Speed to develop and maintain is far more appreciated BY ME than raw performance (or i could have used Java instead).
This is because i have noticed that when a project grows in code size, you must have maintainable code. When I first wrote my application in the procedural way, and without any framework it became a nightmare only after 1 month. I was totally lost in the jungle of spaghetti code lines. I didn't have any structure at all, even though i fought so badly to implement one.
Then I realized that I have to have structure and code the right way. I started to use CodeIgniter. That really gave me structure and maintainable code. A lot of users say that frameworks are slowing things down, but I think they missed the picture. The code must be maintainable and easy to understand.
Framework + OOP + MVC made my web application so structured so that adding features was not a problem anymore.
When i create a model, I tend to think that it is representing a data object. Maybe a form or even a table/database. So I thought about ORM (doctrine). Maybe this would be yet another great implementation into my web application giving it more structure so I could focus on the features and not repeating myself.
However, I have never used any ORM before and I have only learned the basics of it, why it's good to use and so on.
So now Im asking all of you guys that just like me are striving for maintainable code and know how important that is, is ORM (doctrine) a must have for maintainable code just like framework+mvc+oop?
I want more life experience advices than "raw sql is faster" advices, cause if i would only care about raw performance, i should have dropped framework+mvc+oop in the first place and kept living in a coding nightmare.
It feels like it fits so good into a MVC framework where the models are the tables.
Right now i've got like 150 sql queries in one file doing easy things like getting a entry by id, getting entry by name, getting entry by email, getting entry by X and so on. i thought that ORM could reduce these lines, or else im pretty sure that this will grow to 1000 sql lines in the future. And if i change in one column, i have to change all of them! what a nightmare again just thinking about it. And maybe this could also give me nice models that fits to the MVC pattern.
Is ORM the right way to go for structure and maintainable code?
Ajsie,
My vote is for an ORM. I use NHibernate. It's not perfect and there is a sizable learning curve. But the code is much more maintainable, much more OOP. Its almost impossible to create an application using OOP without an ORM unless you like a lot of duplicate code. It will definitely eliminate probably the vast majority of your SQL code.
And here's the other thing. If you're are going to build an OOP system, you'll end up writing your own O/R Mapper anyway. You'll need to call dynamic SQL or stored procs, get the data as a reader or dataset, convert that to an object, wire up relationships to other objects, turn object modifications into sql inserts/updates, etc. What you write will be slower and more buggy than NHibernate or something that's been in the market for a long while.
Your only other choice really is to build a very data centric, procedural application. Yes it may perform faster in some areas. I agree that performance IS important. But what matters is that its FAST ENOUGH. If you save a few milliseconds here and there doing procedural code, your users will not notice the performance increase. But you 'll notice the crappy code.
The biggest performance bottle-necks in an ORM are in the right way to pre-fetch and lazy-load objects. This gets into the n-query problems with ORMs. However, these are easily solved. You just have to performance tune your object queries and limit the number of calls to the database, tell it when to use joins, etc. NHibernate also supports a rich caching mechanism so you don't hit the database at all at times.
I also disagree with those that say performance is about users and maintenance is about coders. If your code is not easily maintained, it will be buggy and slow to add features. Your users will care about that.
I wont say every application should have an ORM, but I think most will benefit. Also don't be afraid to use native SQL or stored procedures with an ORM every now and then where necessary. If you have to do batch updates to millions of records or write a very complex report (hopefully against a separate, denormalized reporting database) then straight SQL is the way to go. Use ORMs for the OOP, transactional, business logic and C.R.U.D. stuff, and use SQL for the exceptions and edge cases.
I'd recommend reading Jeffrey Palermo's stuff on NHibernate and Onion Architecture. Also, take his agile boot camp or other classes to learn O/R Mapping, NHibernate and OOP. Thats what we use: NHibernate, MVC, TDD, Dependency Injection.
A lot of users say that frameworks are
slowing things down, but I think they
missed the big picture. The code MUST
BE MAINTAINABLE and EASY TO
UNDERSTAND.
A well-structured, highly-maintainable system is worthless if its performance is Teh Suck!
Maintability is something which benefits the coders who construct an application. Raw performance benefits the real people who use the app for their work (or whatever). So, whose concerns ought to be paramount: those who build the system or those who pay for it?
I know it's not as simple as that, because the customer will eventually pay for a poorly structured system - perhaps more bugs, certainly more time to fix them, more time to implement enhancements to the application. As is usually the case, everything is a trade-off.
I've started developing like you, without orm tools.
Then i worked for companies where software development was more industrialized, and they all use some kind of orm mapping tool (with more or less features). The development is far easier, faster, produce more maintainable code, etc.
But i've also seen the drawbacks of these tools : very slow performance. But it was mostly misuses of the tool (hibernate in that case).
Orm tool are very complex tool, so it is easy to misuse them, but if you have experience with them, you should be able to get nearly the same performances as with raw sql. I would have three advices for you :
If performance is not critical, use an orm tool (choose a good one, i am not developing with php, so i can't give you a name)
Be sure for each feature you add, to check the sql that the orm tool produce and send to the database (thanks to a logging facility for example). Think if it is the way you would have written your queries. Most of the inefficiencies of orm tools come from unwanted data that are gathered from the db, unique request split in multiple ones, etc. Slowness rarely comes from the tool in itself
Do not use the tool for everything. Choose wisely when not to use it (you reduce maintainability each time you do raw db access), but sometimes, it isn't just worst trying to make the orm tool do something it was not developed for.
Edit:
Orm tool are most useful with very complex model : many relationships between entities. Which is most of the time encountered in configuration part of the application, or in complex business part of the application.
So it is less useful if you have only few entities, and if there is less chance they get changed (refactored).
The limit between few entities and many is not clear. I would say more that 50 differents Types (sql tables, without join tables) is many, and less than 10 is few.
I don't know what was used to build stackoverflow but it must have been very carefully performance tested before.
If you want to build a web site that will get such a heavy load, and if you don't have experience with that, try to get someone in your team that have already worked on such sites (performance testing with a real set of data and a representative number of concurrent users is not an easy and fast task to implement). Having someone that have experience with it will greatly speed up the process.
Its very important to have a maintainabilty that is high. Ive developed large scaled web application with lowlevel super high preformance. The big disadvantage was maintaining the system, that is, developing new features. If you'r to slow developing the customers will look for other systems/applications.. Its a trade of. Most of the orms has features if you need to do optmized queries direct to sql. The orm itself isnt the bottleneck. Ill say its more about a good db design.
I think you missed the picture. Performance is everyday for your users, they care not at all about maintainability. You are being ethnocentric, you are concerned only for your personal concerns and not those of the the people who pay for the system. It isn't all about your convenience.
Perhaps you should sit down with the users and watch them use your system for day or two. Then you should sit down at a PC that is the same power as the ones they use (not a dev machine) and spend an entire week doing nothing but using your system all day long. Then you might understand their point.
Related
I am re-factoring a codeigniter project that uses database extensively (right now that layer uses PDO and generated queries but it became unreadable so needs re-factoring), and trying to figure out what's the best way to go. I am interested in ease of development, but more importantly - performance, but I couldn't find out useful comparisons of performance:
CI's Active record, NotORM and ORMs (currently I am looking at GAS and Datamapper, but open to other suggestions) that can be integrated with CI .
I started looking at DataMapper, but then found a post claiming it is twice as slow as the CI Active Record, and that seems to me like a deal-breaker - I am ok with a bit of overhead for extra flexibility, code reuse and readability, but would rather with a really fast bad code than find out I significantly slowed my pages loading time for that.
I am looking for something like http://www.techempower.com/benchmarks/ , but for ORMs and other DB access layers and not PHP frameworks.
Actually there's no good answer here.
If you need extremely good performance, then use PDO. You write plain SQL queries, so you have 100% control.
If you want to introduce some tool to ease the way you write SQL, maybe you can have a look at any SQL-fluent-api library, that can abstract you "a bit":
select('X')->from('Y')->where('Z')->limit(10);
A bit clearer, maybe :). It'll probably also generate compatible-queries with many RDBMS (MySQL, Oracle, PostgreSQL...).
None of the above alternatives is an ORM. If you need it, of course there's a penalty on performance (and we can say it's always "big"). Good and modern ORMs usually allow you also to cache results, or even the generated SQL to avoid part of the overhead.
Anyway, the performance is degraded, of course. For each query, the ORM has to transform the resultset to your objects (and all the relations), which is (on the other hand) very cool :D. And you lose control over what the ORM is doing internally (sometimes, and if you don't know the ORM).
There's no good answer here, it depends on your use-case.
If you decide to use an ORM, have a look at Doctrine2. You can have a look at how to integrate it with CodeIgniter here: http://doctrine-orm.readthedocs.org/en/latest/cookbook/integrating-with-codeigniter.html
I started learning PHP awhile ago. I guess I'm fairly okay in it. I want to write a Content Management System, just as a project for myself, however long it may take. To be more specific, a simple gaming CMS where users can log in, post clan statistics, post in a forum, have user profiles, upcoming matches etc, various other modules you can install or code yourself. It's been done before, but I feel like I would learn a lot by going through with this.
To the experienced coders:
What is required to undertake such a project?
Any framework preference?
Is OOP necessary?
Are there certain ways to go about making such a large-scale project?
I've heard of various frameworks like CakePHP, codeigniter, and Zend, but I'm not sure what I should make of it.
The most important step in any project is PLANNING.
Plan everything you can , database (tables , columns , relations) , process-flow and such on.
Nothing is necessary but OOP is recommended because:
You won't get lost in your own code
Easy to edit and to add (reflexable for changes)
Cakephp , codeigniter are frameworks and they will save you lot of development time.
Instead of writing classes for each type of models you have (posts , members ...)
you run a simple command and it will create a basic app for your needs.
From my personal experience so far i would suggest you (at least) try making the system on your own since the experience and knowledge gained throughout the process of creating complex systems is by far the best hands on practice you will ever get.
Whether to use a specific framework or not is particularly up to you and whether you feel up to the task of achieving the system development on your own, since using a framework would also require learning the specific framework as well.
For OOP i would highly recommend it since it makes everything a lot easier. If you've never worked with object oriented principles before, you might find it a bit challenging at the beginning, but once you get over the learning curve you'd be more than satisfied with the result, with what you've learned and how easy and organized your whole system will look, especially when you have to make small changes or updates.
Since we are talking about a relatively large system as you suggest, i personally cant stress enough, how important planning and analysis is. Try to write down in details all the data you will need, make drafts and plan your database tables as thorough as you can since if during the process you find out that you've forgotten something or something just doesn't feel right, you might have to recreate classes, databases etc. to make it all run smoothly.
OOP is in the end a matter of preference, but there are a few notable advantages. The very first one that comes to mind is security. Parametized queries with mysqli, which are designed to function in an OOP kind of way, transactions, if you will have any.
If you want CMS, then you will also probably have to display quite a lot of data from the database, which will require pagination. Instead of having to re-write a "procedural" pagination algorithm, you could approach everything with OOP with a single class.
Ultimately, it is still a matter of preference but as far as I know, oop comes with many many advantages in real world applications. Good luck with your project!
I'll just reiterate what's already been said here and say this: OOP is a utility, and never a requirement. I'm an OO person myself and I tend to think easier in those terms after having done it for years, but I don't think I've come up across more than a couple of things that I don't think I could have done without OO practices (one of which being a particle effects engine, which is kind of a given).
That being said, there are definitely times where OO is more a hindrance than an boon. What you need to do is sit down and really visualize your project as a whole. When you're looking at the big picture, do you see things as encapsulated objects? Will you have one block of code that you will be using lots of times over to describe things that are similar but slightly different? Or, is your project a bit more linear where you can see most of your scripts running in the traditional "top-down" format?
Well, the point of OOP is to make programming more similar with the real world. In the real world, you're dealing with objects. Your job is an object of class Job, you are an object of class Employee which extends the class Person, you go home to an object of class Apartment which is contained in an object of class Building, which is contained in an object of class Block.
My point is, the point of OOP is to make life easier for you, you can designate a forum post as an Object, as you can for users and whatnot. The whole structure of data you can create in OOP is far more complex, and easy to understand than procedural PHP.
Eventually, it's all in your preference, but yes, if you asked me whether I'd recommend you use OOP on a project of this scale, I would definitely say yes.
As for your other questions:
What is required to undertake such a project? - Planning, and lots of it. Plan ahead anything you might need (in terms of database, existing projects/classes, files, pages). Also plan in for extensibility, to add modules and tables in the future.
Any framework preference? - I'm not a huge fan of frameworks, but I suggest you do learn the concept of MVC and single point-of-entry.
i think framework will help you a lot.. i mean various repetitive task can be easily omitted
and for a large project OOP is highly recommended for simplicity without OOP your code will be very evil and very hard to maintain
You should first look for some good framework - working from beginning is quite difficult. You should first create some kind of block diagram of necessary parts of your application and corresponding database/tables.
OOP is recommended because it could save you a lot of time.
One good framework look here: http://code.google.com/p/phpstartapp/
Consider the creation of high traffic PHP web-site with many parallel users. Which is the best possible MySQL abstraction (ORM or OODBMS) in terms of effectiveness (15-20 database tables with sum of about 100000 items and JOIN queries between no more than 4 tables)?
Somewhere I heard that Doctrine libraries are appropriate or I should use framework like Zend? Which of these database solutions are build over PDO and don't require much learning (at this time I'm using pure PHP)?
Regardless of the DB solution you should look at using a system like MemCached. With the proper caching strategy you will significantly reduce the load your databases are putting on your server.
There is a PHP API for memcached here
ORM or any data modeling layer will never get you better performance. Their sole purposes is to make your development time faster and easier to maintain. They are notoriously bad at decision making when it comes to actually using relationships appropriately and end up querying all tables in order to find the correct data. At that level of complex queries you are not going to be able to abstract away these relationships without sacrificing performance.
MySQL is fine for up to a couple million records at least (I've used it for over 100 million in a single table). For performance sake you generally want to have at least a master/slave setup and some method of distributing reads between them. The database will almost always be the limiting factor in performance. You can always add in more web servers and get a load balance in front of them to solve the other side of things but the database setup is always a little harder to maintain.
You have to think about why you want to use an ORM. If its for development reasons, that's fine, but be coginiscent that your performance will suffer. Otherwise stick to queries. An ORM adds a third layer of code to deal with and learn. If you know PHP and MySQL, do you need to learn a 3rd language to use them effectively? Most often the answer is no.
You have many options to choose from but be aware that at some point the framework/ORM you choose will not behave the way you want it to and to get it to behave to your desires you will have to do a lot of searching and digging through code. It's the classic problem - save time up front and pay for it later or spend time up front with no possible payoff later.
ORM solutions will be able to optimize some aspects, if you cache query data and use the object API in a planned and deliberate way.
Column / document[nosql : hbase,mongo] databases will improve performance if you have lots (millions+) of records, and are still growing.
Memcached will help if you have a lot of spare memory and especially if there are a lot of repetitious queries being run.
I am in the process of picking a PHP framework for a web application I am starting. I have never really used a framework in the past but with this project there is a great need.
I have been debating between the usual suspects; CakePHP, Zend Framework and Symfony. I have been going back and forth about which framework will work best for me and this project. I am leaning towards CakePHP but I am still researching.
My question is not what framework is best. I know there is no real answer to that and there are tons of posts related to this subject. My question is related to the Model and ORM. I have read a lot about ORMs being slow and I am concerned about speed. I am very comfortable writing SQL and in the past have tried to keep all of my database interactions in stored procedures.
I am looking for some feedback about using CakePHP's ORM or Doctrine with Zend or Symfony as apposed to keeping everything in stored procedures. I know stored procedures are going to be faster but what else will I loose if I do not use an ORM? I understand that an ORM will give me database abstraction but in my mind that just helps people who do not write SQL. I also know that I do not know enough about ORMs.
If anyone can give me some feedback about this and which framework might be best based on using or not using an ORM.
Thanks for any help in advance.
0) Bang for effort
The key advantage with an ORM is that you don't spend as much time dealing with the persistence layer. A pre-written ORM ( I have worked with EclipseLink) will provide a ton of things you probably won't get in custom written stored procs. I think it's worth thinking about how much time you want to spend writing your persistence layer.
1) Caching
All the major ORMs provide multi-level distributed caches. Combined with Named/Predefined queries you can get SQL queries that don't actually have to go to the database. This can give you excellent performance.
2) Abstraction
ORMs allow you to define your table layout in one location and then they manage all the painful mapping between columns/tables and objects. Some will allow you to remap column, table and schema names without changing any code at all. If you work with people who like to change things around this can really simplify things.
3) Speed
Some ORMs can have bad performance, but it really is based on how you use it. I find that you tend to end up over-querying for things. On the other hand, you get things like built-in query profilers. You can write custom SQL for queries if you find you aren't getting the performance you need.
Mark Robinson gives a great response. I'm just going to back up what he says by giving our experience with Doctrine2.
I chose to use Doctrine2 as our ORM with Zend Framework a little while back. Our project is still being developed, but choosing D2 has been a decision we've not regretted one bit. Whilst you still need to give a lot of thought to your data architecture, D2 gives you the flexibility to be able to modify that model at a later date if needs be. It allowed us to try things out quickly in the early stages and the room to grow and change later when we decided that things weren't quite right - it happens.
In relation to Mark's point about abstraction. One of the other things I love about D2 is that we're working with plain old PHP objects. Don't underestimate the power of being able to think in terms of objects - both for the people responsible for modelling the data and the developers who work with the data - it'll make your life easier, trust me. Also, having inline documentation of the ORM mapping (if you choose the docblock approach) is nice.
Right, performance. As Mark says, there are ways and means to speed things up - but there's always going to be some overhead. Whenever you introduce another software layer, there'll be some performance hit, but it's a tradeoff. For us, the tradeoff - the advantages of using the ORM vs performance - is worth it. We'd spend more time debugging code and not getting things done without the ORM.
Anyway, D2 can help you with caching for queries, results and metadata. Whilst you probably just want an array cache during development, it's great that the facility for things like APC, memcache etc. is there when you go to test and deploy. You could even develop your own if you're brave.
http://www.doctrine-project.org/docs/orm/2.0/en/reference/caching.html
Hope that helps, I've probably missed stuff, but if you have any questions just fire them in and I'll do my best.
A framework implements mainly three kinds of features :
the flow between "getting a request" and "rendering a page". That's were you put things like MVC, router, etc...
the way to manage your model and it's persistence. That's where you see acronyms like ORM, DBAL, DAO
Components. Features, often working also standalone. Like Xml parsing, i18n handling, pdf generation...
When you choose your framework, it in facts means that you choose 1). It's the thing you will certainly have to stick with, it's the flow of your application. 2) and 3) ? You can integrate those you prefer. As an example, i'm on Zend Framework with most of it's components, but use Doctrine ORM 2 and Symfony's Dependency injection. A friend of mine is on Symfony 2, uses Doctrine ORM too, but does it's pdf generation and mail management with Zend's related components.
The other thing you need to know if that currently there is a "second generation" of php frameworks/orm's, (re)written to take advantage of the new php 5.3 features, and/or to solve the general performance/coupling issues they (nearly) all had. Some of them are production ready, some are still under development :
Doctrine ORM 2 (production ready)
Symfony 2 (production ready)
CakePhp 2 (in RC 2 currently, but by the time your project is ready it should be stable)
Zend Framework 2 (still under active development, but normally not for so long)
FLOW 3 (beta2, should be ready soon too)
For the ORM part, i'll recommend using one, especially Doctrine's. #Mark and #iainp999 explained perfectly why.
ORMs are for programmers who don't "grock" SQL!
Yes ORMs make it easier (or at least require less lines of code) to write simple CRUD stuff, but when you get to more complex requirements its like trying to write SQL with a piece of wet spaghetti from ten feet away.
So stick with SQL.
Its worth looking at something like "SQLMap" which is ORM starting from the "R"elational side of the mapping (most try to map an "O"bject on to a table). This will allow you to write the SQL yourself and generate the appropriate "helper" classes to easily access the results in your program.
We have got a project to build an ERP system for one of the largest garment industry of Bangladesh.
They have around 20,000 employees and about 10% of them get out/in every month. We are a small company with 5 PHP developers and don't have much experience with such a large project. We have developed different small/medium scale projects previously with Codeigniter/Zend Framework and MySQL database.
For this project we decided to go with Yii framework and MySQL or PostgreSQL. There will be about 1 million database query every day. Now my question is can MySQL/PostgreSQL handle this load or is there a better alternative? Is it ok to do it with Yii framework or there have a better PHP framework for this kind of application? We have got only 5 months to build the payroll and employee management modules.
For one thing, consider using PostgreSQL rather than MySQL. You're going to be dealing with mission-critical data and, in general, you'll appreciate that:
You will have access to window functions (useful for reports), with statements, and a much more robust query planner.
You will have extra data types, namely geometry types which can be used to optimize date-range overlap related queries.
You will have access to full text search functionality without needing to use an engine (MyISAM) which is prone to data corruption.
You will have more options to implement DB replication (some of which are built-in).
With respect to scalability, be wary that scalability != performance. The latter is about making individual requests faster; the former is about being able to handle massive quantities of simultaneous requests, and often comes with a slight hit to the latter.
For the PHP framework, I've never used Yii personally, so I do not know how well it scales. But I'm quite certain that Symfony2 (or Symfony, if you're not into using beta software) will scale nicely: its key devs work in a web-agency whose main customers are mid- to large-sized organizations.
I think, Yii will work fine with (relatively) large amount of data. I'm using Yii to manage 1.3 million records, some thausend updates a day and some thousand querys a day on an small virtual host with an amazing performance.
If your database can handle this data, your Yii application will also handle that.
Your choice of the database will be an important point. So #Denis said some important thinks. By using MySQL probably you have to explore / determined the right storage-engine for your needs.
But, there are some points, which i realized by creating an growing project with Yii. You should think about those things:
-Yii is an young framework: new technologies (like ajax) are supported, but in some special cases it's a bit immature: it's very easy to generate an basic application in a cuple of hours. Problem could be occur by special situation and requirements.
Example: they have an nice validation-mechanism for user inputs(HTML Forms). But until Yii 1.1.6 that doesn't work with HTML Checkboxes, since Yii 1.1.7, Checkboxes are supported by default, but no groups of checkboxes. An other problem: Yii alway uses an table alias, which is always "t". That could be a problem! Sometimes you can define that alias, sometimes not (which is inconsistent). If you like to lock a couple of tables in MySql, you ran into a problem, because Yii calls every table with the same alias "t". So you are unable to loot the tables in MySql by tablename and it's also impossible to lock a couple of tables, which called by the same alias. -> those are specific problems, you can solve them, by writing pure PHP (not using Yii functionality) What I'm trying to say: the framework will not be helpful in very case, but in mostly.
-Yii is easy to extend. It's easy to add own extensions or functionality. So lot's of those "small problems" can be solved be writing own extensions, widgets or by overriding methods.
-Yii supports PHP 5.2. Yii is compatible with 5.3 but (Yii runs on 5.3 - i'm still using it since yesterday, it work's) but doesn't support new features from 5.3 (maybe you need one?)
PHP5.3 will be (maybe) supported with Yii 2.0 - in a distance future (2012)
-Yii has a small (but very good) community.
-there is no professional support (you can post bugs in hope, anybody will fix it - or you will fix it yourself)
-Yii is OO PHP. Think about that by handling with Data-Objects. It's possible to load large amount of data into Data-objects. But keep in mind, that your application server have enough RAM (but that's not a Yii specific thing)
At all: i like Yii an if your application is not to complex, you will have a lot of fun an an nice and powerful application at the end.
I think you might be asking the wrong question, though.
You have five months to build an ERP system. The primary concerns should be:
security. You're dealing with money and personal details.
reliability. Uptime is probably a big deal (at least during working hours)
consistency. You don't want to risk losing data or corrupting data
developer productivity. Five months is not much time do build what you describe
maintainability. Sounds like this is a core enterprise asset, with a lifetime of years - it's likely to require maintenance and extension in the future.
scalability. You need to support tens of thousands of workers, each with many time cards, pay roll runs etc.
performance. You want the application to be responsive.
I would query whether performance is an absolute priority - it shouldn't be slow, but many ERP systems are a bit sluggish. Performance optimizations often mean trading off other priorities - for instance, an ORM system improves developer productivity, but can be slower than hand-crafted SQL.
As for scalability - as long as you have a reasonably designed schema, I don't think 20K employees is much of a challenge to any modern RDBMS on decent hardware.
So, if I were you, I'd probably go with PostgreSQL, for the reasons Denis mentions. Never used Yii, but it seems perfectly reasonable. I would use ORM until you find a situation where the performance really is unacceptable.
Critically, I would put together a testing framework which allows you to monitor performance and scalability during the development cycle (I use JMeter for this), and only make performance optimizations if you really have to. Sacrificing all the other things - especially productivity and maintainability - in the name of performance before you know you have a problem tends to create over-complex solutions, and they in turn tend to have more security issues and maintenance challenges.
Just to add ,
Yii scales very nicely in both directions (ie functionality addition using new modules etc and is one of the fastest php frameworks when it comes to performance ).
The only drawback I can see with Yii is that it has lesser user base so a bit lesser support than some other frameworks, but this is changing fast.
The best part of Yii is the gii based code generation which helps you get started really quickly once you get used to it.
Yii is very flexible, light and easy to learn PHP framework.