From: Alexander W. <th...@sp...> - 2005-04-21 11:28:04
|
erlyaws-list: If you folk read the main Erlang help list, you might have noticed I asked there about mysql module replacements/enhancements. (While the suggestion to use odbc was intriguing, I really would prefer/need an all Erlang solution.) But this isn't about that. I was going through the mysql module code and noticed that the fetches were being issued, reasonably, with the Pid of the calling process being sent along to reply. Seemed reasonable to me; I assumed that each yaws page reload should be getting a new pid, and my mingling of responses was some other glitch. Then I thought about what happens when you make assumptions. Then I ran some tests. On my installation of Yaws (latest release, Erlang 10-4), the Pid of the calling page render process flips back and forth between two different Pids. That's it. No /wonder/ the send is coming back confused and out of sync sometimes. Its expecting the Pid to be a relatively unique entity, and it instead is bipolar! So, here's the question: Is this a problem with my config, an intrinsic "feature" of Yaws, or a glitch in the mysql assumptions? Given my druthers, I'd /rather/ have the page requests be semi-unique (long-cycle, random in a large keyspace, whatever) to facilitate just such response patterns. Worst case I can just have the .yaws code spawn a process to do the mysql interrogation, which should reintroduce the proximate uniqueness of the Pid for the duration of the call need, but it seems vaguely awkward. Thoughts? -- Alexander Williams (th...@sp...) The Squid's Redoubt: http//chancel.org:8000/Redoubt Currently Playing: Robert Lopez and Jeff Marx - If You Were Gay Album: Avenue Q (Original Broadway Cast Recording) |
From: Torbjorn T. <to...@no...> - 2005-04-21 11:45:45
|
Well, the MySQL protocol is a bugger of a protocol. I recomend that you create a gen_server that deals with the MySQL interaction. Then you provide an atomic (gen_server:call) interface to that server, that the rest of your system uses. This way, you won't get any mixup of mysql messages. On the other hand your server may become a bottle neck (eventhough I doubt that). Cheers, Tobbe Alexander Williams wrote: >erlyaws-list: > > If you folk read the main Erlang help list, you might have noticed I > asked there about mysql module replacements/enhancements. (While the > suggestion to use odbc was intriguing, I really would prefer/need an > all Erlang solution.) > > But this isn't about that. > > I was going through the mysql module code and noticed that the > fetches were being issued, reasonably, with the Pid of the calling > process being sent along to reply. Seemed reasonable to me; I > assumed that each yaws page reload should be getting a new pid, and > my mingling of responses was some other glitch. > > Then I thought about what happens when you make assumptions. Then I > ran some tests. > > On my installation of Yaws (latest release, Erlang 10-4), the Pid of > the calling page render process flips back and forth between two > different Pids. That's it. > > No /wonder/ the send is coming back confused and out of sync > sometimes. Its expecting the Pid to be a relatively unique entity, > and it instead is bipolar! > > So, here's the question: Is this a problem with my config, an > intrinsic "feature" of Yaws, or a glitch in the mysql assumptions? > Given my druthers, I'd /rather/ have the page requests be > semi-unique (long-cycle, random in a large keyspace, whatever) to > facilitate just such response patterns. > > Worst case I can just have the .yaws code spawn a process to do the > mysql interrogation, which should reintroduce the proximate > uniqueness of the Pid for the duration of the call need, but it > seems vaguely awkward. > > Thoughts? > > > |
From: Alexander W. <th...@sp...> - 2005-04-21 12:01:50
|
Torbjorn: Thursday, April 21, 2005, 7:45:51 AM: TT> Well, the MySQL protocol is a bugger of a protocol. TT> I recomend that you create a gen_server that deals with the MySQL TT> interaction. Then you provide an atomic (gen_server:call) TT> interface to that server, that the rest of your system uses. This TT> way, you won't get any mixup of mysql messages. On the other hand TT> your server may become a bottle neck (eventhough I doubt that). The only problem with that is that, well, its a heck of a lot of work for fairly little pay-off, considering I'm trying to make the Yaws code on these pages as straight-forward as possible. It seems to me that the Pid is a reasonable assumption of self-identification, as the page delivery process can't actually complete until the process has completed working with that particular port. Hmmm, which makes me think that I might can get out of the worst of it by simply increasing the timeout before the receive on the fetch call returns a none (leaving the slow-to-return query send hanging out in hyperspace). I'm not particularly concerned about milking the absolute tightest response possible out of the server, so I may simply start with extending that timeout and seeing if fewer pages come back confused. -- Alexander Williams (th...@sp...) The Squid's Redoubt: http//chancel.org:8000/Redoubt Currently Playing: Stan Ridgway - Goin' Southbound Album: LIVE! BEYOND TOMORROW! 1990 @ The Coach House, CA. |
From: Torbjorn T. <to...@no...> - 2005-04-21 12:17:11
|
Alexander Williams wrote: >Torbjorn: > >Thursday, April 21, 2005, 7:45:51 AM: > >TT> Well, the MySQL protocol is a bugger of a protocol. > >TT> I recomend that you create a gen_server that deals with the MySQL >TT> interaction. Then you provide an atomic (gen_server:call) >TT> interface to that server, that the rest of your system uses. This >TT> way, you won't get any mixup of mysql messages. On the other hand >TT> your server may become a bottle neck (eventhough I doubt that). > > The only problem with that is that, well, its a heck of a lot of > work for fairly little pay-off, considering I'm trying to make the > Yaws code on these pages as straight-forward as possible. > > Nah...it's not that much work. I have put some code for you to have a look at here: http://www.trapexit.org/download You'll find the server in chat_srv.erl. Check out how it is setting up communication in the init function, and how it performs the authentication in the new_session call. Note also how you can get the configuration data from the /etc/yaws.conf file (see the init function again). The /etc/yaws.conf may look something like: <server www.trapexit.org> port = 80 listen = 0.0.0.0 docroot = /home/yaws/www dir_listings = true partial_post_size = 1024 start_mod = chat_srv <opaque> echat_port = 4567 chat_auth_method = phpbb chat_phpbb_ip = 127.0.0.1 chat_phpbb_user = root chat_phpbb_passwd = ********* </opaque> </server> The start_mod parameter will cause Yaws to start the server. The various server specific parmeters are located in the opaque part. You will also find an informal description of the MySql protocol in the html file. Cheers, Tobbe > It seems to me that the Pid is a reasonable assumption of > self-identification, as the page delivery process can't actually > complete until the process has completed working with that > particular port. > > Hmmm, which makes me think that I might can get out of the worst of > it by simply increasing the timeout before the receive on the fetch > call returns a none (leaving the slow-to-return query send hanging > out in hyperspace). I'm not particularly concerned about milking the > absolute tightest response possible out of the server, so I may > simply start with extending that timeout and seeing if fewer pages > come back confused. > > > |
From: Claes W. <kl...@gm...> - 2005-04-25 14:33:57
|
Hi, Yes, the Pid of the "yaws page" is not a very unique entity. If you take a look at the bottom of: http://yaws.hyber.org/internals.yaws The worker processes that are used to ship ".yaws" pages get spawned=20 by the gserv() process. These Pids get "reused". Thus when a page is done with, the pid doesn't necessarily die, but enter a wait state waiting for another "job". This is a performance enhancer which shouldn't usually interfer badly=20 with user code.=20 The alternative to "reusing" the same process would obviously be to terminate the worker process. I don't know much about mysql, nor the protocol to talk to mysql but it certainly is a highly interesting technology to use for Yaws. It might be a good idea to serialize all requests through a=20 server .. .what do I know. /klacke |
From: Carsten S. <ca...@co...> - 2005-04-26 23:29:21
|
Hi! On Mon, Apr 25, 2005 at 04:33:36PM +0200, Claes Wikstrom wrote: > The worker processes that are used to ship ".yaws" pages get spawned > by the gserv() process. These Pids get "reused". Thus when a page is done > with, the pid doesn't necessarily die, but enter a wait state waiting for > another "job". > This is a performance enhancer which shouldn't usually interfer badly > with user code. Have there been tests how much this enhances performance? As a result of buggy yaws code it might happen that stream data is sent not in the answer to the request it was meant for, but to the next request. If server processes are reused, this might mean sending data to the wrong client. Greetings, Carsten -- Carsten Schultz (2:38, 33:47) http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. |