Loading...
 
Architecture / Installation

Architecture / Installation


Can Tiki run a large site?

posts: 1

Hi

This product has amazing functionality for a groupware / collaboration site.

Does anyone know how big a site it can support? How many registered users?

How many simulatenuous sessions?

How can it scale up? (add more memory, servers, etc.)


Can i have 10K registered users? 100k? 1k simult. sessions?

Your help is greatly appreciated.


Val

posts: 2881 United Kingdom


What a lot of Q's!

The bigger the site the better the server needed.

The only limit to the number of registered users is the size of a mysql table. The number of sessions will depend on your server spec and line speed.

Damian

posts: 6 United States

> The only limit to the number of registered users is the size of a mysql table. The number of sessions will depend on your server spec and line speed.

Servers get can only get so big, so it is feasible that certain engine can’t power sites with more users than X. I imagine that there might be other problems, such as the number of required queries growing exponentially and not linearly as the number of users increases.

I don’t think it will be pertinent to the original poster’s site, but some sites require the use of multiple servers. I know definitely that Slashdot and Wikipedia both use multiple (and redundant) web and database servers. Does TikiWiki require the database to rest on the same machine as the web server? Can it access multiple external database servers? Can it have multiple web front ends to the same database server(s)? Those are the real questions about TikiWiki’s scalability.


posts: 8 Sweden

I'm in the process of releasing a large site for one of the largest music festivals in sweden: http://www.arvikafestivalen.se/.
We put it there last friday and we have already run the server down on it's knees. And this with only around 10-20 users at once. eek

You say it is a question of increasing the hardware Damian, but do you have any conrete examples of what kind of traffic one could expet to be handled by a ceirtain "level" of hardware?

We are running the site on this:

Processor
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 2
cpu MHz : 400.920
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr
bogomips : 799.53
Memory
256 MB Ram
Operating system
debian woody
Database
mysql Ver 12.22 Distrib 4.0.18, for pc-linux-gnu (i686)
Web Server
Apache/2.0.49
Server version: Apache/2.0.49
Server built: Apr 10 2004 22:22:57
Server's Module Magic Number: 20020903:7
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT=""
-D SUEXEC_BIN="/usr/lib/apache2/suexec2"
-D DEFAULT_PIDLOG="/var/run/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="/var/run/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
-D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf"

Oh, and I forgot: Latest version of PHP smile

posts: 2881 United Kingdom

Wow, thats a tiny spec machine!

My main Tiki webserver is a dual PIII-1Ghz with 768Mb RAM and dual 120Gb drives.

You can also try and install turckmmcache, I have that installed on all 3 servers and even on that kind of spec I notice a vast improvement.

Memory is very low 256Mb, That should be at least 512Mb+

What kind of drive configuration are you using?


posts: 2881 United Kingdom

Wow, thats a tiny spec machine!

My main Tiki webserver is a dual PIII-1Ghz with 768Mb RAM and dual 120Gb drives.

You can also try and install turckmmcache, I have that installed on all 3 servers and even on that kind of spec I notice a vast improvement.

Memory is very low 256Mb, That should be at least 512Mb+

What kind of drive configuration are you using?


posts: 8 Sweden

It IS tiny, is it not? I kind of raised an eyebrow when the IT guy gave me the specs.

I found the info on the MMCache and sent it to him already, thanx.

About the drive config, I dont know... maby I should haul his ass into this forum... yes, I think I'll do that.

The lag went away again for some reason after a while: I went through the admin interface and tried anything that looked good, like compiling the languages and stuff like that, do you have any quick tips on cashe configuration or precopileing or any such stuff that could help speed up that poor machine?

posts: 2881 United Kingdom

Turck should help a lot.

But seriously if you have to work with that machine, get at least another 512mb in it.

Drive config, is it a slower older IDE or a new faster one? Personally i favour the new IDE drives, cheap enough and just as quick. Disable as many services as possible and let the machine concentrate on serving webpages.

Damian


posts: 2881 United Kingdom

Turck should help a lot.

But seriously if you have to work with that machine, get at least another 512mb in it.

Drive config, is it a slower older IDE or a new faster one? Personally i favour the new IDE drives, cheap enough and just as quick. Disable as many services as possible and let the machine concentrate on serving webpages.

Damian


posts: 8 Sweden

Thanx for the heads-up. I think they thought the new site would demand the same resources as the old one... but as the old site was more or less static, I think we have to re-evaluate that. Especially since we are expecting a good increase in hits.

I'll try to remember to post the results here when we fix this biggrin

/Bjarne


posts: 8 Sweden

The servers are beeing upgraded in a week to some mega dual processor memory monster with an insane disk array, but after some testing I've come to the conclusion that perhaps the modules are the main problem... they all had a chashe setting of 0. After setting that to a better value, like 60 or 120 the responce times of the site are now what they should be on a user friendly site.

One question: the DB access count for a single page generation is 40-80 accesses. 40 for a super basic static HTML page. That count is the total to generate the page in the cashe, right... not every time the page is accessed?

posts: 10 United Kingdom

> One question: the DB access count for a single page generation is 40-80 accesses. 40 for a super basic static HTML page. That count is the total to generate the page in the cashe, right... not every time the page is accessed?

Every page afaik

There is a lot of information needed from the database to render the page, like permissions, statistics, etc. Some of these forum pages take upto 800 queries if you have tiki_p_admin or admin_forum permissions!

Tiki needs a lot of work in optimisation for the database queries. Something thats planned for a rewrite sometime i believe, Damian will be able to tell you more later

Berry


posts: 10 United Kingdom

> One question: the DB access count for a single page generation is 40-80 accesses. 40 for a super basic static HTML page. That count is the total to generate the page in the cashe, right... not every time the page is accessed?

Every page afaik

There is a lot of information needed from the database to render the page, like permissions, statistics, etc. Some of these forum pages take upto 800 queries if you have tiki_p_admin or admin_forum permissions!

Tiki needs a lot of work in optimisation for the database queries. Something thats planned for a rewrite sometime i believe, Damian will be able to tell you more later

Berry


posts: 8 Sweden

By looking at the web server history around earlier years festivals, we have an expected ( historical ) maximum server load: 19 hits per second average over an hour.
That would result in around 100 * 19 = 1900 database queries per second.
Current tests on a rather standard install of TikiWiki ( No MMCashe ) shows that it handles around 3 hits per second with an average responce time of 7 seconds. The main work that is done on the server is done in the PHP processes, so installing MMCashe would definetly help.
The test server is a:
Intel 4 2,4 GHz
1Gb memory
SATA 120Gb disk

At this load the MYSQL is not a problem, but I guess it would act up att max load...

Any server running around that load that you guys know of in production?question

One thing I just realized... the 19 hits per second top load includes image (and other stuff) requests, so maby 10-15 when the shit hits the fan. And with a 400% PHP efficiency increase when using MM Cashe, 12 users per second is in reach. Hope is awakened. question


posts: 6 United States

> The only limit to the number of registered users is the size of a mysql table. The number of sessions will depend on your server spec and line speed.

Servers get can only get so big, so it is feasible that certain engine can’t power sites with more users than X. I imagine that there might be other problems, such as the number of required queries growing exponentially and not linearly as the number of users increases.

I don’t think it will be pertinent to the original poster’s site, but some sites require the use of multiple servers. I know definitely that Slashdot and Wikipedia both use multiple (and redundant) web and database servers. Does TikiWiki require the database to rest on the same machine as the web server? Can it access multiple external database servers? Can it have multiple web front ends to the same database server(s)? Those are the real questions about TikiWiki’s scalability.


posts: 8 Sweden

OK, now the site is back on an improved server:
Dual processor
1GB mem
Blazing HD's
Separate DB server
MMCashe running

And it's running along at nice speeds despite hard pressure.

Check it out and become part of the load mrgreen at:
http://www.arvikafestivalen.se/
(Its a Swedish music festival, so the language may be a bit too hard for some of you wink)


Upcoming Events

1)  18 Apr 2024 14:00 GMT-0000
Tiki Roundtable Meeting
2)  16 May 2024 14:00 GMT-0000
Tiki Roundtable Meeting
3)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
4)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
5)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7) 
Tiki birthday
8)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9)  21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting
10)  19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting