Author Topic: Cache Changes (Read 4133 times)

KM · « **on:** March 26, 2006, 07:52:12 pm »

Just running some tests with some new peer cache software on 82.195.155.5 - it will be running the new cache software (minus the connection testing) tonight just to see how it handles on a live server, if anyone wants to test it out by forcing winmx or various other third party applications to use that cache and that cache only and see if you have any problems - if any programs are having problems connecting using that cache then let me know so i can have a look in to it...

also check some of the existing modified versions of some third party applications (i am thinking in particular of those that were modified shortly after the shutdown that are fixed to only using 82.195.155.5 - as the cache traffic when switching to the new software quickly becomes double what it should be, which could indicate a program failing and trying over and over again)

i have chosen a sunday night as it is the time when least users are starting up winmx and getting their initial connection to the network so any problems should have minimal impact, and i have chosen that particular server (as apposed to another) due to the unique nature of that cache being the first online and therefore having traffic other than just the standard programs (for example the edited programs mentioned above)

before anyone asks the obvious "if the old software works, why replace it?" 2 reasons -

1. the new one should be more reliable - the current cache software fails after a couple of days, so i have it set to restart every 10 minutes (ok, slightly excessive there), with all kinds of backups in place that shouldn't really be needed - i figured that workaround was easier than fixing the bug itself as i can live with the bug, but in fixing it i might break something else...

2. it is a lot more efficient and uses much fewer resources on the server whilst hopefully returning better results to the clients (although the improved results probably won't be noticed as very few users will notice connection times dropping from the current 3 seconds to about 2) - but the traffic routing should be more efficient for the network, not sure how much of an effect that part of it will have (if any) though

I'm going to bed now, in the morning I'll be switching it back to the old cache software and of course checking this thread for any feedback

GhostShip · « **Reply #1 on:** March 27, 2006, 04:41:38 am »

I haven heard any screams yet, so its hard to tell if there have been any problems.

KM · « **Reply #2 on:** March 27, 2006, 04:47:36 am »

perhaps choosing a quiet night was a bad idea?

did anyone specifically test for problems? because there are no reports of things being broken :-S

oh well, I've switched it back to the old cache software now - at least i know that the new cache software (when it's completed) will run just as well on a live server as it does on my test servers, not a single error

unfortunately any client issues with using the cache have not been identified

(btw, server load average went down to 0.08 - compared to the 0.55 it normally sits at... i didn't realise the old cache software was responsible for that much of the load!)

~~GnarlySnarly~~ · « **Reply #3 on:** March 27, 2006, 02:52:39 pm »

I tried.. and got connect times from 2 to 30 seconds - tested both as primary and secondary. Most attempts were fast to connect, but several took 10-30 seconds.

but ran into some things i don't understand. got some strange firewall behavior and other distractions.

I edited my hosts list, so only 1 IP was used. actually i reverted to your original hosts list from last sept and fixed the 7 or so typos and used it.

Then:
I did ipconfig /flushdns
I added a firewall alert rule for the CS IP

On every disconnect/connect, i saw winmx try the same cache server, c3310.z1301.winmx.com, over and over.

27/Mar/2006 00:41:20 km test 82.195.155.5 permitted; Out TCP; localhost:3949->c3310.z1301.winmx.com [82.195.155.5:7952]; Owner: C:\PROGRAM FILES\WINMX\WINMX.EXE

I thought it picked one of the 120 hosts at random. Also, I thought that host [c3310] was for winmx version 3.31 - and that the cache servers in the c352x range were for v 3.53 and 3.54. But I have made incorrect assumptions before.

After I did the /flushdns command, I did the /displaydns command.. and got lost. It showed a long list of winmx.com hosts but with CNAME, not hosts list replacements. The only hosts list replacement was:

c3310.z1306.winmx.com
----------------------------------------
Record Name . . . . . : c3310.z1306.winmx.com
Record Type . . . . . : 1
Time To Live . . . . : 604559
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 82.195.155.5

And that was not the one being used.. all connects were to c3310.z1301.winmx.com, not c3310.z1306.winmx.com
There was no entry for c3310.z1301.winmx.com shown with /displaydns

all the other entries were like this, with each listed host linked to a different CNAME, not an IP like the single entry above:

c3317.z1302.winmx.com
----------------------------------------
Record Name . . . . . : c3317.z1302.winmx.com
Record Type . . . . . : 5
Time To Live . . . . : 604559
Data Length . . . . . : 4
Section . . . . . . . : Answer
CNAME Record . . . . : c3310.z1302.winmx.com

No hosts list replacement.. and why is c3317.* replaced with c3310.* ?

Isn't the /flushdns command supposed to clear all such entries anyway?

I did it over 10 times and those entries stay. I cleared it and rebooted. On restart, the first thing I did was open DOS and do the /displaydns command.. and a long list of winmx.com addys were there. I can't seem to clear them and don't see their function.

I set another cache server IP for the c3310.z1301.winmx.com host, then blocked it in my firewall to try to force winmx to use a different host., did /flushdns - i saw the attempt to connect to the other IP get blocked. Then winmx passed a call to c3310.z1301.winmx.com at to 82.195.155.5. How did that happen? I had assigned c3310.z1301.winmx.com to a different IP! I had reset the hosts list, flushed dns, closed winmx. So i have no idea how it was redirecting c3310.z1301.winmx.com to 82.195.155.5 - it was not assigned to that host in my hosts list.

KM · « **Reply #4 on:** March 27, 2006, 05:53:50 pm »

that's because the hosts file also controls reverse DNS requests, it's not showing a DNS lookup for that hostname, it is showing a connect to that IP Address, and the hostname for that IP Address - which if you use a hosts file to override it will be the first hostname it finds that matches that IP

however the connection times - comparison between last night when it was running the new software and how long it takes on the old software to connect? (ie. try it again now and see if it's any different) - and also, primary or secondary (/third party application)?

both primary and secondary seem to work, however as i mentioned for some reason there seem to be a lot more requests than normal when running the new cache so that could indicate clients failing and trying over and over...

~~GnarlySnarly~~ · « **Reply #5 on:** March 27, 2006, 07:12:44 pm »

Quote from: KM on March 27, 2006, 05:53:50 pm

that's because the hosts file also controls reverse DNS requests, it's not showing a DNS lookup for that hostname, it is showing a connect to that IP Address, and the hostname for that IP Address - which if you use a hosts file to override it will be the first hostname it finds that matches that IP

What about /displaydns after reboot?

No winmx running.. nothing but the basics. Right after reboot, the /displaydns listed 10-15 winmx.com entries.. Why would they be there without having started winmx yet?

KM · « **Reply #6 on:** March 27, 2006, 07:14:55 pm »

http://technet2.microsoft.com/WindowsServer/en/Library/7356d145-e8ee-4dae-9edb-8b08a37e53841033.mspx

Quote

The ipconfig /displaydns command provides you with a means to view the contents of the DNS client resolver cache, which includes entries preloaded from the local Hosts file, as well as any recently obtained resource records for name queries resolved by the system. This information is used by the DNS Client service to quickly resolve frequently queried names before it queries its configured DNS servers.

because you are viewing your hosts file...

~~GnarlySnarly~~ · « **Reply #7 on:** March 27, 2006, 07:50:56 pm »

connections tests today:
10 P connects: avg 8.1 sec [3 11+]
10 S connects: avg 6.4 sec [2 11+]

over all seemed slower - few fast connects, only 1 over 13 sec.
so the other last night seemed to have a wider variation. lots fast but also a few over 20 sec.
but i wasn't as pedantic last night due to my distraction over the host/IP confusions.

KM · « **Reply #8 on:** March 27, 2006, 09:02:49 pm »

so, overall, probably not any negative effect? (btw, i did say i didn't think anyone would notice any improvement with the slightly better results being returned

)

..Ñøßß¥.. · « **Reply #9 on:** March 28, 2006, 09:04:43 am »

Should the changes not prove disruptive, does this mean you will be moving forward with a reliability test for the upgrades?

KM · « **Reply #10 on:** March 28, 2006, 05:58:59 pm »

the cache software seemed to work here fine, and i was just so surprised at the results i was getting in testing that i had to test it on a live server to believe it... hence that test, now that i know i'm not being deceived i can finish the software off and put it in to operation on the servers (well, when i get some time off of work to do it!)

KM · « **Reply #11 on:** March 28, 2006, 10:54:01 pm »

ok, for the next few days i'll be switching back to using the new cache software on that server again - just for some more testing... seems to be fine, nobody seemed to have any problems during the first test but this will be a longer test (over a few days) to give more chance for bugs to pop up

~~GnarlySnarly~~ · « **Reply #12 on:** March 29, 2006, 12:53:51 am »

Quote from: KM on March 28, 2006, 10:54:01 pm

ok, for the next few days i'll be switching back to using the new cache software on that server again - just for some more testing

Is it active now? if not now, when?

KM · « **Reply #13 on:** March 29, 2006, 06:25:23 pm »

indeed it is, from the time of that post (well, actually 10 minutes or so before that post) - seems to be running well as far as i can see... the old cache software is still running in the background but is inactive (as long as another program is listening for the connections it will get none), the new software is still handling all queries without having failed... yet...

a few minor changes since the test on sunday night, but nothing major - if all is still running fine on the weekend then I'll consider it a success and start work on the other bits of it (ie. connection testing)

btw, in case nobody was aware... 2.2 of the winmxgroup patch gets the blocklist from the caches as well (using the hostname blocklist.winmxgroup.net) so there's something else you can play with, that part is being handled by the new software on that server

KM · « **Reply #14 on:** March 30, 2006, 03:29:43 am »

ok, just finished the last few bits on the new cache and uploaded it to that server, should now be a standard fully functional cache that impliments everything - and the only things that should need changing from now on will be bug fixes

and, both servers are running the new cache software as of.... now, might as well put them both on it to indicate how much faith i have in my ability to write flawless code that will function perfectly

* KM starts preparing just as flawless backups ready for when it crashes

[/size]

..Ñøßß¥.. · « **Reply #15 on:** March 30, 2006, 06:45:26 am »

Quote from: KM on March 30, 2006, 03:29:43 am

* KM starts preparing just as flawless backups ready for when it crashes
[/size]

lol lets hope thats not a required feature.

KM · « **Reply #16 on:** March 30, 2006, 05:58:53 pm »

was a minor bug in the connection testing code... that not only rendered the caches inoperable for a short period but also rendered the backup inoperable, lol

now to track down the bug...

Bearded Blunder · « **Reply #17 on:** March 31, 2006, 01:13:36 am »

I don't know if it's related or not, but getting robomx to connect has become so unreliable suddenly I'm seriously considering returning to "force connection to specific node" & using my own primary.. even though PM becomes nearly unusable that way....

*edit that should read RoboMX ShareGuard & Ouka all not connecting, only WinMX will*

~~Josh~~ · « **Reply #18 on:** March 31, 2006, 02:23:54 am »

the ireland server is doing bad. And my winmx takes forever to connect now.

KM · « **Reply #19 on:** March 31, 2006, 11:41:57 am »

it does seem to have a bug - btw the reason some programs are having a problem is due to the cache outages, switched ireland back to the old cache software and I'll run the new software only on germany until i get the bug fixed.... should mean no issues at all with cache outages (as no clients are completely dependent on germany, whereas many are dependent on ireland)

btw, anyone suggesting i just run the new software on a test server - won't help, it ran for a week on an idle test server without problems, some things can only be tested with real traffic

but using germany for testing should avoid any problems...

the initial tests seemed fine, which leads me to conclude that the bug is somewhere with connection testing (it seems to be running out of handles - so probably a bug with closing sockets properly when running tests)

edit: i have also just reduced the traffic being sent to that cache, just so any outages don't cause delays