Show me big portals built with Codeigniter

[eluser]Bulk[/eluser]
[quote author="Colin Williams" date="1262753451"]http://mpora.com/ is the largest I know of. I have no idea what it does per day.[/quote]

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.

[eluser]viisik[/eluser]
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

[eluser]Bulk[/eluser]
[quote author="viisik" date="1262880652"]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[/quote]

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.

[eluser]viisik[/eluser]
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

[eluser]Bulk[/eluser]
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

[eluser]n0xie[/eluser]
[quote author="Bulk" date="1262884345"]
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 [/quote]
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.

[eluser]viisik[/eluser]
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.

[eluser]Overlord[/eluser]
[quote author="Bulk" date="1262884345"]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.
[/quote]

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).

[eluser]viisik[/eluser]
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/

[eluser]Rick Jolly[/eluser]
[quote author="viisik" date="1263261109"]However for enterprise or larger scale projects I have had to start using Zend.[/quote]
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.