World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
Kaj 19-May-2008 [2569] | Cool |
Oldes 19-May-2008 [2570] | If I have a proxy server made in Uniserve, what is the best way to join it with Cheyenne? |
Dockimbel 19-May-2008 [2571x2] | 1) Add you service in %UniServe/services/ 2) Edit %Cheyenne/cheyenne.r 3) Add in the 'set-cache block inside the %services/ section, the name of your service. 4) In 'do-cheyenne-app function : - find the line "do-cache %HTTPd.r" and add after that : "do-cache %your-service.r" - find the line "control/start/only 'task-master none" and add after that : "control/start/only 'your-service-name none" |
That way it will work both in source mode and encapped. | |
Oldes 19-May-2008 [2573] | I will try it.. thanks. |
Terry 19-May-2008 [2574] | How much time will you be spending on Cheyenne Doc? |
Dockimbel 19-May-2008 [2575] | Hard to answer, but as it's propably the most important software component for my company, quite a lot I guess. |
Oldes 19-May-2008 [2576x2] | And where I should add protocol? If I used to start the proxy using: uniserve/boot/with/no-loop [services [proxy-http] protocols [http]] |
I see... do-cache uniserve-path/protocols/HTTP.r | |
BrianH 19-May-2008 [2578] | On the web site linked above in the Chunk-encoding section: transferts -> transfers |
Oldes 19-May-2008 [2579] | With PHP I often use code like: <? if(something) { ?> normal HTML is here <? } else { ?> something else here <? } ?> Don't you miss some way to do such a conditions? And as I'm now writing RSP I found the RSP's <%%> tag much more difficult to write than PHP's <??> |
Graham 19-May-2008 [2580x2] | remap your keyboard?? |
or, remap your keyboard%% | |
Dockimbel 19-May-2008 [2582x2] | Typo fixed, thanks Brian. |
Same in RSP : <% either something [ %> normal HTML is here <% ][ %> something else here <% ] %> | |
Dockimbel 20-May-2008 [2584] | Just as a reminder for those currently using Cheyenne/RSP, you can add the DEBUG keyword in your webapp config section in %httpd.cfg to display a menu with useful debugging info. |
Will 21-May-2008 [2585x3] | impressed! 8) I finally gave another try at php support in cheyenne and after patching fastcgi.c as suggested it now works like a charm. If you are on os x and use macports, here is a way to patch and compile: sudo port install php5 +mysql5 +fastcgi sudo port uninstall php5 cd /opt/local/var/macports/distfiles/php5/ sudo tar -xjf php-5.2.6.tar.bz2 >> run patch below tar -cjf php-5.2.6.tar.bz2 php-5.2.6 sudo port install php5 +mysql5 +fastcgi checksum.skip=yes copy of Dockimbel's patch with path fixed for this example ;---- cut'n paste the following code in REBOL's console ---- patch-php: has [buffer pos][ target: %php-5.2.6/sapi/cgi/fastcgi.c if none? attempt [buffer: read target][ print "unable to find the file to patch!!" exit ] either parse buffer [ thru "int fcgi_accept_request(" to "if (req->fd >= 0) {" pos: to end ][ insert pos "^/^-^-^-^-break;^/^-^-^-^-" write target buffer print "patch applied." ][ print "failed to locate the line to patch!!" ] ] patch-php ;---- end of code ---- |
tar -cjf php-5.2.6.tar.bz2 php-5.2.6 should be: sudo tar -cjf php-5.2.6.tar.bz2 php-5.2.6 | |
just in case if you want to have macports php5 support mysql 5.1.x, install this before php5 and php5 will recognise and use it: sudo port install mysql5-devel +server | |
Terry 22-May-2008 [2588] | Is that just for Mac? I was having some problems with PC |
Will 22-May-2008 [2589x3] | the php source patch is needed only for non WIN platform |
btw, belcome back Terry? ;-) | |
I just installed drupal 6.2 in a snap on Cheyenne, I really love the cleaning they have done on the database structure. If only it was in rebol... | |
Dockimbel 22-May-2008 [2592] | Yep the patch is for non-Windows only. |
Pekr 22-May-2008 [2593] | OT: Will, do you find Drupal better than Jumla? I downloaded both, just haven't tried extensively yet .... from what I saw I found Joomla has nice interface :-) |
Will 22-May-2008 [2594] | Pekr, forget joomla, that is bloated stuff, drupal is elegant, has good community and good documentation. I like the cleaning they have done with the database structure in latest version. It looks to me they have so much reduced the code a good php/rebol coder could translate it in a week.. ;-) |
Pekr 22-May-2008 [2595] | It is just that I found Joomla much more user pleasant :-) |
Terry 22-May-2008 [2596x2] | Doc.. have you worked with Erlang? |
Will, I only come here to keep an eye on Doc's developments. And get sucked into the evolution group simply because I can't resist :) But I've actually found post Rebol life to be very productive. | |
Dockimbel 22-May-2008 [2598] | Erlang, no, I just looked at the language specs and a few examples, why ? |
Terry 22-May-2008 [2599x2] | It has some features that make it ideal for serving web pages, DB access etc... all the stuff that's right up your alley. |
Here's a Yaws (Erlang based daemon) vs Apache benchmark. http://www.sics.se/~joe/apachevsyaws.html Shows Yaws handling 80,000 parallell connections. | |
Dockimbel 22-May-2008 [2601] | This bench looks a little odd to me. First, how can Yaws supports 80,000 parallel connections when running on a single server (TCP/IP stack limit is at 65535 AFAIK) ? Second, the load is generated by sending request byte per byte with a delay of 10s between each bytes and getting in response a file of 1 byte...This isn't a web server real load test, it just compares the scalability of OS threads vs "soft threads". You don't need a benchmark to know which one scales better on a mono-CPU server, it's obvious. How Erlang handles multi-core CPU ? |
Terry 22-May-2008 [2602x2] | Im not that familiar with it.. just looked interesting. Amazon uses Erlang for their S3 and SimpleDB products Apaceh uses it for their CouchDB product. |
Although it is possible to take advantage of multi-core technology by running several applications processes in parallel, the real benefit would be for multi-threaded applications. The challenge then is to change single-threaded or sparsely threaded applications into multi-threaded and also to debug them. Erlang has unique properties for taking advantage of multi-core technology One of the fundamental properties of the Erlang language is built-in support for very light-weight processes, each with its own memory, and using explicit message passing for their communication. Because of this most applications written in Erlang are realized as a number of cooperating Erlang processes representing something in the problem domain of the application, for example active call sessions, connections or transactions. Typically this will result in many thousands of simultaneously executing processes in a heavily loaded application. The parallelism already present in most Erlang applications makes them ideal for taking advantage of multi-core technology, without there being any need to modify them. The only thing needed is an Erlang virtual machine (VM) which works in a multi-threaded way, and that is what we now are releasing in Erlang/OTP R11B. | |
Dockimbel 22-May-2008 [2604x2] | Yep, cooperative multitasking built-in. Maybe we'll get that in R4 ;-) |
Cheyenne, with its mono-thread full async engine, would scale very well on a similar benchmark, probably much better than Apache, but less than Yaws I guess. OTOH, a bench testing raw throughput, would show Apache performing quite better than Cheyenne (maybe 2 or 3 times better). It's hard for interpreted REBOL to compete with compiled C on raw power. I think that it would be possible to reduce this difference to 1.5 with deep optimization in Cheyenne (task scheduled for v1.1 according to my roadmap). R3 should open new perspectives for speed & memory optimizations (threading, clean async kernel, optimized ports, Rebcode, plugins...). | |
Gregg 22-May-2008 [2606x2] | Erlang has a lot going for it, but it has its own set of issues as well. Maarten recently spent some time evaluating it quite deeply for me. At this point, we're sticking with REBOL. |
It is *very* attractive, all the stuff you get basically for free, in the context of building distributed systems. | |
Will 22-May-2008 [2608] | Interesting Gregg, could you say more on what pros and cons made you take the decision? |
Graham 22-May-2008 [2609] | Where's the whitepaper? :) |
Terry 23-May-2008 [2610] | Never noticed this before.. seems someone was considering using Rebol as the GUI for Erlang http://erlbol.dougedmunds.com/ |
Pekr 23-May-2008 [2611] | Interesting :-) |
BrianH 23-May-2008 [2612] | Was? That's a new project :) |
Gregg 23-May-2008 [2613] | A good starting point for doc links is http://www.erlang.org/doc.html . The pros are that it's been around for a long time, it was built to solve a specific type of problem, and has been proven to work for large commercial systems. It also has a nice community it seems. Just as C# and VB.net are capable languages, you really need to know the .NET framework to make things sing. Erlang, by itself, is very capable, but the OTP (Open Telecom Platform) provides a huge amount of value on top of it, if you're building distributed systems. It also has Yaws, Ejabberd, and other things already built that you can leverage. On the downside, it's a very different model that takes some getting used to, though Maarten got up to speed for experimentation very quickly. If you're used to Prolog, that will help. It's also really only good for back end stuff, so we would still be doing front ends in something else, which wasn't the dealbreaker in our case. What turned us away was the security model. It's designed for use in an intranet type (read safe) environment, where access to machines on the cluster is controlled by secret cookie. If your cookie is compromised, they have absolute power over the node, and any nodes it shares that cookie with. http://www.erlang.org/doc/reference_manual/distributed.html#11.7 We decided that, since we would end up building security on top of everything, using something like dialects for control, we were better off sticking with REBOL. There are a number of things out there already to bulid on (LNS, Rugby, Uniserve, BEER), we can really do things the way we want, in a tool we know we like and are comfortable with. And we know its limitations, so there will be fewer surprises. |
Joe 28-May-2008 [2614] | Hi Gregg, which is the project you're talking about ? |
Joe 29-May-2008 [2615] | Doc, the 64K limit is the limit on the number of server ports but not the number of connections that can be open to a single port like port 80 |
Dockimbel 29-May-2008 [2616x2] | AFAIK, every client or server connections are taking a port number in the 64K range. Each time a server receives a new connection it assigns a local port number to the client connection. That local port number is in the 64K range because TCP (or UDP) header storage space for source or destination ports are only 16bits each. |
In theory, a combination of a client IP and a local port (in the 64k range) could make a unique key allowing to handle more than 64k clients, but I don't think that the big 3 OS are able to exploit such trick in their default configuration. | |
Maarten 29-May-2008 [2618] | There is a paper on Philip Wadler's site: http://homepages.inf.ed.ac.uk/wadler/documents/ServiceArchitectures.pdf Check footnote 32 on page 21 (chapter 13). That's what stopped us. |
older newer | first last |