On Wed, Mar 24, 2010 at 1:27 PM, Karanbir Singh mail-li...@karan.orgwrote:
Use this as a reference platform, eg if you can get 25% better performance
by moving all your static content ( eg. graphics, css, js ) into a tempfs,
that will translate to a about the same level[1] boost in production as
well.
What are the benefits using these static media in tempfs (in WebServer
Environment)? Can you please show some examples/cases? Anyhow, as I know,
modern servers load the content in memory, delivers it to client, and keeps
the cache in RAM for reducing disk level IO.. This can clearly be seen, a
long running apache just fills more and more RAM even if the load reduces.
If we use tempfs, we are keeping just copies of static content in memory -
one sure wastage of precious memory.
Assuming (and probably its fact), when your site gets popularity, your
Static Media content collection will become huge with the time. So, I don't
think, tempfs should really be in scene.
If you have a quad core, perhaps locking down 2 cpu cores and dedicating
them for the mysqldb might be a good idea.
This is a good idea, again if you are using same system for WebServer and
Database server. But keep them apart, life would be much easier (and cost
would be little expensive).
Similarly, separating the i/o for http and mysqld at the block device level
might be something you want to look into.
What you meant by this? Do you want to say Keeping them in different
partitions or disks would be beneficial?.
These are just some generic options you can look at - before you move into
app level optimisations. And there are many many things that could be done
there as well. Simple things like - are you running the webroots with atime
enabled / ensure that db index's are valid and the querylog isnt reporting
runtimes greater than a second for most things
Hope this helps and gets you thinking along a more formalised path.
My suggestions would be take the same route, what the others have taken,
and is already proved. Read mysql performance blog for tuning mysql. Then
read the case-studies and tricks on highscalability.com
You will find them really nice and proven, although you won't need that
much, but you will get insights.
Now, if I have to do something like this, I start with Browser. I
install *Firebugplugin
+ *Mozilla Firefox, enable the Net section, and refresh/load my webapp page.
It shows how much data is recieved, and what are those data.
Most static contents are then put in a rule to not expire, so browsers
won't hit the server for same data. Take an example, jQuery javascript
plugin is around 60KB (minimized version). But 60KB is too much for me. I
enable GZip compression on the webserver, so when a browser sends requests
with header saying it knows/supports GZip compression, my server just
compresses the JS (or any content which can be compressed - more effectively
texts). The size becomes too less, around 16KB (in transfer). When browser
gets it, it decompresses and presents to the page. That saves bandwidth, and
a lot time.
Now, since I am not going to update my jQuery, CSS, JS and images (which are
static to site), i write the rule in apache config to deliver them with
expiry time set in months. So next time browser wont hit my server for
getting the jQuery or other expensive media files.
After that - I look into either DB or App level for tuning. But if I have to
use the caching, I use it from the beginning of development. And what I put
in cache (like memcache) -
- Rendered page blocks : Today we use Template languages in every
framework. They are comparitively slow, takes a lot cpu in rendering the
content. So good idea would be to save those cpu ticks :)
I just get my templates rendered and push that in cache server, giving
expiry time depending on how dynamic presentation is. Even if I give 5 mins
for Homepage template blocks, it saves a lot CPU.
- I enable slow_db_logging in mysql config, so taht I can get those
queries which takes more than 1 sec (and 1 sec too is really evil). Getting
all those queries, I try to find how to optimize, either at application
level, or query level or db level.
- In application, when I fetch a query result, I store them in memcache
server. When I change something at users-request to that table, I do
invalidate those cached result. That way, data is always fresh till you
follow the rule One Entry and Failure point at application level.
- I prefer only those servers for delivering my static contents which are
based on libevent. That are really fast in processing multiple requests
concurrently.
But in Tanveer's case, he is using vBulletine, a ready made package. And he
won't want to spend his time in fine tuning at application level. So he need
to play at hardware, server (apache + mysql) and content delivery by other
server like nginix. He can also search Google to find way to attach caching
server into
