1
ewonline
Feature Requests : My 2 Cents
  • 2004/11/17 1:02

  • ewonline

  • Not too shy to talk

  • Posts: 198

  • Since: 2004/11/17


I run a site with XOOPS and XOOPS seems to run pretty slowly
I do understand that with all its features it cant be that fast, but anything to speed it up would be great.

Also, for PMs. How about pop-up on new pm?

Maybe increased caching to speed things up?

Mainly, I think that XOOPS needs a little speed boost from all the features that it has.

2
ewonline
Re: Feature Requests : My 2 Cents
  • 2004/11/17 1:03

  • ewonline

  • Not too shy to talk

  • Posts: 198

  • Since: 2004/11/17


oh, one question
is this forum using newbb 2.0?

3
brash
Re: Feature Requests : My 2 Cents
  • 2004/11/17 1:35

  • brash

  • Friend of XOOPS

  • Posts: 2206

  • Since: 2003/4/10


Yep, XOOPS performance is a common sticking point. However, as I see it XOOPS is a perfectly capable racecar, but it will only ever go as fast as the driver/team are capable of letting it go.

Almost regardless of CMS, there are basic technical fundamentals that are just about always overlooked and/or discarded. Nothing fancy, but simple things such as;

- Caching (as you've mentioned). XOOPS uses a very capable caching system called smarty, and you are able to set the caching level on blocks and modules independtley. There is no one size fits all settings, but the performance gain from tweaking your cache times can result in enormous performance gains.

- HTTP requests. Keep the number of HTTP requests on your front page to a minimum. Every HTTP request can quite easily result in a .5 of second server connect time for visitors on slower connections, so it's easy to see how a great stack of thse is going to render your site unusable.

- Site weight. Graphics no doubt add to the visual appeal of a site, but unless used wisely, they will also kill your site for lower bandwidth users. Again, use of graphics on the front page of your site should be always keep to a minimum.


I just had a look at your site ewonline, and HTTP and weight wise it isn't too bad. Site totalled 40 HTTP requests, and came in at around 175KB (loading time was 18.2 seconds which will vary depending on connection). Still, there is some room for improvement though if you were to have a closer look. If you haven't configured your block and module caching then I HIGHLY recommend you do that as well (probably more so than anything else).


Oh yeah, this site is using Newbb 2.0 .

4
ewonline
Re: Feature Requests : My 2 Cents
  • 2004/11/17 5:01

  • ewonline

  • Not too shy to talk

  • Posts: 198

  • Since: 2004/11/17


I have definitely enabled caching in whatever blocks and modules i can.

Trust me, its caching as much as it can or possible.
I plan on starting another site, and I'm very hesitant to use XOOPS again due to the speed

I added a page gen time in the source code of the site at the bottom of the source code.

I've seen that go up to 4 secs and as low as 0.5secs.

I would prefer that is stay below 0.5, but that just doesnt happen. The server runs Zend Optimizer. Another key problem I say is that XOOPS is too much DB based. My DB is about 3MB.

Here is my cache settings for modules:
Resized Image

I'm not that concerned about images, I have enough bandwidth plus modern browsers cache images, so thats fine.
I'm more worried about the page generation time.

5
brash
Re: Feature Requests : My 2 Cents
  • 2004/11/17 21:58

  • brash

  • Friend of XOOPS

  • Posts: 2206

  • Since: 2003/4/10


Hi ewonline,

If you have tweaked all your cache settings to the max, and are still getting execution times of upto 4 seconds, then I'd be looking at your host. Unless you are getting 10's of thousands of page views a day, then with the amount of content you have on your front page you should be getting execution times of under 1 seconds most of the time even if you don't use caching at all. I host my own site and on my server (AMD XP2600+ with 1.5GB of RAM) which hosts all kinds of different services I get a page execution time of about 0.08 seconds with just 13 database queries when coming out of cache, and even without cache the execution time is only around the 0.15 second mark.

I would suggest using the MySQL debug block (if you haven't already) and it will display a popup window showing the caching information of all the blocks as well as SQL queries and query count. There is a hack getting around you might be interested in that changes the caching system so that the cache is ONLY refreshed/updated when content has actually changed, instead of just having a time based caching system as it is by standard. I think this hack is worth it's weight in gold. I have also just released a page counter & MySQL query counter that you can put at the bottom of each page (much like your ) which will display a page execution time (to 3 decimal places) and MySQL query count generated to render each page.


-EDIT-

BTW, have you enabled both module & BLOCK caching? I just ask this as you only mentioned you module caching (image is not working btw), but block and module caching are totally seperate. You will probably see the greatest performance advantage come from block caching rather than module caching as your site (as with most) is dominated by blocks, which are also usually more DB query intensive.

Another thing is that if you are concerned about performance, you should still be trying to minimise the use of images. You are correct in saying that once a user has visited your site that they will be cached, but regardless of cache or not each image will stll produce a HTTP request. And as I said earlier, for users with slow and/or laggy connections between them and your site, these HTTP requests can quite easily take .5 of a second each to process.

6
ewonline
Re: Feature Requests : My 2 Cents
  • 2004/11/18 0:20

  • ewonline

  • Not too shy to talk

  • Posts: 198

  • Since: 2004/11/17


The blocks are cached too. As much as possible.

Another suggestions, auto login aka Remeber Me. That is a really useful thing that should be standard.

Thanks for your help

7
ewonline
Re: Feature Requests : My 2 Cents
  • 2004/11/18 0:21

  • ewonline

  • Not too shy to talk

  • Posts: 198

  • Since: 2004/11/17


Server Info

This is one generated a week ago.
Server Info
And yes, it is a shared server.

8
brash
Re: Feature Requests : My 2 Cents
  • 2004/11/18 0:52

  • brash

  • Friend of XOOPS

  • Posts: 2206

  • Since: 2003/4/10


I agree, GIJOE's auto login hack is king ! I do beleive it will be included as of XOOPS 2.2.

Looking at those server stats, it all looks pretty good. Load averages and CPU utilation seem very comfortable, and although there is only 1GB of RAM, there is plenty free.

Still, a quad Xeon 2.4Ghz should be absolutely eating script processing tasks for breakfast, so I can't help but think that the snapshot you linked to was at low utilzation, or that there is some other bottle neck at play. Personally I think putting IDE drives in a server like this is like putting skateboard wheels on a Ferrari. I'd be very interested to see some I/O performance stats.

9
ewonline
Re: Feature Requests : My 2 Cents
  • 2004/11/18 4:27

  • ewonline

  • Not too shy to talk

  • Posts: 198

  • Since: 2004/11/17


Well, if you want to know, I've seen the server load at 4 and lowest at 0.2, but it really still doesnt make much of a difference in terms of page gen time.

The first visit is slower, but after Zend kicks in, the gen time stays around 0.6/0.5 secs.

I would greatful if auto-login aka remember me was implemented. I even get tired of logining into xoops.org. lol
Does auto login work with 2.0.7.3

From what i've heard, Smarty isnt exactly the fastest templating engine?

I know this wouldnt exactly be the best question to be asked here, but what is fast CMS?

10
brash
Re: Feature Requests : My 2 Cents
  • 2004/11/18 7:06

  • brash

  • Friend of XOOPS

  • Posts: 2206

  • Since: 2003/4/10


Yep, I think just about everyone has gotten sick at the lack of an auto login here at some stage. What's even worse is when you go to submit a monster post, only to find you aren't logged on anymore. Now that makes you mad !

Load averages are not the be all and end all. They are just a representative number of system load over the past 5, 10 and 15 minutes. What I was getting at is that even if this server was hosting 100 sites with 10,000 page views a day, 4 x 2.4Ghz Xeons should be able to chew it up and spit it out if they are able to operate at their maximum potential.

However a couple of desktop grade, 7200RPM ATA-100 hard drives with only 2MB of cache and a pretty average 9ms read seek time are NOT suited for ballsy database applications. If I were to use an IDE drive in such a server, then at the very minimum I'd be using a 10,000RPM SATA model with 8MB of cache as they have half the average read seek time, and in general are geared far more geared towards performance. Even better would be some kind of hardware RAID.

Smarty isn't the fastest templating system, but again I bring you back to the point that with the kind of delays you are experiencing, I can GARANTEE you it is not XOOPS that is dragging its feet. http://ams.it-hq.org is another site on my server, and it contains more content than your site and it can render the entire main page without any caching (90 odd queries) in around 0.3 of a second or less every time. That mean my AMS site which has more content than yours could be rendered from scratch more than 13 times over in the time it takes for your site to render once from scratch. And this is coming from a server with a fraction of the processing power compared to the server hosting your site. I know it's frustrating trying to chase down these performance issues, but I can tell you that it is not XOOPS that is causing your grief. I would be contacting your host.

P.S Have you tried the cache hack so that content is only updated when something changes? Do this and you should only have a handful of MySQL queries to process on each page load, and script execution times should be almost non existant.

Login

Who's Online

322 user(s) are online (222 user(s) are browsing Support Forums)


Members: 0


Guests: 322


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Nov 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits