Priv Out vs Priv In and Outgoing vs Incoming

What? Where? Why?How?

on app server
incoming - when you load data, or when there is write, but what about when app server is connected to the database server
outgoing - when you pump data, or just plain read
private in - ? My 'private ip in' is way higher than outgoing ?
private out - ?



what about on database server?
incoming - ?
outgoing -?
private in - ?
private out - ?

"Priv" (in and out) refers to the private network in each data center, for which traffic is free. For IPv4, this is the 192.168.x.x space, and for IPv6 any direct Linode to Linode traffic within a single DC. You have to configure the IPv4 case explicitly on your Linode (the address to use is obtained on the remote access tab), whereas for IPv6 you just use the normally configured address (or any of your own blocks).

Incoming and Outgoing are for your public network traffic, that is the traffic that counts against your transfer pool.

All directions (in/out) are from the perspective of the Linode whose graphs you are looking at.

-- David

ok - but how is it possible that application server's 'private in' is 5mb/s and outgoing is 400kb/s? Does that mean... it is pulling 5mb/s from the database server and pumping 400kb/s to visitors.

Why is it pulling so much? It is not in proportion to what it is receiving and pushing.

I figure if it is pumping 400kb/s, it will have an outgoing of 400kb/s...

?

More or less yes, depending on what other traffic may exist internally between those two servers. E.g., you might want to verify that the only (or clearly the majority) of the traffic from the database server to the application server is actually database traffic.


Well, it's in a proportion, just maybe not what you expect.

Having much higher database traffic need not be unusual, since the application may be processing a bunch of data to render an aggregate set of information to the client. What the expected proportion might be depends heavily on your application stack and what data it needs to generate results to clients. So it's difficult to say whether 12:1 is reasonable for your specific configuration.

While I don't use them, so this is speaking somewhat out of school, certainly comments I've seen on environments like Wordpress or Drupal and their load imposed on databases makes me think such stacks are pretty inefficient by default. Which is why caching is often emphasized.

Then again, if you're not having performance problems, 5Mb/s on the private network between two Linodes isn't necessarily a problem, either.


I'd consider that (1:1) to be unlikely; there's probably always somewhat more raw data (plus database protocol overhead) that gets processed than output generated to clients. Plus depending on your web server configuration you may be compressing things before sending to clients.

Of course, it could be something mis-configured, or just an inefficient application (pulling entire posts back just for a header, for example). Or maybe you have to pull an entire data set back to produce a single average number for the page. There's really no way to judge without knowing the specifics of exactly how the database is being used to render pages for clients. Depending on your database server or application stack you could probably log queries to see what's going on to render your pages.

-- David

thank you so much. It is more clear now.

It is also possible that the application selects all rows from a table and then sorts and/or picks out the rows manually, instead of using where or limit, offset. It's not unheard of.

Also, Drupal. It used to do dozens of queries and pull all sorts of data for nothing. I don't know if the situation has changed with recent versions.