• IP addresses are NOT logged in this forum so there's no point asking. Please note that this forum is full of homophobes, racists, lunatics, schizophrenics & absolute nut jobs with a smattering of geniuses, Chinese chauvinists, Moderate Muslims and last but not least a couple of "know-it-alls" constantly sprouting their dubious wisdom. If you believe that content generated by unsavory characters might cause you offense PLEASE LEAVE NOW! Sammyboy Admin and Staff are not responsible for your hurt feelings should you choose to read any of the content here.

    The OTHER forum is HERE so please stop asking.

Hey Sam Leong! Why SaMMYBOY.com is slow?

No leh it's normal ! Maybe they target you since you complain about PAP .

I love to say this now. Cos when I complain no one notice .
 
Ah Leong will never admit slow 1, his other forum also slow like fuck.

Anyway, :oIo: Christians, LOL :D:D:D
 
There is a transparent proxy that many time IS the problem in SG to access anything outside SG. The ISP Claimed THERE IS NONE, but there is a proxy in transparent mode, which in theory is supposed even to speed up web access for users, but as usual, doing the reversed.

On many occasions when I found it slow, I went via other proxies, it became faster. So it was for sure the local ISP's proxy was contributing to slowness.

But on some other occasions it appeared to be Sam's server side. Because going via other proxies will still get no access. I recall seeing V-bulletin's error message crying SQL database problem.

On a server running this sort of forums, there are several elements affecting speed:

1. Apache (usually) web server
2. PHP pre-processor usually on the same server as Apache
3. SQL server, which holds the posting messages, our login IDs & Passwords.
4. The hosting network's speed and load, even if it is a very fast carrier it can still be slow if it is heavily shared.

It depends on the hosting company and account type, most SQL servers are shared amount hosting accounts. Some SQL servers are dedicated in the more expensive hosting packages.

For heavily loaded sites, they can actually have multiple web servers each with own PHP, and each web server located at different parts of the world. Then they can be linked to the same SQL server. Each web server holds an individual A record in the DNS. This way the traffic load is split up and avoided single point of failure.

The only final bottleneck is the SQL server, which is limited by the fact that this entire interactive forum will only appear as one, if it is sourced from the same SQL db. Any otherwise there will be latency to hamper the interactivity of a discussion forum, affective the interactive dialog.
E.g. if I am posting into one SQL db and you are reading from another, where the SQL servers are master-slave clustered together, our interactivity can go wrong due to latency.

For less interactive type of purposes e.g. blogs, the master-slave topology can effectively help to relief SQL bottlenecks, that is blog authors updates into masters, and then the multiple slaves where the mass readers are reading the blogs from are periodically replicated from the master. This way the latency is acceptable, because only the refresh is late, there is not much of 2 way interactive communication between blog readers & authors that needs to be so real time, unlike an interactive discussion forum like this sammyboy.com

I believe that e.g. blogspot.com will use this type of topology, to have heavy user loads distributed to multiple slave servers, which are read only and periodically updated by from a master SQL, which only blog authors' posting will go directly there. In this way on the readers' side there is no single point of failure because multiple web servers and PHP and SQL are there located in different cities and different networks.
 
Last edited:
But on some other occasions it appeared to be Sam's server side. Because going via other proxies will still get no access. I recall seeing V-bulletin's error message crying SQL database problem.

This forum runs on a dedicated server. I have never seen the server load factor going beyond 1.5 even at peak hours. (5 is the red zone) The server has grunt to spare.

However, there are times when I might be doing maintenance in the background.. ie optimising or repairing tables, pruning threads, updating counters etc and these processes hog the CPU while they are running and slow down response for those using the forum.

If you see a database error message, it usually means one of more of the tables is corrupted and needs repair. It can also be caused when MySQL has crashed and needs restarting.

The forum is almost always extremely responsive from where I am. (no proxy required)
 
This forum runs on a dedicated server. I have never seen the server load factor going beyond 2 even at peak hours. (5 is the yellow zone) The server has grunt to spare.

However, there are times when I might be doing maintenance in the background.. ie optimising or repairing tables, pruning threads, updating counters etc and these processes hog the CPU while they are running and slow down response for those using the forum.

If you see a database error message, it usually means one of more of the tables is corrupted and needs repair. It can also be caused when MySQL has crashed and needs restarting.

The forum is almost always extremely responsive from where I am. (no proxy required)

That means SQL server is on the same machine as everything else.

If your load factor don't show very high, then can it be your hosting facility's network heavily shared? Can run some cron jobs to test speed via some speed testing site and log them, to see if you can discover anything clue.

If the network became too busy for users to reach your box, then load factor will also record low loads, while users KPKB about speed.

I would like to caution you to take some temp measure when the GE came. Sure you are going to jam! ;)

One compromised way may be to create a READ-ONLY MIRROR some where, so that during GE, when the actual site jammed people can at least read from mirror site.

Additionally, to facilitate opposition activists to post during the jam period, there can be another SECRET POSTING MIRROR, which runs the same script on another box, with SQL remotely linked to your main box, and URL only given to some users.

In this way, opposition will enjoy advantage over PAP's dogs in our Cyber wars. :p

You can secure remote SQL connection by permitting only recognized IP in SQL's IP WHITE-LIST.

;)
 
One man's junk is another man's treasure! :D

Which junk are treasures?, so that I can keep for remembrance? :p

sammyboy.com at some odd times, very slow to load, even I try using the two different ISP's, Starsux & Sing & Tell.

using IE 7, IE 8, when it is low, the page doesn't even load, but I use mozilla, only text load, but not anything else.

have no luxury at the moment to get a Macbook etc..to try safari 4.0, so that I can not comment.

but this occurance, I noticed is due to heavy traffic volume on the 'highyway' leading to sammboyboy.com, maybe the IB is holding a 'protest' along the way??:D
 
The traffic doesn't warrant a separate MySQL box at the moment.

The pipe should have capacity to spare too. I would request that anyone experiencing slow response do a traceroute to sammyboy.com and post the results here so we can track down the bottleneck.

Statements such as "Hey Sam Leong! Why SaMMYBOY.com is slow?" is of no help to me when it comes to troubleshooting. :confused:

That means SQL server is on the same machine as everything else.

If your load factor don't show very high, then can it be your hosting facility's network heavily shared? Can run some cron jobs to test speed via some speed testing site and log them, to see if you can discover anything clue.

If the network became too busy for users to reach your box, then load factor will also record low loads, while users KPKB about speed.


;)
 
... I would request that anyone experiencing slow response do a traceroute to sammyboy.com and post the results here so we can track down the bottleneck.

Statements such as "Hey Sam Leong! Why SaMMYBOY.com is slow?" is of no help to me when it comes to troubleshooting. :confused:
statements such as "I would request that anyone experiencing slow response do a traceroute to sammyboy.com and post the results here so we can track down the bottleneck." is useless wifout details on how 2 use traceroute ...


did 1 ... most timed out was found 2 occur @ atlas.cogentco.com ...
 
statements such as "I would request that anyone experiencing slow response do a traceroute to sammyboy.com and post the results here so we can track down the bottleneck." is useless wifout details on how 2 use traceroute ...

The internet is more than a decade and a half old.

EVERYONE should know how to do a traceroute and those that aren't sure of the details know that all they have to do a search of "traceroute" and the answer will appear before their very eyes. :rolleyes:

Here's what I just got from http://www.speedtest.com.sg/

Traceroute Result:

1 203.116.178.1 (203.116.178.1) 0.520 ms 0.406 ms 0.213 ms
2 203.117.190.73 (203.117.190.73) 0.815 ms 0.813 ms 1.344 ms
3 vlan911-an-cat6k-ts-2-rsm1.starhub.net.sg (203.118.5.4) 1.192 ms 1.538 ms 0.851 ms
4 anutsi10.starhub.net.sg (203.118.3.162) 3.783 ms 5.354 ms 5.750 ms
5 so-7-0-1.edge6.SanJose1.Level3.net (4.53.22.1) 222.842 ms 219.276 ms 218.929 ms
6 vlan89.csw3.SanJose1.Level3.net (4.68.18.190) 224.321 ms vlan79.csw2.SanJose1.Level3.net (4.68.18.126) 221.455 ms 214.964 ms
7 ae-64-64.ebr4.SanJose1.Level3.net (4.69.134.241) 220.003 ms ae-74-74.ebr4.SanJose1.Level3.net (4.69.134.245) 213.821 ms ae-84-84.ebr4.SanJose1.Level3.net (4.69.134.249) 213.306 ms
8 ae-2.ebr4.NewYork1.Level3.net (4.69.135.186) 282.099 ms 284.294 ms 288.384 ms
9 ae-94-94.csw4.NewYork1.Level3.net (4.69.134.126) 292.073 ms 287.316 ms 288.818 ms
10 ae-91-91.ebr1.NewYork1.Level3.net (4.69.134.77) 283.809 ms 283.030 ms 282.491 ms
11 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 298.690 ms 287.690 ms 288.712 ms
12 ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 300.627 ms 288.497 ms 291.325 ms
13 ae-33-89.car3.Washington1.Level3.net (4.68.17.133) 288.551 ms 288.545 ms 288.725 ms
14 HOSTICAN-LL.car3.Washington1.Level3.net (4.79.169.70) 281.388 ms 281.162 ms 279.363 ms
15 cdr2-sw.hostican.com (208.73.38.15) 281.860 ms 279.654 ms 282.135 ms
16 cdr2-241.hostican.com (208.79.202.26) 280.313 ms 279.979 ms 280.172 ms
Traceroute Completed.
 
This forum runs on a dedicated server. I have never seen the server load factor going beyond 1.5 even at peak hours. (5 is the red zone) The server has grunt to spare.

However, there are times when I might be doing maintenance in the background.. ie optimising or repairing tables, pruning threads, updating counters etc and these processes hog the CPU while they are running and slow down response for those using the forum.

If you see a database error message, it usually means one of more of the tables is corrupted and needs repair. It can also be caused when MySQL has crashed and needs restarting.

The forum is almost always extremely responsive from where I am. (no proxy required)

An hour ago, for about 2 hours, when I tried to log in as usual,- the site goes to www.ask.com, and preventing any attempt to log in. Now it has come back to normal. At first I thought it was my computer, but all other bookmarked sites on my PC functioned normally. FYI only.
 
You try posting and comparing the speed between 3in1kopitiam and sammyboy.com and tell me if you can find the speed difference?

Damn those hackers from Langley!
 
You try posting and comparing the speed between 3in1kopitiam and sammyboy.com and tell me if you can find the speed difference? ...
dat fella oredi said ur statements laidis no use la ...
 
Sam! How come your traceroute starts in Yangon?



The internet is more than a decade and a half old.

EVERYONE should know how to do a traceroute and those that aren't sure of the details know that all they have to do a search of "traceroute" and the answer will appear before their very eyes. :rolleyes:

Here's what I just got from http://www.speedtest.com.sg/

Traceroute Result:

1 203.116.178.1 (203.116.178.1) 0.520 ms 0.406 ms 0.213 ms
2 203.117.190.73 (203.117.190.73) 0.815 ms 0.813 ms 1.344 ms
3 vlan911-an-cat6k-ts-2-rsm1.starhub.net.sg (203.118.5.4) 1.192 ms 1.538 ms 0.851 ms
4 anutsi10.starhub.net.sg (203.118.3.162) 3.783 ms 5.354 ms 5.750 ms
5 so-7-0-1.edge6.SanJose1.Level3.net (4.53.22.1) 222.842 ms 219.276 ms 218.929 ms
6 vlan89.csw3.SanJose1.Level3.net (4.68.18.190) 224.321 ms vlan79.csw2.SanJose1.Level3.net (4.68.18.126) 221.455 ms 214.964 ms
7 ae-64-64.ebr4.SanJose1.Level3.net (4.69.134.241) 220.003 ms ae-74-74.ebr4.SanJose1.Level3.net (4.69.134.245) 213.821 ms ae-84-84.ebr4.SanJose1.Level3.net (4.69.134.249) 213.306 ms
8 ae-2.ebr4.NewYork1.Level3.net (4.69.135.186) 282.099 ms 284.294 ms 288.384 ms
9 ae-94-94.csw4.NewYork1.Level3.net (4.69.134.126) 292.073 ms 287.316 ms 288.818 ms
10 ae-91-91.ebr1.NewYork1.Level3.net (4.69.134.77) 283.809 ms 283.030 ms 282.491 ms
11 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 298.690 ms 287.690 ms 288.712 ms
12 ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 300.627 ms 288.497 ms 291.325 ms
13 ae-33-89.car3.Washington1.Level3.net (4.68.17.133) 288.551 ms 288.545 ms 288.725 ms
14 HOSTICAN-LL.car3.Washington1.Level3.net (4.79.169.70) 281.388 ms 281.162 ms 279.363 ms
15 cdr2-sw.hostican.com (208.73.38.15) 281.860 ms 279.654 ms 282.135 ms
16 cdr2-241.hostican.com (208.79.202.26) 280.313 ms 279.979 ms 280.172 ms
Traceroute Completed.
 
Back
Top