PDA

View Full Version : FQuest Notice: IRM Trailing Slash Paradox solved


Terra
06-12-2000, 12:30 PM
Last night, all servers were updated with new IRM logic in an effort to (once and for all) solve the 'Trailing Slash Paradox'...

The problem is that *every* hit (not pageview) must go through the IRM logic regardless if it's destined for an IRM'd domain or not, hence the 5 IRM limit per domain...

I believe that I have found a suitable compromise between functionality and extra overhead [mainly stat()] involved with the extended parsing routines...[nbsp][nbsp]stat() is a very expensive syscall that is best avoided at all costs, which is why languages such as perl do their best to cache the results of stat(s) via the '_' mechanism...

The ending result is about as optimized as I can get it, resulting in a server friendly solution that should not exhibit any appreciable performance loss for domains with IRM's...

--
Terra
--Sometimes a brief moment of Inspiration can remove the most stubborn of thorns--
FutureQuest

<DISCLAIMER: This solution can be pulled at any time if it's found to have unforeseen problems or severe degradation of performance.>

Juan G
06-12-2000, 06:39 PM
Really, FQuest is doing always an astonishingly good work. This new feature seems to be working very fine. :)

On the other hand, I guess that probably cgi is more reliable with normal (non IRM) domains. Is this true? If I am not wrong, for domains which use cgi a lot, normal domains are better but, for other domains, IRMs are great.

Thank you very much for solving the IRM trailing slash problem. I think FQuest has a rating of 9.9 now, but only because my beliefs don't allow to give a 10 to humans. Excellent work! ;)[nbsp][nbsp]

[This message has been edited by Juan G (edited 06-12-00@6:56 pm)]

Monty
06-12-2000, 07:47 PM
I have seen no differences in performance of cgi within IRM's or &quot;outside&quot; of them, since both are the same cgi-bin.[nbsp][nbsp]The coding gets a little interesting, since you have to realize what it is you are doing, so paths and URL's take on entirely new meanings.[nbsp][nbsp]One of my busiest message boards resides at an IRM, and everyone who has ever been there has remarked at the speed of it.[nbsp][nbsp]We took just over 700K hits on these sites last month, without so much as a hiccup.

Thanks TeRRa for the kewl new hack, y'all are the best ;) , it's a 10.0 all the way for me.

Mont

Jeff
06-12-2000, 07:54 PM
Yes !!!

The IRM trailing slash problem was the *only* problem I had with FutureQuest -- and now it's solved!


Genius is both quantitive and qualitive and many times subjective...[nbsp][nbsp]But most of the time it's just plain luck... :þ

Well, I feel really great about hosting with a company with such excellent 'luck' (if you say it's luck...)!

Thanks once again for making my day!


[This message has been edited by Jeff (edited 06-13-00@11:18 pm)]

Justin
06-12-2000, 08:43 PM
...because my beliefs don't allow to give a 10 to humans. Who are you calling humans?

:P

------------------
Justin Nelson
FutureQuest (http://www.FutureQuest.net/index.php) Support

Juan G
06-12-2000, 10:13 PM
So, is Seven of Nine ( http://aota.net/ubb/Forum4/HTML/000368-2.html ) working at FQuest? :)

Seriously, it's easy to feel very happy to be here. Thank you as always for many things. :)

[This message has been edited by Juan G (edited 06-12-00@9:19 pm)]

John Kennett
06-13-2000, 05:35 AM
Thanks Terra!

John

hawkman
06-13-2000, 06:52 AM
Hello,

Have I understood this correctly that no trailing slash is needed? I e
www.irm.com/sub (http://www.irm.com/sub) does not show main domain error message, but show www.irm.com/sub/ (http://www.irm.com/sub/)? In that case I have some problems with my irms.

www.var-redo.nu/scoutsajten (http://www.var-redo.nu/scoutsajten) generates the error message of my main domain, 'cause www.webbolaget.com/scoutsajten (http://www.webbolaget.com/scoutsajten) does not exist...

Well, if I have misunderstood things I do appologize...

Yours
Hakan Ahlberg[nbsp]

Deb
06-13-2000, 07:11 AM
Hmmm, do you have any special files in place that would address &quot;scoutsajten&quot; specifically?

www.var-redo.nu/yaddayadda (http://www.var-redo.nu/yaddayadda)[nbsp][nbsp] (works as it should)
www.var-redo.nu/scoutsajt (http://www.var-redo.nu/scoutsajt)[nbsp][nbsp][nbsp][nbsp](works as it should)
www.var-redo.nu/scoutsajte (http://www.var-redo.nu/scoutsajte)[nbsp][nbsp] (works as it should)
www.var-redo.nu/scoutsajten (http://www.var-redo.nu/scoutsajten)[nbsp][nbsp](redirects to main site)
www.var-redo.nu/scoutsajtent (http://www.var-redo.nu/scoutsajtent) (works as it should)

This test leads me to believe that there is something else there that specifically address &quot;scoutsajten&quot; as all other variations work as they should and nothing at the server level would cause such a situation with that exact text...

Deb
[nbsp]- scoutsajten? Translate Swedish to English I'm curious ;)

hawkman
06-13-2000, 07:57 AM
Hello Deb,

Thanks for your fast answer! No I have no files that address &quot;scoutsajten&quot; directly. It's just a test directory. And if I create a directory called yaddayadda I get my 404...

As I have understood this fix should take care of users that type www.var-redo.nu/scoutsajten (http://www.var-redo.nu/scoutsajten) see to that they are seeing the contents of www.var-redo.nu/scoutsajten/ (http://www.var-redo.nu/scoutsajten/). Have I misunderstood this?

And now to the swedish lession :)
Var-redo! = Be Prepared! (and the domain .nu makes it even better since nu = now)

scoutsajten = scout - scout (of course! :) ) and sajten = the site.

Ha en bra dag = Have a nice day

:)

/Hakan

Terra
06-13-2000, 11:40 AM
I believe I've gotten everything patched up with the 'empty directory' handling...[nbsp][nbsp]It should now properly pass control to the DirectoryIndex layer...

Please run another set of tests and let me know if you find any further problems...

--
Terra
--step by step--
FutureQuest

BenV
06-14-2000, 01:42 AM
...and there was much rejoicing!!!

Thanks and I pray you won't have to ever pull it[nbsp][nbsp]:)

Terra
06-14-2000, 04:04 AM
Thanks and I pray you won't have to ever pull it
It already is in danger of extinction if we cannot solve the following post:
http://www.aota.net/ubb/Forum5/HTML/000726-1.html

We need some JavaScript gurus to go through his code with a fine tooth comb...

The main problem is that I *cannot* reproduce the problem with either IE5 or NetScape...[nbsp][nbsp]If he is experiencing the problem, then I'm sure others will follow with similar complaints turning into a real support@ nightmare chasing ghosts...

--
Terra
--Bam, Bam, Bam--
FutureQuest

pdstein
06-14-2000, 12:17 PM
My root domain is steinbrueck.org and ourchurch.com is an IRO.[nbsp][nbsp]I have had this annoying problem where a URL like http://www.ourchurch.com/member/a/Alliance-life will be automatically converted to http://www.steinbrueck.org/member/a/Alliance-life/

It still happens, so am I to assume that the IRM fix discussed in this thread does not apply?
[nbsp]

Justin
06-14-2000, 02:47 PM
Are you saying the images don't cache on FutureQuest.net (http://www.futurequest.net/)? They do (and always have) for me...

As for YourCompetitors.com/net, these are (I think) PHP pages, thus you would have the Last-Modified issue as explained earlier... There are no images on those two sites...

Otherwise, please explain what you are seeing at our sites that isn't normal behavior...

------------------
Justin Nelson
FutureQuest (http://www.FutureQuest.net/index.php) Support

mill_webs
06-14-2000, 04:02 PM
Justin, at the time I posted earlier futurequest.net was not caching properly in IE browsers... now it is fine. I still see the problem with YourCompetitors.com/net.
http://www.milleniumsys.com/prop.jpg
This is what I was getting for properties from my two websites, futurequest.net, etc. This is from yourcompetitors.com... I tested this with IE5, 5.01, and 4.0 and Communicator 4.7. IE4.0 showed 'Undefined' where this image shows 'Not Available'.
Hope this helps!
Robert

I think this is what we all need??? www.milleniumsys.com/missing_key.html (http://www.milleniumsys.com/missing_key.html)
[This message has been edited by mill_webs (edited 06-14-00@3:14 pm)]

Juan G
06-14-2000, 05:20 PM
It really seems that different browser versions (or sub-versions inside versions: 5.0...) show different things.

I've got an Explorer 5 on this computer, and it gives 06/14/2000 as date and 1855 bytes as size for http://www.yourcompetitors.com/ . Netscape shows the same size, but a different date, July 28, 1999. Very strange.

For http://www.yourcompetitors.net/ the data is 1067 bytes and again 06/14/2000 in my Explorer 5, and the same size but August 30, 1999 in Netscape Communicator.

Since there are different sub-releases of Explorer 5, other people can test the Properties (right button of the mouse), and maybe some of them have a version that loses data, as it happens to Robert's Explorer version.

For tests with Communicator, see menu View / Page Info, or right button (&quot;View Info&quot;).

A related info (given by Deb on this forum for this topic):

You may find the thread at http://www.aota.net/ubb/Forum3/HTML/000252-1.html very interesting as I believe it addresses the situation you are referring to.

Deb
- It's amazing how much longer a nanosecond is these days.
http://www.aota.net/ubb/Forum5/HTML/000726-1.html
An example from the second page of Deb's link:

Sue Fisher has already mentioned in one of her posts that the latest update to MSIE5 has improved (but not completely fixed) the Cache Management inefficiency found in MSIE5.
As Robert suspects, probably this is an Explorer issue.

[This message has been edited by Juan G (edited 06-14-00@4:30 pm)]

Juan G
06-14-2000, 05:47 PM
I've seen that for example Jeff has Internet Explorer 5.00.2314.1003, and I have IE 5.00.2919.6307. And the computers of other people surely give more variety. ;)
Who knows what patches and bug fixes are inside each computer...

[This message has been edited by Juan G (edited 06-14-00@4:49 pm)]

Dan Kaplan
06-15-2000, 01:44 AM
I have had this annoying problem[nbsp][nbsp]where a URL like http://www.ourchurch.com/member/a/Alliance-life will be automatically converted to http://www.steinbrueck.org/member/a/Alliance-life/ Isn't that normal behavior for anything not ending in a file extension?[nbsp][nbsp]Without the extension, it is treated just like a directory path, which is good because most people don't type the trailing slashes.

Dan
[This message has been edited by Dan Kaplan (edited 06-14-00@12:45 pm)]

mill_webs
06-15-2000, 01:52 AM
We need some JavaScript gurus to go through his code with a fine tooth comb...
Didn't mean to pull out the dogs, but I don't think it is only my code when I have noticed this same problem with FQ's main site and IRM examples www.YourCompetitors.com (http://www.YourCompetitors.com) and www.YourCompetitors.net (http://www.YourCompetitors.net) also noticed it in other FQ hosted websites with IRM's such as Craig Antill's www.titan.uk.com (http://www.titan.uk.com) which has the IRM's www.leisurebuildings.com (http://www.leisurebuildings.com) and www.timberbuildings.com (http://www.timberbuildings.com), which at the time of this post are still affected by this. It is not only JavaScript rollovers that are affected, but everything within non IRM directories that I have seen.

Respectfully,
Robert

Jeff
06-15-2000, 02:16 AM
I take it Terra found the solution to the cache issue?[nbsp][nbsp]I just revisited http://marinearchitecture.com/ads/ and the images there which before were exhibiting the problem are now caching fine with the same IE version I was running before in my prevoius post... and *best of all* the trailing slash Fix seems to still be in place so my IRM's work great![nbsp][nbsp]Excellent!
[This message has been edited by Jeff (edited 06-15-00@01:17 am)]

Chiessa
06-15-2000, 02:35 AM
About mill_webs' issue, I tested the URLs that he mentioned with IE5.0 and NC4.7.[nbsp][nbsp]I couldn't reproduce the errors he cited other than that IE5.0 always displayed file creation and modification dates as today (It wan't a FQ problem though since I got the same error with yahoo.com and micorsoft.com).

Also, I don't think his was a Javascript coding problem.[nbsp][nbsp]Javascript is quite limited in what it could do, and it's unlikely that it could affect the properties of a document.[nbsp][nbsp]Maybe the problems lie at mill_webs' end (e.g. are you connected through a proxy or something)?[nbsp][nbsp]Maybe he could test some websites outside FQ to see if he gets the same problem.[nbsp][nbsp]Just a suggestion.
[This message has been edited by Chiessa (edited 06-15-00@01:49 am)]