The maximun number of users doesn't depend of Qcubed. It depends on your server(s) and database(s).
QCodo (in which QCubed is based) is used in sites with lots of concurrent users. One example is http://chess.com.

Cheers,

---
Marcos
http://thinkclear.com.ar

Thankz very much Marcosdsanchez.
But I really want to know how robust Qcubed can be. I'm using Qcubed in some projects in my office and boss really wants to know how reliable the projects will turn out. Please I'd appreciate any help on this. Thankz very much.

chess.com has millions of hits a day.

All of these companies are using QCubed for their day-to-day businesses - i.e. their survival depends on stability of the platform.

If you're looking for some other measurement of reliability, let us know, we'll try to dig it up for you.

when i first descover qcodo & qcube i started to re-write one of my ols sites for edu reason.
i discover 2 issues.
1.that it took me to write it half of the time (very very good) and
2. that takes a lot more memory with qcodo to execute each script.
i change memory_limit to 10MB in php.ini
and the new version of site doesn't work
but the old one works fine.

Isn't it a problem?
this site is in production mode this time with over 100.000 users a day,
if i upload the new version with qcube i don't think that it will work.

the whole memory / performance thing is really a problem.

There is much that can be done to improve QCubed in terms of that, but it would probably require quite a major rework of parts of the framework.

Folks - memory consumption for QCubed is indeed a problem, but in order to fix it, we need to know exactly what scenarios are failing for folks. If any of you are willing to share your scenario - or, even better, your code (privately) - you can really make QCubed better. Alternatively, if you want to run a profiler on your app, and give us the results, we'd very much appreciate it, too.

Hey guys. This is a current concern of mine as I am finishing up a large QCodo 0.3.43 based project and at the moment performance is not good enough.

I will post details of my findings as I go, but here's one tidbit for now...

There is a ticket currently in the QCubed trac with regards to QType performance. The basic word is this:

QType performance is horrible. On a page with two datagrids each displaying 10 items and featuring a smallish number of additional calls the QType cast functions get called about 1900 times and consumed roughly 10% of the total execution time within the script.

I rewrotie QType for my application and was able to reduce it's overall performance impact to about 5%.

Of additional interest, see this ticket. The patch introduced here is worrisome. Performing preg_matches in a method which is going to be called over a thousand times on some pages is not a good idea.

With regards to memory usage, QCodo/QCubed is a memory hog. My initial suspicion is this has a great deal to do with the serialization and deserialization of data peformed by QCodo.
Further investigation will be posted...

I too agree that QType performance is "not good enough", but I can't disagree more that this is the right place for us to address.

OOPMan, you mentioned that QType calls account for only 10% of the execution time of the page - and by doing the rewrite, you were able to take it down to 5%. That's like a 3% overall improvement in your page performance. That's totally negligible.

The rule of performance optimizations is "find the stuff that REALLY affects your app - things that slow things down by a factor of 2x or 3x". Nitpicking misc issues that have 2-5% impact is just a waste of time. No matter how many times the function is called.

That said, if the work is already done, we'd love to see the results so we can apply them to core. :) Any improvement is definitely welcome, alex's point is that your effort could probably be even more productively used optimizing other areas.

I would love to post my QCast but the QCubed Trac system does not seem to like me. Even though I have an account here when I try to login to the Trac system it presents me with the login dialog, accepts my input and then reloads as though nothing has happened.

Alex, I may be nitpicking but in some cases it does have an effect. Furthermore, the think that if QType gets a bunch of preg calls thrown in a real performance decrease will become very visible.

Some more general stuff...

QCodo/QCubed makes excessive use of the array_key_exists function when the isset function does pretty much the same job but is about 2 or 3 times faster and with substantially less memory usage (The latter I discovered when running through the xdebug trace logs for my system and discovering that hits to array_key_exists were, in some cases, allocating on the order of 70kb memory per execution)

Yes, I know. There is a difference between the two. Isset considers an array key with a value of NULL to be not set. However, having done a somewhat painful regex-based find and replace of pretty EVERY array_key_exists with the equivalent isset expression I can confirm that QCodo seems to putter on just fine.

I think that this change would do well to be flowed through to QCubed. Also, I think that a guideline should be put in place to prefer isset over array_key_exists unless the latter is truly necessary...

OOPMan,

I think what you are doing is great. While it is definitely important to find those big memory users, these little things can really add up.

Sure, alone, they don't mean much, but if you find four different "small" things that take up 5% a piece, that is a good chunk of usage.

So, if someone is willing to look at and fix these things, more power to them. :)

OOPMan-

I have been watching some of the things you have been bringing up, and I want to let you know that they are not going unnoticed. As Rob said, all of these things add up.

That said, I think the best way you could help the project right now is to track all of these little performance increases that you're finding somewhere. Even if it's a spreadsheet you just keep on your local computer, we need to put it somewhere. If you need any assistance, please feel free to contact me directly, or talk with other core contribs through the IRC channel.

I *really* don't want to lose the work you've done, but as you know, our focus is on the 1.0 release currently. Once we get that out the door, we'll be able to look at these tiny performance increases.

array_key_exists is used instead of isset because of the exact reason you pointed out.

I do agree we need to find performance increases but wasting time on small performance increases is a waste of time. You can sit down forever to try and increase speed and performance.

What we need to do is find fixes that will improve things drastically and not try to fret over what function performs an operation 0.000021s faster than the other one.

It is alright if you don't want to do it.

If he does, where is the problem? Not everyone is going to work on drastic issues. That is one of the points of open source; people can tackle problems they see or notice.

Like I said, if something is found that is 2 ms faster and that thing is run 1000 times, well, that can add up.

It only becomes a problem if the big issues are being ignored because of the small ones. As far as I knew, bugs are being actively worked on.

I would rather encourage whatever help is being offered instead of casting it aside.

Yes, sorry, excuse me.

If I came off like I didn't want people helping with performance then shoot me in the foot. My experience would be to tackle the bigger problems that's all I was getting at.

I know it may seem like I'm attacking some minor things but really all I'm doing is hitting the heaviest pages on my site with XDebugs profiling and tracing tools enabled and examining the results.

I plug the profile into kcachegrind and take a look at what methods and functions are being called the most and seeing what I can do to improve them. Of particular importance to me are methods and functions that have consume a high absolute execution time and spend most of said execution time within themselves. In other words, hog functions.

I know I can't fix them all. Some of them are just not fixable and some aren't worth the effort.

Others, however, are easier to deal with and fixing them does show some improvment.

These are not the only things I'm doing to optimise my application though. I have already pluged in in XCache and have set up a tool to easily make use of its variable caching facility within my code.

Be assured, I'm not approaching this in a: "My app is slow, it *must* be the framework!" kind of way...

Basilieus, with regards to array_key_exists: As I said, I've already wholesale replaced it in my application with isset and everything is working fine. The whole fact that the functionality of isset and array_key_exists differs in PHP seems to me to be a fault in the language itself. Why exactly are NULL values permissiable in arrays but not in normal variables? Seems inconsistent to me...

Yeah I don't understand it either, but anyway thanks for all your help on the project, I'm sure isset would suffice if you aren't having any problems, after all I haven't tested it.

Jon

OOPMan, if you haven't already, please create a ticket with the suggested improvements. That way we can evaluate it from a compatibility standpoint, and commit it for v1.1.0 :)

As I've said before, I am unable to use the Trac system that QCU is using. When I attemp to login (Opera and Firefox tested) it accepts my login details and reloads the page but does not consider me logged in. Hence, I am unable to use you Trac system.

I tried to look into your trac account to see why that may be, but my access seems to have been reduced. Can someone else track down the problem?

I actually see the same issue - after I log in, Trac doesn't consider me logged in - I have to manually refresh the page through F5. It seems like caching is somehow wrong.

Another symptom: after I change a wiki page on Trac, it also doesn't get updated. I have to manually refresh it.

I still have no luck. Refreshing doesn't help. Could someone look into this. I would like to contribute but not being able to do anything with tickets makes this really hard...

Sorry OOPMan, we've checked it out pretty thoroughly on our end, and everything looks right in the settings for your account. Can you try it on another computer / browser?

Well, I could try it from a VM. Other people in my office have reported the issue though. It might be a proxy issues somewhere.

Hey all, just thought I'd let you know I've finally managed to log in to the trac system. Seems a transparent proxy was causing issues for me.

Anyway, my first addition is here:

http://trac.qcu.be/projects/qcubed/ticket/76#comment:3

When I read this I felt there is now really great involvement with QCUBED coming up and very knowledged people are working on different aspects.

I just wanted to say thank you for analysing and sharing these informations this will help to make the project better. After working on problems regarding performance the last week I realized this is deep stuff.

It is great that everyone in the community is interested in different aspects.

Thanks again and god bless you.