Fwd: Question: MacOS X Bundled Apache Server or Embeded Web Server?
Pierre Sahores
psahores at easynet.fr
Sat Aug 26 06:46:51 EDT 2006
Katir,
I forgot to precise, in the previous mail, that the tasks queued to
the Rev deamon is'nt managed by the Rev deamon it-self (Rev is not so
good in about this) but by Apache+PHP, so the Rev deamon always just
know about one task after the other and never twice at once. Because
Apache does this part of the job in multi-thread mode, the result is
for us that the global server-side process "Apache+PHP+Rev" works
just alike a 100% multiprocess system would do with just a small
difference : it works then time faster than the Tomcat, JBoss or
Websphere based solutions...
Best,
Pierre
Début du message réexpédié :
> De : Pierre Sahores <psahores at easynet.fr>
> Date : 26 août 2006 12:36:01 HAEC
> À : How to use Revolution <use-revolution at lists.runrev.com>
> Cc : Pierre Sahores <psahores at easynet.fr>, Sivakatirswami
> <katir at hindu.org>
> Objet : Rép : Question: MacOS X Bundled Apache Server or Embeded
> Web Server?
>
> Hello Katir,
>
> In theory such a process will block your framework for 10 seconds
> as you expect. In practice, there is, for sure, a way we can design
> the entiere "n-tier" process your are thinking about to have the
> blocking part of it on the client-side part of the solution (AJAX
> xmlhttprequest object calls if the client app is a webbrowser, Rev
> scripting if the client-side app is a Rev one), so you will never
> need to slow-up and breake your server-side queue of tasks. In this
> case, the fact that Rev is not multi-threaded will never be a
> problem because, even if some ones can doubt of this, J2SE deamon
> are running up to teen time slower than Rev deamons (Linux and OSX) :
>
> J2SE supports 3 threads max at once while Rev is queuing each task
> = 3 * 10 times unit for J2SE and, only, 3 * 1 times under a Rev
> server-side deamon to have the same quantity (and quality !) of
> queries served to the clients. As you can expect, even if Rev is
> not multi-threaded, the work will be well done by Rev because its
> ablity to speed-up the responses to the queue of requests...
>
> If you give me some more details about the process, you are
> thinking about, i'm sure we will be able to design the solution
> without having to manage synchronious blockings on the server-side.
>
> Kind Regards,
>
> Pierre
>
> Le 26 août 06 à 05:43, Sivakatirswami a écrit :
>
>> Pierre:
>>
>> If a single engine is running as a daemon, and, as we know,
>> Revolution is no multi-threaded and cannot fork a new process.
>> What happens if one of your CGI has a "wait 10 seconds" in it...
>> or a blocking call ? Doesn't this bring down the entire framework
>> for 10 seconds and all other attempts to use the engine are
>> blocked for 10 seconds?
>>
>> Sivakatirswami
>>
>>
>> Pierre Sahores wrote:
>>> Hi Andre,
>>>
>>> I'm bundeling MC/Rev client-server's applications to Apache since
>>> 1997 in using this kind of architecture. The client part of the
>>> process can be un standard web browser under the Win32, MacOS9/X
>>> or Linux platforms, a webbrowser+AJAX add-ones (XMLHTTPRequest
>>> objects) on the same platforms or MC/Rev client-side apps. All
>>> works very securely in real solutions solded to my customers
>>> (Education, Universities, Humans Ressources Management and
>>> Coaching).
>>>
>>> Perhaps could you have an eye on the basic tutorial i maintain on
>>> the subject at <http://istream.homeunix.com/insead/index_en.html>.
>>>
>>> Dont hesite to ask me more about the details ;-)
>>>
>>> Best Regards,
>>>
>>> Pierre
>>>
>>>
>>> Le 24 août 06 à 01:49, Andre Garzia a écrit :
>>>
>>>> Hi Folks,
>>>>
>>>> I am building my soon to be released web application development
>>>> thingy. I am bundling all my libraries (and some third party
>>>> with credits), docs and example.
>>>>
>>>> But since I talked with Dan and others during RevConWest, I
>>>> decided that the most important part of this package is the out-
>>>> of-the-box experience. The hardest thing about CGI and WebApps
>>>> for rev users is usually setting up the environment. The idea is
>>>> to develop locally and then deploy when ready. I can't really
>>>> build this for Windows, I expect help on that later. So the idea
>>>> is that there's a home stack that sets everything up.
>>>>
>>>> Till today I was bundling the LiteSpeed Web Server <http://
>>>> www.litespeedtech.com> server with the package. The server would
>>>> be all set up out of the box so that you could just launch and
>>>> play. The problem is, the thing is not running CGIs, the plain
>>>> old ones... they run once, then the server deadlocks. ARGH!!!! I
>>>> thought about using cherokee web server <http://www.0x50.org/>
>>>> but then, it comes out in source form and when it compiles it
>>>> hard code some paths for the dynamic loading libraries, so you
>>>> cannot really build it and then just bundle. You must compile it
>>>> for each installation. Thats the same trouble with Lighttp
>>>> <http://www.lighttpd.net/>, and building it with static options
>>>> makes a huge server like 158mb and still it hard code the paths.
>>>>
>>>> The MacOS X Apache server is not ready for FastCGI, for that we
>>>> need to install the modules, which is easy. Actually thats not
>>>> hard, simple commands and a revolution made stack could drive
>>>> that installation easy. But again MacOS X out-of-the-box lacks
>>>> the needed C compiler for that, only those that installed XCode
>>>> development tools have the needed stuff to build Apache Modules.
>>>>
>>>> So here I am. The little servers all have some trouble or
>>>> another, the MacOS X bundled one is fine, but again, you need to
>>>> download 1GB XCode tools just to build simple couple megs apache
>>>> module...
>>>>
>>>> any clue out there folks? is there any autoconf magician here
>>>> that can build a lighttp install with relative paths instead of
>>>> absolute ones (I tried and it didn't like).
>>>>
>>>> Can we use otool to rewrite the linkers absolute path using a
>>>> relative one like we do for frameworks (using @executable_path).
>>>>
>>>> Argh, I am looking for help.
>>>>
>>>> Andre
>>>> _______________________________________________
>>>> use-revolution mailing list
>>>> use-revolution at lists.runrev.com
>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>>
>>>
>>> --
>>> Pierre Sahores
>>> www.sahores-conseil.com
>>>
>>>
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
> --
> Pierre Sahores
> www.sahores-conseil.com
>
>
>
--
Pierre Sahores
www.sahores-conseil.com
More information about the use-livecode
mailing list