Show me big portals built with Codeigniter

[eluser]viisik[/eluser]
Thank you nOxie - thats a good answer - Zend has more advanced library , for Webservices etc. that big portals usually need , and Zend is thus more complicated to learn

If you say that in general Codeigniter can do the same things that Zend can - then why big portals are not built with Codeigniters ?

could it be that big portals are being developed by experienced professionals usually - who usually know Zend well and - why to use Codeigniter for big portals when you are experienced with Zend ..

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

But it's kind of a dumb question. Download it, run your own tests, and figure it out for yourself.

[eluser]viisik[/eluser]
At least one big Codeigniter site named after the long conversation ) hopefully there are some more of similar size Codeigniter portals in the world

This www.mpora.com site has about 56 000 visitors per day according to some stat counters , so looks promising

[eluser]n0xie[/eluser]
[quote author="viisik" date="1262732701"]
could it be that big portals are being developed by experienced professionals usually - who usually know Zend well and - why to use Codeigniter for big portals when you are experienced with Zend ..[/quote]
Well define experienced. I have 10 years of PHP experience. Does that make me experienced? I know a lot of students who just finished college and their heads are filled with Design Patterns and OOP paradigms. Are they experienced? Is the guy who has been programming for 20+ years in Fortran, Cobol and C and decides to learn this 'new thing' called PHP experienced?

Programming is, to me at least, an art form. While you have many mediocre artists, there are only few who truly are amazing. Obviously there are a lot of artists who no one understands, or rather, no one likes and there is a large group who are plainly rubbish. But all of them have experience.

So what does this tell you? Like I stated earlier, it's all 'just' PHP. Put it in the hands of a truly amazing programmer, and it powers sites like Youtube, Digg and more than half the alexa top 100 sites. Put it in the hands of mediocre programmers, you'll get the standard corporate website. Put it in the hands of hobbyist, you end up with Wordpress, Joomla and all the other behemoths OS engines. (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).

Obviously you care more about the differences between CI and Zend. I would reckon that most programmers who want to use many of the Zend components, are inclined to just use the whole package, instead of adapting components to CI. This would make sense, especially if they have a lot of experience with the Zend framework and are comfortable/familiar with the conventions/configurations of Zend.

[eluser]CI2RULZ[/eluser]
a note about above... to me... use CI because it's the fastest of all the frameworks (not opinion), and if you need one or two classes to do something, just add the class to your library for that project. And hell, you don't have to use a framework at all. .NET comes out and the PHP community freaks and every tom dick and harry made a framework... for what? At the end of the day, if it's not making it easier and speeding development (and believe me... ZF will NOT make your life easier), then what's the point? CI is fast and speeds development. <-period

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

[quote author="n0xie" date="1262794143"]
(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).
[/quote]

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

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

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

[eluser]Rick Jolly[/eluser]
viisik, what are you saying? Everything you've listed is not really framework related.

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