Author Topic: Backup Server behavior  (Read 5692 times)

Offline BlackFly

  • Contributor
  • ***
  • Posts: 27
Backup Server behavior
« on: January 25, 2014, 04:02:07 PM »
I have a normal Acc and a blockacc as backup Server for incomletes.
If i'm downloading a file with many incompletes i got a problem that alt.binz want to switch the servers very often and take a long time to connect to the server (and in case of the backupserver it is often unable to connect) which will result in very low speeds.

It is possible to change the backupserver behavior? I think it should be better if alt.binz will download everthing o the primary server what is possible and at the end of the download it will switch to the backup and download all the rests. Another possibility should be if alt-binz will connect to the primary and backupserver simoultaniously and will only use the backup if needed all the other time it could be idle

Offline freelance86

  • Contributor
  • ***
  • Posts: 14
Re: Backup Server behavior
« Reply #1 on: January 26, 2014, 06:59:51 PM »
I think it should be better if alt.binz will download everthing o the primary server what is possible and at the end of the download it will switch to the backup and download all the rests.

afaik altbinz is designed to write from memory cache and not from hdd temp folder so doing that would create alot of unneccesary hdd read/write operations especially if its done at the end of the collection. if its done at the end of each file within the collection (before it decodes) then it could help but it makes more sense to work exactly how it does now, whereas if the part isnt found it will cycle all other servers before moving onto the next part.

i know where your coming from as ive had a few downloads that have slowed to a crawl because both the primary and first backup server were missing the majority of parts but second backup had them, i just ended up switching the servers around to make old second backup the primary, old primary the first backup and old first backup the second backup.

if its a common occurrence look into a better primary provider...

Offline BlackFly

  • Contributor
  • ***
  • Posts: 27
Re: Backup Server behavior
« Reply #2 on: February 01, 2014, 09:15:54 AM »
I think i have a good combination of primary and backup Servers.
It is not so often that this problem ocours but it is very annoying if it ooccours!
What is with the second solution? Connect to the primary and secondary servers simultaniously but use only the primary if everthing is working fine and if the primary Server isn't able to get the file use the secondary?

The only Problem is that my secondary server (Gebriukhet) needs to much time to connect if you connect and disconnect very often...

Offline davidq666

  • Contributor
  • ***
  • Posts: 1302
  • Watashi Wa Ero Desu!
Re: Backup Server behavior
« Reply #3 on: February 01, 2014, 11:40:17 AM »
I agree the switching between primary and backup is a serious drag on download speed.  When i come across a post that uses my backup i often switch the backup to primary just for that download.

I would like to see an automatic switch option. After xx missed attempts on primary permanently switch to back up for that specif collection. There could be a check box to define that limit either as missed attempts in total or consecutive missed attempts.

Either way I'd still like to see a dropdown menue attached to the connection button that lets you switch servers without going through the settings menu.

Offline niels

  • Contributor
  • ***
  • Posts: 2
Re: Backup Server behavior
« Reply #4 on: February 25, 2014, 09:55:02 AM »
I'm in a similar situation to the OP.  I have a monthly primary, and a block backup.  I have a relatively high latency link, so would like to maintain as many active connections as possible.  It'd really help my situation if the backup server had a connection pool of its own, rather than share the connections with the primary.

In other words, assuming they had 10 connections each, the 10 connections on the primary would always be logged in and in-use.  If an article fails from the primary, it would be sent to the backup connection pool to fetch it, and the backup pool would connect threads as required (and thus not slow down attempts for new articles from the primary).

Offline zoned

  • Contributor
  • ***
  • Posts: 115
Re: Backup Server behavior
« Reply #5 on: March 02, 2014, 09:30:57 AM »
I'm in a similar situation to the OP.  I have a monthly primary, and a block backup.  I have a relatively high latency link, so would like to maintain as many active connections as possible.  It'd really help my situation if the backup server had a connection pool of its own, rather than share the connections with the primary.

In other words, assuming they had 10 connections each, the 10 connections on the primary would always be logged in and in-use.  If an article fails from the primary, it would be sent to the backup connection pool to fetch it, and the backup pool would connect threads as required (and thus not slow down attempts for new articles from the primary).
That is how it is now and it swamps the primary.

Maybe each server has two further settings to help Altbinz. For example two servers primary and backup.

Primary Server (A) retention is 1000 days
Backup Server (B) retention is 2000 days

Server Settings

Primary Server A Setting | 0-900 days (post retention)
Primary Server B Setting | 901-2000 days (post retention)

Primary Server A never downloads or attempts to download posts that are above 900 days
Primary Server B never downloads or attempts to download posts that are below 901 days or above 2000 days

The over sever a, b is simple and clear cut. Though if have more servers that overlap the retention post days those will have same problem that is now. Until they change the settings to be simple as the example above for all other servers they have.

Altbinz could allow for many servers maybe Servers A-Z using the above suggestion is all that is needed with multiple servers.

Offline zoned

  • Contributor
  • ***
  • Posts: 115
Re: Backup Server behavior
« Reply #6 on: March 02, 2014, 09:41:21 AM »
Addition to the above

Maybe Altbinz behaviour could be changed. Where all post parts that are not complete they remain on the download list in a pause state until later.

When not all posts on the download list but when the Actual post archive has been downloaded then Altbinz does the same as would do with par2 files and before par2 file downloading. Will un-pause those previously paused incomplete parts and retry using all other available servers (whatever date they have set in settings) to complete the archive. After that par2 files are downloaded to complete if possible. To try complete the whole archive or best that can be between all servers and global retries setting.

Offline wizziwig

  • Contributor
  • ***
  • Posts: 14
Re: Backup Server behavior
« Reply #7 on: May 25, 2014, 12:54:48 AM »
I wish this worked like Newsleecher.  When a backup server needs to be accessed, it switches to it without disconnecting the primary.  When they go back to the primary, the backup will remain connected until it hits the usual idle timeout.  If the backup server is needed again before the timeout, it's still connected and the download of the missing part starts instantly.  In their implementation, the primary also instantly starts downloading the next part while the backup is grabbing the missing parts.  That would require separate queues for primary and backup and is probably too much work for alt.binz.  I would be happy if it just stopped the constant re-connections.

The current alt.binz solution is terribly slow and inefficient.  It's constantly closing and opening connections when switching primary and backup.  On some providers, it literally takes 10+ seconds to establish a connection so your download grinds to snail pace.

Offline domdom

  • Contributor
  • ***
  • Posts: 110
Re: Backup Server behavior
« Reply #8 on: July 15, 2014, 10:13:53 AM »
+1, take downs are not going away and optimized backup server management would be nice.
It would be a nice area of improvement since Altbinz hasnt been updated in a while? Rdl?  :) :)
Much appreciated

Offline Rafael

  • Contributor
  • ***
  • Posts: 9
Re: Backup Server behavior
« Reply #9 on: September 10, 2014, 07:06:34 AM »
Yeah! I am having this issue right now.

The real problem is that the threads drop the connection when switching server! I think the behavior should be, once open, keep it open, at least for a while, even if idle. I even enabled the "Connected while idle" thing hoping it would change this but it didn't.

So it:
- tries on the primary server
- drops the connection on not found
- tries first backup server
- drops the connection on not found
- tries second backup server
- Repeat for the next article

This is VERY slow! Plus it addup to servers connections limit: they take to long to notice the closing making this VERY VERY but VERY slow!

I think simply keeping the connection alive when switching servers would solve this! Please, add this feature!

Offline Benjiro

  • Contributor
  • ***
  • Posts: 8
Re: Backup Server behavior
« Reply #10 on: December 21, 2014, 01:44:13 AM »
Also noticed this problem. Its actually very annoying. Not only that, it can also trigger too many requests to the primary / backup servers, and then they start blocking your connection.

Offline Rafael

  • Contributor
  • ***
  • Posts: 9
Re: Backup Server behavior
« Reply #11 on: December 21, 2014, 02:01:13 AM »
Exactly what I meant by: "they take to long to notice the closing". "too many requests to the primary / backup servers" always happens to me when no/most of the articles cannot be found on the primary server! Even though they all can be found on the secondary!

Offline bifidus

  • Contributor
  • ***
  • Posts: 24
Re: Backup Server behavior
« Reply #12 on: March 16, 2015, 07:09:39 PM »
I thought I was the only one having this problem  ;)
I've 4 servers and almost everytime Alt.Binz stops downloading after a while. I've to disconnect and reconnect to get downloading further.
It's very annoying when I queue stuff and find out after a couple of hours, only some files have been downloaded.

Offline dabrown

  • Contributor
  • ***
  • Posts: 81
Re: Backup Server behavior
« Reply #13 on: March 31, 2015, 04:48:10 PM »
I too am experiencing this problem, and if I had to guess, many people are.

The way that alt.binz handles the primary and backup is really painful, as if there are a number of blocks missing from the primary, I notice that eventually, most of my connections are trying the backup, and often what happens is the backup server blocks me out and I have to wait until it times out those connections.

Worst of all, if there is a propagation issue and the blocks are missing from the primary and backup, each missing block is retried multiple times (I have mine set to 3 retries) and also contributes to the slow down.

I don't know what the solution is here, but I thought I should add my comments in case the more people who have issues, might give it higher priority?  Well, I'm hoping it does :-)

Thanks