New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Apache is kind of heavy in terms of webservers, have you considered one of the other options our there like Nginx, Lighttpd, or Cherokee?
That being said I did a test a while back and with Lighttpd, a 64MB Xen VPS (w/ 128MB swap) could handle serving a static HTML page to 400 users at the same time without any dropped connections.
For a simple blog/site you can use static site generator (ie: jekyll, hyde, blogofile, etc) + discuss for comments and you don't need to worry about security (except for the webserver and the vps itself)
Xen/KVM/VMware? or is OpenVZ
openvz, of course
i want to see if i would be able to run a mediawiki site with 1000 visitors a day, and maybe ~100 edits/day on 96mb guaranteed/196mb burst...i havent run a major operation ever, so i have no clue on how much is needed
"If I run Apache, MySQL, PHP, and MediaWiki, how many visitors can I handle at once?" With 96MB of RAM.... about 2, if you're lucky. I had a MediaWiki install on an Apache server with 512MB of RAM and it locked up with 20 simultaneous clients.
You'll need to start with nginx instead of Apache, and you'll need to set up Squid and APC, at the very least.
I guess it depends on the configuration?
@feartrich: Go for Nginx. If you don't know how to install it, you can use LEB script.
@KuJoe: With proper optimization it uses about 50 MB memory.
@iKocka That looks more like 34MB of RAM to me, impressive!
On my xen 96MB vps I've got php running using 18 M of memory
total used free shared buffers cached Mem: 89 84 5 0 25 41 -/+ buffers/cache: 18 71 Swap: 255 1 254Using my version of lowendscript with php-fpm.
Also ipv6 with 6to4.
I don't believe Mediawiki caches out of the box either. That's some thing you'll need t look at as well. Save you some processor and memory if you could do that.
@Keith: Once you will have MediaWiki installed and there will be few hundred visits per day, memory usage will increase.
@drmike: CloudFlare does job well with it's agressive caching.
I believe that's the completed files. the caching I was suggesting was of mySQL and you have to have the program do that.
@iKocka @drmike -- CloudFlare's "aggressive caching" is only setting the expiry date of static assets to far distant future to force the browsers not fetching those files again. I do not think it does any magic on dynamic files.
Even with static file aggressive caching, which you can easily do yourself as well, that increases very little workload to event based webservers like nginx or lighttpd.
I know with most of the caching that we do on the software platforms we use, static caching would only be half of what's needed. usually you can setup some sort of caching for MySQL calls and that helps a lot.
I might have said before -- caching and cache invalidation have lots of comp science behind it and is a difficult problem to solve. These days in order to scale, your applications pretty much need to be smart enough to know how to cache (HTML blocks, MySQL results, etc) and how to invalidate them when new updates come in. The would differ from app to app.
MySQL query cache (simple to turn on in
my.cnf) is okay when you have mostly-read queries. However your result set cache gets invalidated as soon as any one of the table in your query gets updated. Even on a simple app like WordPress, it creates way too much cache misses.While caching is nice, wouldn't it be easier to just run a second LEB dedicated to MySQL?
I believe MediaWiki has built in caching for static pages. Though I doubt this would save on much RAM, especially for a large site.
http://www.mediawiki.org/wiki/Manual:File_cache
I wish could figure out how to use the quote function.
@KuJoe While caching is nice, wouldn't it be easier to just run a second LEB dedicated to MySQL?
I know with most of the CMS caching function that I see, you can get rid of upwards of 90% of the calls.