StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
17666071
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-07-16T00:23:55.453
FavoriteCount
0
LastActivityDate
2013-07-16T00:23:55.453
LastEditDate
LastEditorUserId
0
OwnerUserId
856823
ParentId
3046551
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
I think you were getting confused by varnish's response buffering. Let's say the fastest your backend can respond with a 100k page for a given request is 10 seconds, sending 10k each second. Without varnish in your stack, the client connection gets tunneled directly to the back end, and the browser starts receiving data in 1 second (the first 10k, and starts to parse, render, follow <code><link></code> tags, etc). With varnish in your stack, it waits for the back end to send the entire page before sending the first byte to the client. So the client has to wait 10 seconds until it can start rendering the page, following <code><link></code> tags, etc. Believe it or not, this is a good thing for two main reasons. One, if that response is cacheable, the next client won't have to wait 10 seconds for the back end to generate the response, varnish will serve it quite quickly (ms, not s). If your hit rate is high, which you should optimize for, the initial cost of having to wait for the first byte of the response pays many dividends in future cache hits. Two, let's say a mobile phone on a spotty cell signal requests that same 100k page, but it can't download the page as fast as the backend can generate it, it needs a full minute to receive the 100k page. With varnish in place, apache doesn't have to waste a connection and thread for an entire minute (mostly idle, mind you) while it slowly transmits the data to the client. It sends the data as fast as it can to varnish, and then moves on to the next request while varnish sends the data slowly to the client. For requests that are known not to be cacheable, you can configure varnish via VCL, if you desire, to <code>return (pipe)</code> which will result in no response buffering. It will send data directly from your back end to the client as soon as it receives it. But in the default.vcl pipe is not used.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POVarnish waits for the complete page load before sending response to browser
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USJohnny C
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.