vb.org Archive

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   Big Board Discussions (https://vborg.vbsupport.ru/forumdisplay.php?f=172)
-   -   Distributive Computing for hosting? (https://vborg.vbsupport.ru/showthread.php?t=110005)

RMS-Chef 03-11-2006 04:35 AM

Quote:

Originally Posted by Paul M
I find it curious that you seem to suffer with only 1200 or so users online - we have a dedicated server that only has 2GB RAM and a single HT Xeon. We had a burst during the week that saw over 1000 users/guests online and it barely flickered.

wow. Do you display logged in users on FORUMHOME and use full DB read marking with those kind of users without issues? Are the people posting or just browsing? This forum averages around 2,000-3,500 post per day.

Maybe it's because we are running CPanel? I have been told that we would be better off without CPanel and running lighter apache/SQL applications only and cutting out Cpanel and all the added crap that comes with it. It's just that I don't know enough about the server backend stuff to be without it.

The one forum is the only thing on the server and we recently had to up the RAM to 4GB from 2GB because with the two, things were ugly at around 1000 users. I was told by vB support that when you start hitting 1000 users you really need a two server setup so doing OK with 1400-1500 on the one machine I thought we were doing OK.

And as I said before, the reason that we don't just opt for a two server setup right now is that it's only needed for two days a week. It just seems silly to me to have my client paying the extra monthly cost when 75% of the time they don't even need what they have now. It has become a tough balancing act.

Paul M 03-11-2006 05:20 AM

Quote:

Originally Posted by RMS-Chef
wow. Do you display logged in users on FORUMHOME and use full DB read marking with those kind of users without issues? Are the people posting or just browsing? This forum averages around 2,000-3,500 post per day.

Yes to both the first two. The users are posting, but not at the rate you have, about 650-800 per day.

Quote:

Originally Posted by RMS-Chef
Maybe it's because we are running CPanel? I have been told that we would be better off without CPanel and running lighter apache/SQL applications only and cutting out Cpanel and all the added crap that comes with it. It's just that I don't know enough about the server backend stuff to be without it.

Well we have Plesk, not Cpanel, but I think your OS and apache versions will have more influence. Apparently the linux 2.6 Kernel/Apache 2.0 combination (such as we have) can handle much more than linux 2.4 or Apache 1.3. FYI, we run mysql 4.15 and php 4.4.2.

Trigunflame 03-11-2006 05:37 AM

Most server issues come by way of improper configuration, scaling servers is not always the best solution. You can just keep throwing hardware at something but your cost are going to keep skyrocketing, if possible it is always best to maximize the resourcefulness of what you have.

I have managed servers that average upwards of 2500 during idle times and 4000+ when busy with just using 1 dual xeon 3ghz/ht 4gb memory server using a custom compiled mysql (changes to mysql source)and lighttpd/fast-cgi / php 4.4.x/eaccelerator with offloading image/video to a seperate media server (we are talking somewhat huge files that would normally bog down traffic for page browsing); and the loads would generally stay around < 2.5.

When running database intensive applications such as vbulletin that is where most of your load is going to originate; if you setup your mysql configuration properly atuned to your server MOST people are just wasting money by running multiple servers.

Ps. If you have a large site with many Request/s, do NOT use apache as it is potentially the largest cause of swapping you can have even with a good setup due to the pre-fork model that 95% of people use.

Step into the new world, move to non-blocking IO servers such as lighttpd that use kqueue/epoll etc.. that have loads of advantages.
1. Tons less memory usage, these servers are built to run with small memory footprints yet handle more concurrent connections/request then apache could ever dream of.
2. They natively implement the fast-cgi model which is a Must for a heavy traffic site. mod_php is fine for small servers, but when you get into heavy traffic fast-cgi is the only Proven Stable platform for handling such loads.

Thats all from me on this issue ;)

RMS-Chef 03-11-2006 05:46 AM

Quote:

Originally Posted by Trigunflame
Most server issues come by way of improper configuration, scaling servers is not always the best solution. You can just keep throwing hardware at something but your cost are going to keep skyrocketing, if possible it is always best to maximize the resourcefulness of what you have.

I have managed servers that average upwards of 2500 during idle times and 4000+ when busy with just using 1 dual xeon 3ghz/ht 4gb memory server using a custom compiled mysql (changes to mysql source)and lighttpd/fast-cgi / php 4.4.x/eaccelerator with offloading image/video to a seperate media server (we are talking somewhat huge files that would normally bog down traffic for page browsing); and the loads would generally stay around < 2.5.

When running database intensive applications such as vbulletin that is where most of your load is going to originate; if you setup your mysql configuration properly atuned to your server MOST people are just wasting money by running multiple servers.

Ps. If you have a large site with many Request/s, do NOT use apache as it is potentially the largest cause of swapping you can have even with a good setup due to the pre-fork model that 95% of people use.

Step into the new world, move to non-blocking servers such as lighttpd that use kqueue/epoll etc.. that have loads of advantages.
1. Tons less memory usage, this servers are built to run with small memory footprints yet handle more concurrent connections/request then apache could ever dream of.
2. They natively implement the fast-cgi model which is a Must for a heavy traffic site. mod_php is fine for small servers, but when you get into heavy traffic fast-cgi is the only Proven Stable platform for handling such loads.

Thats all for me on this issue ;)

I know we could get more out of it. The owner's Goggle revenue has been quite steady in the lower $x,xxx range per month for a couple of months now so I plan to soon try and convince her to allow me to requisition somone with advanced server and vBulletin specific knowledge to give her machine a once over. I personally think that will help quite a bit.


All times are GMT. The time now is 06:33 AM.

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01017 seconds
  • Memory Usage 1,740KB
  • Queries Executed 10 (?)
More Information
Template Usage:
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (4)bbcode_quote_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)pagenav
  • (1)pagenav_curpage
  • (1)pagenav_pagelink
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (4)printthreadbit
  • (1)spacer_close
  • (1)spacer_open 

Phrase Groups Available:
  • global
  • postbit
  • showthread
Included Files:
  • ./printthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/class_bbcode_alt.php
  • ./includes/class_bbcode.php
  • ./includes/functions_bigthree.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • printthread_start
  • pagenav_page
  • pagenav_complete
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete