Re: Example of web application done right?
thumb_42_at_yahoo.com
Date: 02/17/04
- Next message: Paul Lalli: "Re: Reading & Posting Usenet News Messages"
- Previous message: Brian McCauley: "Re: open pipe vs signals causing problems ?"
- In reply to: Simon McCaughey: "Re: Example of web application done right?"
- Next in thread: Chris: "Re: Example of web application done right?"
- Reply: Chris: "Re: Example of web application done right?"
- Reply: Chris: "Re: Example of web application done right?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 17 Feb 2004 18:45:01 GMT
Simon McCaughey <simonmcc@nortelnetworks.com> wrote:
>
> <thumb_42@yahoo.com> wrote in message
> news:iySXb.43206$_44.39503@attbi_s52...
>
> <snip>
>
>> As far as the web front.. I would really not recommend perl for this
>
> What would you recommend? and what did you use?
We used perl, and regretted it for the web interface.
I might go with java servlets if I were to do it again, or try and find a
way to get PHP to do it. mod_perl wasn't very stable IMO.
> Did you manage without session data? or how did you handle this problem?
No.. the sessions were a constant struggle. Here is how it was supposed to
work (as I recall):
Session ID was a string that contained info about which machine it was on.
If Session ID is from another machine, fetch session across network
and make it local, use new session ID.
Our web server load balancing was done by DNS, and, thankfully most browsers
didn't rotate the IP, so we didn't have to copy the session across very often,
when we did, it usually worked but on occassion it dropped them on the
floor. :-(
I much perfer the way Apache + tomcat handle the problem, even if you use
perl to do the web interface, it's a technique that is worth looking at.
Basically the way they do it is the web server is like a proxy that forwards
the HTTP request to whoever is responsible for that that session ID. I
suppose we could have used this approach in our code as well but didn't
think of it then. :-)
It's kind of a matter of cost -vs- cost of failure type of problem. It's a
hassle, but not a complete outage because (ideally) the (current_users /
(number of servers - 1) ) are unaffected by it, and anyway, affected users
could restart their session. Considering most of your "heavy lifting" is
done on a backend server, taking a web server down is relatively rare anyway
so this isn't that huge of a concern. If you were a stock broker it might be
though. (in that case you should probably have dedicated servers that do
nothing but manage sessions)
The most important part of doing large-scale web applications (IMO) is
preparing for the maintenance issues, second is hardware failures. Ideally,
you can work it out so that any machine can be taken out with minimal
or no impact.
A big part of that was dynamic configuration, when you take a machine out or
add a new one in, all the other machines need to know about it. We "abused"
an LDAP server for this purpose. Using LDAP was overkill, but we could take
a backend out of the loop, wait for it to finish what it was doing then stop
it, perform an upgrade, start it, and tell the other machines about it
via LDAP. (repeat process foreach backend until everything is updated) This
was actually kind of cool because it meant we didn't have to login to each
machine to update it's config. :-)
By keeping as much logic as possible outside of the web space and on
back-end(s), most maintenance was handled 100% transparently.
Jamie
- Next message: Paul Lalli: "Re: Reading & Posting Usenet News Messages"
- Previous message: Brian McCauley: "Re: open pipe vs signals causing problems ?"
- In reply to: Simon McCaughey: "Re: Example of web application done right?"
- Next in thread: Chris: "Re: Example of web application done right?"
- Reply: Chris: "Re: Example of web application done right?"
- Reply: Chris: "Re: Example of web application done right?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|