3.0 slow

[backdream]

0.4219 isn't slow. You can even say "fast" for a really big framework like the one IPB has.

But in 2.3.9, IPB always show 0.04 seconds.

[backdream]

Even if IPB loaded in 0.0001 seconds - would you really notice the difference between that and 0.5 seconds?

NO, you are wrong.

When IPB can loaded in 0.0001 seconds, The server can support 10000 members online at once, BUt 0.5, it can only support 100 members online at once.

[Brandon D]

Nice. How'd you work those numbers out exactly? :P The time it reports isn't indicative on how many people the server can "support".

You also have to realize that the time it's reporting is just the time it takes the backend to do it's thing. Majority of the time is taken up by your browser rendering the page.

[ryuux!]

Testing it out.

[backdream]

Nice. How'd you work those numbers out exactly?

The time it reports isn't indicative on how many people the server can "support".

You also have to realize that the time it's reporting is just the time it takes the backend to do it's thing. Majority of the time is taken up by your browser rendering the page.

Now 16 queries, 1.1214 sec.

You say the time it reports isn't indicative , But what can indicative ?

More little queries means more little load with Database server, Also More little time the IPB running means more little load with Application server .

[Mark]

It's funny, I was just reading this feature request before this thread.
You can see in that thread a feature suggestion is made, one of our developers replies saying that it would cause a significant performance hit, and the reply from the customer is that the addition of the feature would be worth the extra load.

Feature suggestions seem to follow this pattern, and so not just for IPB, for any software, as time goes on and more features get added: the computer (or server) required to run that software also has to be improved.
For example, would you expect to run Windows 7 on a computer you bought 10 years ago? Of course not.
Yet we seem to be expected to both add new features and maintain equal loading time to the previous version? Please someone tell me how we can do that.

That being said, in IPB 3 loads of features have been added - and loads of optimisations have been made - you might say it "feels slow" but this is at the moment the only large live IPB 3 site on the internet, and the average users online is around 300 - this is a busy a site.
Now, looking at load times on my test server - IPB 3 was 0.05 seconds and IPB 2 was 0.07.
On a live site the difference is going to vary, but as I said before, this is the only large IPB 3 site out there, and as such only we have the actual numbers behind the difference between IPB 2 and IPB 3 when in production.

I'm not saying we're ignoring speed, of course not: a large part of IPS is hosting, and almost every site we host has an IPB installation: do you really think we'd overlook performance?
Optimisations can be made, and will continue to be made, all we ask is that you first of all, accept that IPB 3 is probably in most cases going to be fractionally slower than IPB 2 - it is newer software and as is the nature of software - and secondly, don't be too hasty on your decisions until you've seen IPB 3 in action - on this site we have every new feature turned on and are still testing a few things - each person is going to use the product sightly differently and if performance is a huge issue for you, you're probably going to be turning off some of those features which we have on.
Of course, if when IPB 3 does release you have issues like the OP is having which are of course unacceptable, we will look into that via a support ticket :)

[chasz]

if you are gonna make the database server work of course you are gonna limit the number of users to the site LOL

there are only 14-16 queries so why is there a delay in loading?? i am thinking if you cache the templates to database and run templates off the database, you wont serve many people LOL

why not cache it out to files and then have a function to recache to files periodically?

[bfarber]

I'm not saying we're ignoring speed, of course not: a large part of IPS is hosting, and almost every site we host has an IPB installation: do you really think we'd overlook performance?

I think a lot of people are forgetting this. Our hosting department does not like it when they have to reduce the number of sites on a server, or work overtime maintaining servers, because IPB is causing problems. The better IPB performs, the more sites you can fit on a server without overloading it. That translates directly into dollars, and is naturally a motivating reason for us to ensure IPB performs as best as possible, setting everything else aside.

We never forget performance. :)

if you are gonna make the database server work of course you are gonna limit the number of users to the site LOL

there are only 14-16 queries so why is there a delay in loading?? i am thinking if you cache the templates to database and run templates off the database, you wont serve many people LOL

why not cache it out to files and then have a function to recache to files periodically?

We have cached skins to files since like....version 1.0 I think? IPB3 continues to cache skins to files. They're only recached when you edit the skins.

However, in some tests we've shown that loading the skins from the database and evaling them at runtime can be faster than loading the cached skin file, mainly because it's fast to run a database query to a dedicated db server, while disk access is relatively slow. When you're loading up 30 different files on one page load, it can be faster to offload 2 or 3 of them to database queries. It's all relative, however.

People should really really not look at raw query counts. What's going to be faster here?

select max(id) from forums; select min(id) from forums;

select count(*) from forums;

or

select f.*, t.*, count(*), max(f.id), min(f.id) from forums f left join topics t on t.tid=f.last_topic_id order by f.id ASC group by t.forum_id limit 8

(Above query may not actually be formatted right/correct columns but you get what I'm saying).

Raw query count means little if the queries are properly optimized. Query speed is not presently an issue.

[rbiss]

Hello, just want to let everyone know that this was not 3.0 but my own computer problem. I wouldn't want potential customers to think there is a problem when there isn't one. Sorry about that.