MultiThreading? Javascript problems...
 

First let me begin by saying I know zip-zero-zilch about Linux (or unix).

I have a nice javascript I wrote on my PC that runs very smoothly when viewed from localhost. I've put it on other servers and it runs smoothly as well. I put it on the server I wrote it for, a Linux RedHat, and it crawls, taking up 50% of the CPU for a web-browser to view the page.

I thought it was a javascript problem, but when I asked for help, this is the reply I received on the problem:

Honestly, that's greek to me, I don't know what any of that means. I'm just a programmer. I could have sworn that javascript worked via the browser, not the server (meaning it should run even when I disconnect my network cable). But I looked up some stuff here:

http://stackoverflow.com/questions/1...-red-hat-linux

http://www.acme.com/software/http_load/

etc, and seems there's a problem with RedHat and single-threads? Does this sound right to the experts on here? I need to write to the Tech group that controls the RedHat machine, if it is true, and have them fix it. But, need to know what to say to them, since, unless you give them very specific instructions, they tend to reply with a blank-stare and a not-our-problem attitude (otherwise I know they're just going to say it's the javascript, not their RedHat, which is the most perfect OS ever, that's the problem).

Can anyone help?

I assume you have tried different browsers on your side? This type of behaviour (a crawling local browser) usually has nothing to do with the server. For example, I've been on many webpages which really crawl in Linux FireFox (it pops up the "a script on this page is blocking / freezing firefox" dialog) but in Windows FireFox they run just fine.

Unless your javascript contacts the server itself (with AJAX type calls) it runs ONLY in the browser - the server has no effect on its execution, except to deliver it to the browser when the page is viewed. UNLESS it then goes off by itself and again calls the server.

Here's an analogy - it is like having an eight-cylinder car engine. Let's say your client environment is the rocker arm, moved by the cylinder. That rocker arm is constrained to be pushed up and down only by one cylinder - it cannot be moved by the force of two, or four cylinders in adjacent engine chambers. What the statement means (IMO) is that, at script level, your script CANNOT spawn new threads, because the owning process / thread is limited to only one line of execution. I. e. anything that thread does must be done serially (one after the other) - it cannot "branch off" (called "forking) new processes or spawn new threads.

This is not universal, it depends on how the system is set up and how the controlling process is written, and / or how the hosting server is set up. But that does sound strange, forking is usually trivial to do, I think?

Doubtful - all that "Red Hat" means is that the standard Linux kernel of whatever version has been wrapped in an installer and a certain set of Open Source software (called a "Red Hat distribution"), and given to you or made available on a DVD or as a download. A Suse / Debian / Ubuntu "Linux" is in fact just again the same standard Linux kernel of whatever version, wrapped in an installer and with a certain set of Open Source software. Red Hat definitely is not limited to single threads / processes. The problem you refer might actually mean that the application environment you are running in, IS limited to a single thread, and has been created as incapable of spawning new threads or forking new processes (this is completely possible, but it is not something "Red Hat" enforces) - it is how the application was written.

I doubt this is something your server people can assist you with. Have you tried your script in other browsers? What does Konqueror do with the site / page you are having problems with? If you can get on a Windows system, what does Chrome or Windows FireFox do? I think you might find the problem changes or even disappears entirely - which indicates (as it should) that the problem is BROWSER centered, not server centered.

Again, unless your Javascript does something where it deliberately interacts with the server, like repeated AJAX calls through spawned HTTP objects. In that case, the server CAN have a direct impact on a Javascript script's performance "in browser".

Teeheehee! I know the type. I think you are barking up the wrong tree though - I've had problems like this, and it has never been due to the server - usually the local browser version or type. Determining this is easy - try different browsers on Linux and Windows - I'm willing to bet you'll find that the problem goes away or at least changes as you change browser software.

Yes, I tried Firefox and Internet Explorer. Both browsers have the same problem. I put the page on one server, such as http://i-sphynx.com/dev/ and it works fine in both browsers. I put it on the linux server, and my task-manager says my browsers are taking up 50% CPU and the images crawl at 1/20th the speed. I've tried on 4 different servers, re-FTP'd the files in case there was corruption or something, and it only crawls on the RedHat machine.


That was my understanding as well, after all, I did disconnect my network cable and it still crawled at 50% cpu...

But if it's not the OS (which from a logic point-of-view, seems improbable), and not browser based (which, since it only crawls from the RedHat server, makes sense), what else is there? o.O

Ouch... ok, what exactly does your script do, or what is it supposed to do?

How does it do what it does?

Maybe if you post some more info, some real guru could help as well. (I'm just a wannabee!)

http://i-sphynx.com/dev/

That's a working, non cpu-intensive server, copy of the page that locks up all browsers when placed on the RedHat server.

Any other info that you may need, you'd probably have to tell me how to get since it would be about the linux-setup I think.

Ok, I'm not sure how/why, but I have one further piece of the puzzle....

if I go to the www.<domainname>.com site, no CPU usage....
if I go to the <domainname>.com site, the CPU sky-rockets.

I guess this means it could have something to do with the stream, with the dmz, the firewall? I'll need to redirect anyone that comes in to the <domainname>.com site towards the www.<domainname>.com site as a 'fix', but I'm still very curious as to what the actual problem is... o.O

Well, nicely done script! The URL you sent works just fine here.

Construction worker porn... ;)

If that solves your problem, sure, it seems like a legitimate solution - albeit illogical, but then, the problem itself is illogical. It might somehow be a DNS issue as well, are you sure www.domainname.com and domainname.com resolve to the exact same address?