Thread

I don’t think the problem is going to be if CodeIgniter can handle the traffic you throw at it, it’s going to be a problem to get that much traffic in the first place. I’ll show you some examples, i have some actual real life numbers from benchmarks as well 😊

Ok firstly, all the testing i’ve done is on my slicehost account. It’s a VPS that cost $20 a month. It has a recent version of Apache + MySQL + PHP installed and eAcccelerator, apart from that it’s stock standard without any modifications. I used this on all my benchmarks.

I setup a hello world example 3 times. First I created a static HTML page, second just echoed in php and thirdly created a CI view and put hello world inside to see what the base performance was. I ended up with this:

HTML: Requests per second: 2550.88
PHP: Requests per second: 1689.09
CodeIgniter: Requests per second: 356.11

As you can see using CodeIgniter is obviously far slower than plain HTML and even almost 5 times slower than base PHP.

I went ahead and benchmarked a few pages on a website I created with CodeIgniter. The slowest page managed 60 requests per second and the fastest around 120. This is a full website with a fair amount of content with 5 - 10 database lookups per page.

So let’s take that lowest number 60, we’ll cut it down a bit because I don’t think you’ll get exactly 60 visitors per second all day, it’ll go up and down, so let’s use 20 for example.

If you had 20 visitors per second * 3600 seconds per hour and 24 hours per day (20 * 3600 *24) = 1 728 000.

If you can build an application that generates 1.7 million visitors per day then I really doubt you’re going to have problems finding the $20 a month to pay for a machine quick enough to run it.

For all the benefits and security, not to mention the reduction in development time, the slowdown over regular PHP isn’t really much to worry about!

(I’m not saying they are bad products, but if you look at the code, most good programmers would start crying or jump of a cliff).

I had to hack up some of the core for a project at work. It made me sad :S

The original question is a bit like saying, “Show me the houses built with hammer X”.  A framework is just a tool, you still need to write good PHP. 

Far too many frameworks out there are behemoths that insist on you doing it “their way”.  Furthermore, the modules that are supposed to save you time end up costing you a lot more with their steep learning curves and having to occasionally hack around to make it do what you want it to do.  For example, I abandoned Cake after three frustrating weeks (far too much “automagic” and poor documentation for my liking) and settled on CI because of its simplicity and ease of installation.

As for what “big” sites you can build with CI, I think you’re only limited by how many big sites you can build with PHP.

having said that, big portals have different needs than small portals , here is example what a specific need could be for a big portal:

http://ellislab.com/forums/viewthread/140506/

in general - your problems do not grow in linear fashion if the traffic grows, but the problems grow exponentially and sometimes unexpected

in addition to that big portals have these key issues:

- interaction with the database queries - ( Codeigniter lacks ORM - compared to CakePHP), big portals have more intense database queries, indexing, simultaneous queries

- cost of developers in the long run ( compared to other languages/frameworks )

- backup systems and logs systems, down-time not allowed

viisik, what are you saying? Everything you’ve listed is not really framework related.

having said that, big portals have different needs than small portals , here is example what a specific need could be for a big portal:

http://ellislab.com/forums/viewthread/140506/

in general - your problems do not grow in linear fashion if the traffic grows, but the problems grow exponentially and sometimes unexpected

As I have mentioned before, scaling is not related to the framework. It is a specific problem related to architecture and hardware.

- interaction with the database queries - ( Codeigniter lacks ORM - compared to CakePHP), big portals have more intense database queries, indexing, simultaneous queries

CI has many community build ORM implementations available, just not in the core (which most of us consider to be a good thing), and you could use a 3rd party ORM, like Doctrine if you would feel the need. You also assume ORM is always a good thing. It has a specific task, and has a place. The overhead generated by a bad ORM implementation can cripple a site. Besides that, I trust my ‘EXPLAIN’ query a lot more when optimizing queries than the default optimization code most ORM’s use.

- cost of developers in the long run ( compared to other languages/frameworks )

I don’t know why this point is made. Again, it’s ‘just’ PHP. Any developer should be able to work with any framework given some time and with a pretty good grasp of PHP. Learning curve might be steep for some frameworks, but it’s not rocket science.

- backup systems and logs systems, down-time not allowed

Again, architecture, again, not framework related.

http://mpora.com/ is the largest I know of. I have no idea what it does per day.

Wow nice to see MPORA popping up - I’m the guy who originally built MPORA and still maintain it. Although it’s changed a lot internally over the years, it’s still very much CI at its core, and I can confirm we’ve spiked up to 100,000 unique users in a few hours. We also regularly appear on the front page of digg.com thanks to our videos, which can cause a massive traffic spike.

However, as has been mentioned a lot of how we cope with large traffic volumes is to do with our server architecture and not CI it’s self. We currently run 2 servers (one web, one SQL) with several memcached (memory caching) instances running to smooth out the spikes. In addition all our static content (images, css etc) is served from a CDN.

That said CI has been great for allowing us to scale in this way - again as others mentioned is VERY forgiving on how things are built and put together allowing us to do things exactly how we needed to do it, and it’s very easy to change things at its core if you need to.

Thanks Bulk

It has been very interesting what you said about the portal.

You mentioned that you have re-built something in time - can you tell what changes have you made to the original architecture and are the changes made as a restult of growing traffic

Did you integrate Memcached later on or it was already there in the beginning

Thanks Bulk

It has been very interesting what you said about the portal.

You mentioned that you have re-built something in time - can you tell what changes have you made to the original architecture and are the changes made as a restult of growing traffic

Did you integrate Memcached later on or it was already there in the beginning

I did make some changes to the core MySQL drivers to allow for seamless memory caching of database queries but to be honest I’m not to happy with how that works so I may take another look at it in time (We’ve only started using memcached in the last year).

To be honest most of the changes have been made for functional reasons - we split out our site over multiple subdomains so we made some changes to allow for that, and I made some changes to the validation library also (we’re using an older version of CI with the old validation library).

At some point this year we are going to start looking at setting up a MySQL cluster, or some sort of read/write slave set up to allow for some real scalability but I don’t know if that’s going to happen in software (i.e. in CI) or in hardware just yet. If we do it in software I will have to change the database driver to allow for reads to one server and write to another (although that could even be done with out core changes as you can set up multiple DB connections very easily).

I also suspect allowing CI to operate over multiple HTTP servers might need some (small!) adjustments to our code (for sessions and whatnot) but we don’t use the CI sessions library to handle our sessions anyway. I don’t think I’ll have to make any changes to the CI core to allow for it.

By far and away the hardest and most complex part of dealing with lots of traffic is managing the servers. I’ve spent a lot of time tuning apache and mysql to work as well as they can on the servers they are on (and they’re on some beefy servers, not sure I can go in to specifics on them though). I’ve had to do basically nothing in CI its self to optimize it, and I haven’t really felt the need.

Hey Bulk

Is it reasonable to include Memcached in every site right in the beginning or it can be implemented easily later on ( not very pro question )

leaving aside the sub-domains that you created - do you use the originial CI code structure or you have changed it - the folders are located the same as they were in the default CI installation

Do you miss ORM or other stuff as database got bigger hits as the portal has grown

The way I implemented memcached was very straight forward - essentially it takes the query and makes an md5 hash from it, then uses the hash as the key for the result of that query stored in memory. Then if the same query is done, it can look up the data in memcached and return that instead of doing the query. The drawback with this method is it doesn’t give much control. For instance there is no way to “expire” a query manually using this method (memcached expires after a time you set automatically) - this causes problems if data changes (say if a user makes an update) - at the moment we just have to wait for the cache to expire on its own.

If I could go back to the start I would have put memcached in from the start - or at least left a way in the code that I could easily add it in later. If you aren’t expecting your code base to be very complicated it’s quite feasible to do it later - it all depends how big (in terms of features) your site will be 😊

The folder/code structure is essentially 100% the same, we still have folders for views, controller & models etc all in the same places they are by default.

To be honest I’ve not missed any type of ORM system at all - we just use a simple mix of the built in active record class for simple queries and just straight queries for the more complex ones (I believe active record has gotten better in later versions, so many of our queries could probably be done as AR now). We didn’t feel it was worth adding another layer of abstraction on top of the already quite powerful database class. Your mileage may vary 😊

To be honest I’ve not missed any type of ORM system at all - we just use a simple mix of the built in active record class for simple queries and just straight queries for the more complex ones. We didn’t feel it was worth adding another layer of abstraction on top of the already quite powerful database class. Your mileage may vary 😊

Couldn’t have said it better.

In my experience, simple queries is where AR shines. Complex queries you probably want to do by hand anyway so an ORM would just get in the way.

would you care to show how your folders code structure looks like - where is memcached stuff, what sub-folders do you have in Public folder ,

where did you put thumbnails of images etc.

The way I implemented memcached was very straight forward - essentially it takes the query and makes an md5 hash from it, then uses the hash as the key for the result of that query stored in memory. Then if the same query is done, it can look up the data in memcached and return that instead of doing the query. The drawback with this method is it doesn’t give much control. For instance there is no way to “expire” a query manually using this method (memcached expires after a time you set automatically) - this causes problems if data changes (say if a user makes an update) - at the moment we just have to wait for the cache to expire on its own.

Hi Bulk,

First of all, thank you very much for your excellent information. I think that CI could use some more marketing/technical coverage like this.

Second, have you thought about holding a “global” table-based expire in the hashing routine where that timestamp could be changed by SQL updates or manually in code?

Third, care to share/contribute any of that code?

I can imagine an adaptation to file based hashing that could be used on shared servers (not that I’d recommend it), during development and/or proof-of-concept stage).

here one guy nicely explain the thing , so - if the sky is the limit for Zend, it cant be said for Codeigniter in real business:

For me personally I choose Code Igniter the majority of the time as it is quicker to develop with because of my knowledge of using it. However for enterprise or larger scale projects I have had to start using Zend. I do work for some quite major clients and there are now a number specifying the use of Zend framework. The main reasons for this are it’s modular nature as mentioned above and the ability to split the database abstraction etc and use other solutions or even simply use elements of the Zend library in a larger solution.
And I think the definition of enterprise etc is when you start dealing with Java driven database ORM and multi levelled server stacks for major blue chip clients.

http://ellislab.com/forums/viewthread/139559/

However for enterprise or larger scale projects I have had to start using Zend.

It’s important to differentiate between the entire Zend component library and Zend MVC components (Zend_Controller and Zend_View). Zend MVC is a complex over-architected mess. Not all Zend components are created equal.