[tor-talk] OnionBalance Hidden Service has over 1 million successful hits in just 3 days

Wed Jul 8 21:10:43 UTC 2015

Seems plausible, though from what I have logged it's hard to tell. All
the time calculations are 0, which may mean that curl completely failed
to connect, or that it's counters don't work if the connection fails
(I'm not sure which is true).

I forgot to tell it to add a timestamp, so comparison against your logs
would be nigh on impossible - have set the same script running with
timestamps added, will keep an eye to see whether any failed connections
have been logged.

I do, however, have some entries in my tor client logs

Jul 08 09:03:55.000 [notice] Rend stream is 120 seconds late. Giving up
on address '[scrubbed].onion'.

(time is UTC) 

though there aren't enough to account for all the failed connections.

Thomas White <thomaswhite at riseup.net> wrote:
> I wonder if the curl 000 codes match up against our 408 codes for a
> timeout? So the connection was made, the request was about to be made
> then the circuit failed? I'm not overly familiar with the precise
> nature of curl or apache logging systems.
> 
> On 08/07/2015 15:39, Ben wrote:
> >> From the client end, I've seen occasions where I couldn't connect
> >> to the
> > HS, though it's a very small percentage (around 1.5%).
> > 
> > Count Status code 590 000 408391 200
> > 
> > 000 being the code curl returns when it couldn't connect. In terms
> > of time to serve, there's a fair range of variation in terms of the
> > total connection time.
> > 
> > Count  Seconds 45207 0 149979 1 103050 2 55134 3 27011 4 13688 5 
> > 7405 6 4022 7 2217 8 1324 9
> > 
> > All connections were established in less than a second, and the
> > time to first byte was generally < 2 seconds
> > 
> > Count TTFB 590 0 408479 1 1 3 1 4 1 5 1 6 1 7 5 8 10 9
> > 
> > 
> > Obviously some of the variation might be down to my client's
> > connection rather than the hidden service, it's running on a stable
> > 100Mb/s connection, though the traffic graphs show some fluctuation
> > in the bandwidth being used (attached - stats taken at the NIC so
> > likely includes other traffic though the test will be the primary
> > use).
> > 
> > Happy to send the stats file in full if it's of any use to you.
> > 
> > 
> > Thomas White <thomaswhite at riseup.net> wrote:
> >> Just to expand on s7r's number, I just pulled the latest logs
> >> from the servers and compiled a quick breakdown of the HTTP
> >> codes, bandwidth etc for anyone interested:
> >> 
> >> HTTP Code: 200 (OK) Bandwidth used (bytes): 690,400,220,422 Hits:
> >> 4,784,288
> >> 
> >> 
> >> HTTP Code: 206 (Partial Content) Bandwidth used (bytes):
> >> 5,202,918 Hits: 64
> >> 
> >> 
> >> HTTP Code: 304 (Not Modified) Bandwidth used (bytes): 52,059 
> >> Hits: 259
> >> 
> >> 
> >> HTTP Code: 404 (Not Found) Bandwidth used (bytes): 266,053 Hits:
> >> 611
> >> 
> >> 
> >> HTTP Code: 403 (Forbidden) Bandwidth used (bytes): 2,908 Hits: 7
> >> 
> >> 
> >> HTTP Code: 408 (Request Timeout) Bandwidth used (bytes): 0 Hits:
> >> 5,442
> >> 
> >> 
> >> Total bandwidth usage (bytes): 690,405,744,360 (690 GB)
> >> 
> >> Total hits: 4,790,671
> >> 
> >> 
> >> Not bad for a few days work guys!
> >> 
> >> T
> >> 
> >> 
> >> 
> >> 
> >> On 08/07/2015 03:00, s7r wrote:
> >>> *Numbers look good: Over 4 million hits in 7 days.*
> >>> 
> >>> I want again to use this opportunity to say THANK YOU to
> >>> everyone who is contributing and stress testing. 4 million
> >>> requests tell me people are putting quite some effort into it.
> >>> Please continue to stress test as much as you can in the next
> >>> days. After I collect some rendezvous circuit stats also, we
> >>> will stop the test - don't want to overkill the network, prefer
> >>> to leave more bandwidth capacity for users.
> >>> 
> >>> I was waiting to have some rendezvous circuit statistics as
> >>> well, to compare them with the hits on the webserver and have
> >>> an overview on the circuits stats and average number of
> >>> requests per circuit. Hopefully this will happen in the next
> >>> days. Since you asked, here are the exact numbers now.
> >>> 
> >>> The service was started 1st July 2015. Here are the counts
> >>> today, 8th July (little over 7 days of uptime):
> >>> 
> >>> Failback instance #1: 956281 Failback instance #2: 732187
> >>> Failback instance #3: 837818 Failback instance #4: 768636
> >>> Failback instance #5: 911546 =============================
> >>> TOTAL: 4206468
> >>> 
> >>> There are no significant warnings or errors - the same
> >>> instances are running since service first started, no reboot or
> >>> application restart. I am happy with how it works. As you can
> >>> see we have *over 4 million hits*. The number of requests per
> >>> failback instance confirms the load is fairly spread.
> >>> 
> >>> Hidden service http://eujuuws2nacz4xw4.onion/ up and strong!
> >>> 
> >>> On 7/8/2015 1:48 AM, tqr2813d376cjozqap1l at tutanota.com wrote:
> >>>> 4. Jul 2015 22:57 by s7r at sky-ip.org <mailto:s7r at sky-ip.org>:
> >>> 
> >>>> After little over 3 days of uptime, the OnionBalance hidden 
> >>>> service http://eujuuws2nacz4xw4.onion 
> >>>> <http://eujuuws2nacz4xw4.onion/> was successfully accessed
> >>>> over 1 Million times. There was no complaint in any of the
> >>>> running Tor instance s.
> >>> 
> >>> 
> >>> 
> >>>> Hey s7r, things still looking OK? How are the numbers now?
> >>> 
> >>> 
> >> -- tor-talk mailing list - tor-talk at lists.torproject.org To
> >> unsubscribe or change other settings go to 
> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> -- 
> tor-talk mailing list - tor-talk at lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk