Two tables for each torrent uploaded!!!
Brought to you by:
danomac
Menu
▾
▴
I am a bit new to php and mysql stuff. But is it not overkill when we use two tables for a single torrent. Because we can keep the infohash Vs userip in a single table. So if multiple peoples are involved in a torrent than we have multiple rows(one row each for a single user).
Can someone clarify a bit here why we need TWO tables for a single torrent file.
Another thought on the same line. As the raised question boils down to the behaviour of mysql, is it advisable to keep a lot of tables with less data each open or a single table with large data. There is something in mysql configuration like table_cache that determines the maximum number of opened table.
So in this case if we are creating two tables for each torrent file and than in case of high traffic mysql want to open a large number of tables at the same time. Does anyone have some first hand experience of hosting a tracker site of heavy traffic.
Thanks.
This project is a fork off of the original PHPBTTracker; this layout is something that was inherited from the original.
I'm not saying two tables for each torrent is a good idea however. I can try to explain why there is two tables for each torrent though: the original phpbttracker didn't do the compact announce. After the compact announce specification came out, it was decided to add a second table that only contains the compact information (which is also called peer caching in the original.)
Most clients use compact now, so 99.9% of the time, the 'y<hash>' table is used (this contains all of the compact information.) The 'x<hash>' table is the original table with the peer id and ip/port information.
Generally, the 'x<hash>' tables aren't used/accessed that often anymore unless the client is *really* old.
There is a test site that has heavy traffic using phpbttracker+ 2.1 that always has between 6-8000 peers on it. It has gone over 12,000 peers as well (this is however a dedicated PC.) The load on the database was about 220 queries/second.
As far as the database design goes, I will be starting to work on PHPBTTracker+ 3.0 in the New Year sometime. Of course there is no date set for a release, but it is possible for the brave to try CVS (possibly, haven't decided this yet) when I get enough of it rewritten to have a somewhat functioning tracker. It will be a new database design, and a complete rewrite of the backend - it won't be a fork off of the original phpbttracker after 3.0 is released. Of course, existing functionality from 2.x will be moved over into 3.0 as well.