(sending again to CC the list) Hi David,
The complexity of the Rails setup is one of the things that have drawn me to Yaws. Just installing Rails on my MacBook felt like too laborious of a process. And it felt like Rails has too many moving parts and dependencies. I don't like how in Rails (and LAMP) sharing session data between processes requires using the disc, the db or memcached. It seems like the "shared nothing" approach is a good architectural choice only because poor support for concurrency makes "share as much as you want" infeasible. However, there is a very good reason to share stuff from a scalability standpoint: db connection pooling. If your processes can't share db connections you can't spawn to many of them before your db hits its connection limit. This is why NYTimes resorted to creating DBSlayer -- they wanted to scale DB connections independently of web server processes. With Erlang, connection pooling and shared state is handled elegantly using concurrency and Mnesia. AFAIK, Twitter ran into problems earlier because Rails support just 1 db per app. They overcame these issues when people figured out how to make Rails connect to multiple dbs (but without proper connection pooling) I wouldn't be surprised if they are hitting more scalability problems now. You can only have so many Rails processes connecting to your db before it dies. The answer I found for this issue was "your processes will need to talk to the db anyway, so you may as well keep those connections open" but that's ignoring that in many websites over 90% of responses can be served from a cache (I read that Facebook has a 97% cache hit rate), so keeping a DB connections open for every process is wasteful and not very scalable. I think that Rails is great for being a clean, integrated MVC framework that emphasizes rapid development and good coding practices. The AJAX stuff is cool, but I prefer doing AJAX in Javascript rather than in the backend language (a Django developer once said, "why use a wheelchair if you can walk?" :) ). However, I would want to use Rails for high-traffic sites. I think that Ruby's poor support for concurrency is too limiting. Yariv On Nov 15, 2007 12:01 PM, David Mitchell <[EMAIL PROTECTED]> wrote: > G'day Yariv, > > I agree - I fully expect ErlyWeb to give better performance on any > given hardware than Rails. You're right - Rails can't do anything > with session state info except store it to disc or cache. > > Using memcached with Rails is something of a black art - while you can > definitely obtain higher throughput by using memcached, it's very hard > to track down definitive information on how to use Rails and memcached > together in any sort of structured/optimal manner - I'm pretty sure > people are doing it and achieving substantial improvements, but > there's a considerable lack of "howto" information about the topic > that could be applied in a generic fashion to any given Web site. > Also, it adds yet another piece to the whole Rails + Ruby + Mongrel + > Apache/nginx/lighttpd + (various gems) + MySQL/Postgres/Oracle + ... > list of components; it's already at the point where it's difficult to > get your head around all these pieces and how they interact, and > adding memcached to the mix adds yet another layer of complexity. > I'll happily admit that, at this point, I know just enough about > memcached to be able to track down the documentation... > > Interestingly, I found out yesterday that http://www.twitter.com is > Rails-based; I've been using Twitter for a while, and they seem to be > hitting scalability problems at present and having trouble getting > them resolved. Maybe they've reached a point where the Rails' "shared > nothing" approach has hit some sort of scalability limit that will > require significant $$$ to resolve. > > Don't get me wrong - I still love Rails and the improvements it's > brought to Web development as a whole. It's demonstrated that there's > life after PHP (ugh!) for small-to-medium sized apps, and the AJAX > integration is absolutely first rate. It's just that I can see that > it's going to be costly for high-traffic sites unless/until they > address threading issues in Rails itself, and that doesn't appear > likely to happen in the short term. > > Great news about your deciding to look at adding support for Web > services to ErlyWeb - thanks in advance for taking this on. > Personally, my priorities would be support for SOAP and REST/XML (and > possibly XML-RPC) first, followed by REST/JSON and then anything else. > SOAP is the big one, since enterprise-type WebSphere and .NET > developers generally seem to talk SOAP first and foremost, and > REST/XML would be their second choice; in general, my experience is > that JSON hasn't really gotten a solid mindshare with this group yet. > > Thanks again and regards > > Dave M. > > > > > On 15/11/2007, Yariv Sadan <[EMAIL PROTECTED]> wrote: > > Hi Dave, > > > > Thanks for sharing your point of view about web service support in > > ErlyWeb. I definitely see the value there for users. I haven't done > > any benchmarking comparing ErlyWeb and Rails, but from what I've heard > > ErlyWeb is likely to give you much better performance and to be able > > to scale to much higher numbers of concurrent requests without dying. > > > > (Another reason I think ErlyWeb can give you better performance than > > Rails for stateful services is that Rails processes don't share > > memory. If you have some session state, Rails AFAIK forces you to > > store it on disc, in the DB or in an external cache such as memcached. > > In Erlang, your processes can share state in Mnesia, which runs in the > > same VM and works transparently even when you add more machines to > > your cluster.) > > > > I'll look into adding support for web services to ErlyWeb. I'll have > > to do some reading on ActionWebService and see what it provides. Were > > you looking for specific protocols, e.g. REST/XML, REST/JSON, SOAP, > > etc (or all of them)? > > > > Regards, > > Yariv > > > > On Nov 14, 2007 2:29 AM, David Mitchell <[EMAIL PROTECTED]> wrote: > > > G'day Yariv, > > > > > > Thanks for responding. > > > > > > Nobody's requested a Web service interface for ErlyWeb? How could > > > that be? Don't we all live in a Web services world these days? 8-> > > > > > > I'm looking at ErlyWeb as a potential replacement for what I'm > > > currently doing with Rails. Unlike (apparently) a lot of people, I > > > use Rails as much for the Web services interface as the HTML > > > interface; it's by far the fastest way I've found to put a Web > > > services "face" on either existing functionality (using Ruby as the > > > "glue" to access the existing interface, which might be something like > > > a mainframe transaction accessible via MQ) or to expose interfaces to > > > code for testing purposes. > > > > > > In this second case, frequently it comes about that a developer will > > > want to do some early lifecycle testing of a block of code; if I wrap > > > that functionality in a Web service, that allows me to do some > > > testing, then the developer may go away and recode that functionality > > > and I'd retest it via the same interface. As long as the interface > > > doesn't change, the (Rails) Web service doesn't need to change. This > > > approach works well for performance testing all sorts of "stuff"; > > > changing indexes and/or stored procedures for database access and > > > testing whether performance improves, is one example that comes up > > > quite regularly. The Rails Web service code is basically throwaway > > > code; it gets used for some rapid opportunistic testing, then thrown > > > away once that testing is complete and we roll on to the next piece of > > > work. > > > > > > In addition to those sort of esoteric uses, pretty much every bit of > > > development work that I do needs to have a Web services interface - > > > maybe I'm unique in that respect, but I kind of doubt it given that I > > > work primarily for large companies and they're all looking for some > > > sort of SOA-type solution with every new piece of work they do. To > > > get Rails (and ErlyWeb, for that matter) into big companies, you've > > > really got to be able to push the Web services facet. As I said, I > > > find it strange that other Rails users aren't all over > > > ActiveWebService, since it makes a task that's generally pretty long > > > and painful (in other languages/frameworks) into a much simpler, more > > > enjoyable task. > > > > > > As you're probably aware, the big problem with Rails is the lack of > > > threading and the consequent cost of scalability - it's possible to > > > create a Rails solution that can service many simultaneous users, but > > > it's generally expensive to do so. At an average of ~250-300Mb per > > > Mongrel instance, you're pretty much limited to about 6 Mongrels per > > > server on a box with 2Gb RAM; if you've got any transaction that takes > > > more than a few hundred milliseconds, you hit the limits of the > > > architecture pretty quickly. Adding more boxes lets you get around > > > that, but then you have to factor in the cost of the servers plus the > > > incremental cost of maintaining them - pretty soon, your "quick and > > > dirty" Rails solution is also an expensive one. > > > > > > As an example, last year I hit a situation where I had to provide an > > > interface to 1000+ log files across ~100 Linux servers for a very > > > large application. Performance wasn't an issue, so I used Rails to > > > build it. I had a Ruby script that created one thread per server, > > > connected to each server, grabbed log file information and brought it > > > back to the Rails server; as you can imagine, it took some time (many > > > seconds) to execute. Rails was great for building this and actually > > > getting it working quickly, but because each request took so long to > > > service, I had to have loads of Mongrel processes running so that > > > (potentially) many people could use it simultaneously. We put in > > > various workarounds to address this (e.g. store the log data > > > centrally, then when someone requests it via the Web interface, only > > > retrieve it if it was too old; have another process that "trickle > > > polled" blocks of servers regularly to grab info on a regular basis, > > > etc.), but these workarounds were only required to work around the > > > lack of scalability in Rails. > > > > > > ErlyWeb looks like (for me) a potentially better solution. I really > > > liked working through the tutorials that are out there; I could see > > > that, given time, I could probably be similarly productive with > > > ErlyWeb compared with how I currently am with Rails. Erlang's > > > inherent concurrency, scalability and OTP mechanisms directly speak to > > > concerns I have with Rails. The connectivity via Erlangs ports means > > > I could even continue to use Ruby as a "glue" language where > > > appropriate (and Ruby is particularly good for that purpose), and > > > expose that Ruby functionality via ErlyWeb without getting the > > > scalability cost of introducing Rails. > > > > > > Right now, I'm working on a proof-of-concept test harness that will > > > let me drive a stockbroker customer's key mainframe systems through > > > every possible interface (e.g. direct TCP/IP access, MQ, CICS > > > Transaction Gateway, Web services, ...) and thus allow them to > > > establish the limits of their existing architecture. For a number of > > > reasons, Erlang will be a good fit for their requirements, and I've > > > put together an initial mechanism to test a few mainframe transactions > > > via different interfaces that looks very promising. To control the > > > "load generation" bit of the solution, I plan to use HP's LoadRunner > > > product, which the customer already owns; I'd like it to drive the > > > Erlang "generator" via Web services, which is a good fit for > > > LoadRunner and their existing skill set. However, I need to expose > > > the functionality within my Erlang code as Web services, which is > > > where ErlyWeb comes in - I'd really like a simple mechanism within > > > ErlyWeb that I could "bolt on" to my existing Erlang code, which would > > > let me expose the functionality as a collection of Web services. With > > > Rails, this sort of thing would be a couple of hours work at most; > > > with Erlang/Yaws, it looks somewhat more complex and time consuming, > > > and the "standard" Erlsom/Yaws solution doesn't look particularly > > > friendly or easy to maintain. ErlyWeb looks like a potentially good > > > solution, in that it gives a Rails-like simplicity and productivity > > > for Erlang Web development; what's missing (for this specific need) is > > > something equivalent to ActiveWebServices. For this particular > > > application, I could probably expose the necessary functionality via > > > HTML Web pages rather than Web services; it's just that Web services > > > is a more elegant way of going about it. > > > > > > Does that response answer your question? Sorry if it's a bit long > > > winded, but I figure it's better to give you too much info than too > > > little... > > > > > > Thanks and regards > > > > > > Dave M. > > > > > > > > > On 14/11/2007, Yariv Sadan <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Dave, > > > > > > > > Thanks for the feedback. The main reason ErlyWeb doesn't have an > > > > ActionWebService equivalent is that nobody until now has expressed a > > > > need for it. (Btw, I usually refrain from implementing features just > > > > because other frameworks have them -- I like to avoid bload so I only > > > > add features that I need or that other people ask for and/or volunteer > > > > to contribute.) What kind of support do you want to see for web > > > > services in ErlyWeb? > > > > > > > > Yariv > > > > > > > > > > > > > > > > On Nov 13, 2007 2:59 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Hello group, > > > > > > > > > > One of the weaknesses of ErlyWeb from my perspective is the lack of a > > > > > Web services framework. With Erlang's focus on concurrency and > > > > > Erlyweb's focus on making Erlang/Web development as easy as PHP etc., > > > > > this seems a surprising omission (at least, I *think* it's an > > > > > omission; maybe it's there and I just haven't picked up on the fact). > > > > > > > > > > Probably the best point of comparison is Ruby on Rails (RoR). RoR has > > > > > had a Web services framework (ActiveWebService) from the beginning; > > > > > while it doesn't seem to have been that popular, it makes it > > > > > incredibly easy to expose functionality as Web services. > > > > > > > > > > For the types of apps I generally work on, this is just golden; it > > > > > makes RoR a strong contender as the toolset of choice where otherwise > > > > > it wouldn't even be considered as an option. > > > > > > > > > > I'm aware that it's possible to use Yaws+erlsom, but it has a few > > > > > weaknesses: > > > > > - erlsom's install relies on sh; it doesn't install on Ubuntu without > > > > > a bit of mucking around, and must be a challenge for Windows as well > > > > > - setting up a Web service is a non-trivial exercise; just read > > > > > through the relevant page (http://yaws.hyber.org/soap_intro.yaws) at > > > > > the Yaws site > > > > > > > > > > Regards > > > > > > > > > > Dave M. > > > > > > > > > > On Nov 12, 6:04 am, "Yariv Sadan" <[EMAIL PROTECTED]> wrote: > > > > > > Mojo, > > > > > > > > > > > > if you're building a simple CRUD app, you can build it in pretty > > > > > > much > > > > > > any language with similar effort and results. ErlyWeb's goal is to > > > > > > make building webapps in Erlang as easy as in Ruby/Python/PHP/etc > > > > > > and > > > > > > I think it achieves it pretty well. AFAIK, Erlang will give you > > > > > > better > > > > > > performance than the popular scripting languages, but you'll have to > > > > > > benchmark it and decide how much it matters to you. > > > > > > > > > > > > If your app's backend is more complex than a few web servers that > > > > > > talk > > > > > > to a single database server, Erlang can help you even more. If to > > > > > > respond to a request, you need to do multiple things concurrently or > > > > > > do some distributed computation, or fire off background processes > > > > > > for > > > > > > asynchronous tasks, Erlang is the best choice by a long shot. Erlang > > > > > > is much better than other languages for Comet apps that maintain > > > > > > persistent connections to the clients (I'm sure you've seen the > > > > > > apache-vs-yaws graph :) ). > > > > > > > > > > > > For more common needs, Erlang/ErlyWeb also has better support for > > > > > > sharing session state (using Mnesia) and transaction-aware multi-db > > > > > > connection pooling (using lightweight processes + messaging) than > > > > > > other languages. > > > > > > > > > > > > Erlang/ErlyWeb is great for highly available applications (and for > > > > > > interactive and highly productive development) due to its support > > > > > > for > > > > > > hot code swapping. You can even change your database schema, > > > > > > recomplie > > > > > > your app, and start using the new schema without taking your server > > > > > > offline. > > > > > > > > > > > > And finally, Erlang is fun! :) > > > > > > > > > > > > Cheers, > > > > > > Yariv > > > > > > > > > > > > > > > > > On Nov 10, 2007 7:08 AM, mojo.talantikite <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for all the answers, I really appreciate them. Sometime > > > > > > > later > > > > > > > today or tomorrow I'd like to write up some questions that > > > > > > > pertain to > > > > > > > more of what I'm trying to do, but for now that gives me some > > > > > > > pretty > > > > > > > good ideas as to how I could use Erlang/ErlyWeb. > > > > > > > > > > > > > Overall, what do you feel are Erlang/ErlyWeb's particular > > > > > > > strengths > > > > > > > when it comes to web development? Of course you can pretty much > > > > > > > get > > > > > > > any language/framework to do what you need it to do, but how does > > > > > > > this > > > > > > > particular combination yield itself to solving (or simplifying) > > > > > > > particular web development problems? > > > > > > > > > > > > > Thanks again, the answers were very helpful. > > > > > > > > > > > > > best, > > > > > > > Mojo > > > > > > > > > > > > > On Nov 9, 6:25 am, Al <[EMAIL PROTECTED]> wrote: > > > > > > > > On Nov 9, 9:08 am, "Yariv Sadan" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > On Nov 8, 2007 12:23 PM, mojo.talantikite <[EMAIL PROTECTED]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > I'm in the very early stages of founding a startup, and > > > > > > > > > > currently > > > > > > > > > > we're in talks about what type of technology to be using. > > > > > > > > > > As there > > > > > > > > > > aren't too many people on board now, and none besides > > > > > > > > > > myself that are > > > > > > > > > > technical, there is a pretty blank slate for development as > > > > > > > > > > of now. > > > > > > > > > > After playing around with Erlang for the past couple of > > > > > > > > > > days I'm > > > > > > > > > > starting to think about the pros/cons of using Erlang. > > > > > > > > > > > > > > > > Anyways, I have questions pertaining to how Erlang/ErlyWeb > > > > > > > > > > addresses > > > > > > > > > > certain needs and issues of scaling. I thought it might be > > > > > > > > > > more useful > > > > > > > > > > for a greater number of people if instead of speaking > > > > > > > > > > solely about our > > > > > > > > > > needs for our web app, we use an example people might be > > > > > > > > > > familiar with > > > > > > > > > > and get more from: YouTube. Here are some notes on a > > > > > > > > > > Google Tech Talk > > > > > > > > > > that was given, which also contains a link to the tech talk > > > > > > > > > > video: > > > > > > > > > >http://kylecordes.com/2007/07/12/youtube-scalability/ > > > > > > > > > > > > > > > > Here are some questions that come to mind when thinking > > > > > > > > > > about what > > > > > > > > > > they faced: > > > > > > > > > > > > > > > > 1. Their main reason for choosing Python as their language > > > > > > > > > > is because > > > > > > > > > > development speed and productivity was (and is) very > > > > > > > > > > important for > > > > > > > > > > various reasons (one important one was probably showing > > > > > > > > > > prototypes and > > > > > > > > > > their progresses to potential investors). Erlang seems to > > > > > > > > > > be a very > > > > > > > > > > productive environment for some applications, but how does > > > > > > > > > > it stand up > > > > > > > > > > for web app development? Using Python, PHP, or Ruby has > > > > > > > > > > the added > > > > > > > > > > benefit of having lots of developers to draw from their > > > > > > > > > > experiences -- > > > > > > > > > > how would Erlang compare? > > > > > > > > > > > > > > > Erlang definitely has fewer developers using it for webapps > > > > > > > > > that PHP, > > > > > > > > > Python or Ruby. My subjective take is that, having done PHP > > > > > > > > > programming and played with RoR, ErlyWeb can be just as > > > > > > > > > productive if > > > > > > > > > not more and its code is very concise and expressive. I > > > > > > > > > rarely feel > > > > > > > > > that I'm writing repetitive code that doesn't directly solve > > > > > > > > > the > > > > > > > > > problem domain. Plus, I prefer Erlang's functional style to > > > > > > > > > imperative > > > > > > > > > one. I think FP makes your code more readable and debuggable. > > > > > > > > > Erlang > > > > > > > > > has fewer libraries than more popular languages, which may or > > > > > > > > > may not > > > > > > > > > affect you depending on your app's needs, but I think that > > > > > > > > > the fewer > > > > > > > > > libraries isn't as big an issue as some people say. Erlang > > > > > > > > > has a > > > > > > > > > variety of ways for talking to other lanugages and I'd rather > > > > > > > > > write > > > > > > > > > most of my code in Erlang in occasionally outsource some > > > > > > > > > functionality > > > > > > > > > to another language than lock my whole app to a language I > > > > > > > > > don't like > > > > > > > > > as much just because of the existence of a couple of > > > > > > > > > libraries for it. > > > > > > > > > Btw, Erlang also has some tools that other languages don't > > > > > > > > > have -- > > > > > > > > > most notably, elegant concurrency and Mnesia. > > > > > > > > > > > > > > > > 2. Serving content was of course a big issue. They moved > > > > > > > > > > to lighttpd > > > > > > > > > > from Apache for their videos and got a lot of performance > > > > > > > > > > increases > > > > > > > > > > (they use CDNs for their most popular content). Yaws seems > > > > > > > > > > great for > > > > > > > > > > dynamic content, but is there anything better for the > > > > > > > > > > static content? > > > > > > > > > > > > > > > Use lighttpd for static content and Yaws (or MochiWeb) for > > > > > > > > > dynamic content. > > > > > > > > > > > > > > > > 3. Another major issue YouTube ran into was serving their > > > > > > > > > > thumbnails. Each video can have about 4 thumbnails and > > > > > > > > > > each page, > > > > > > > > > > while having only one video playing, could have 40-60 > > > > > > > > > > thumbnails per > > > > > > > > > > page. Thumbnails, unlike video, aren't distributed across > > > > > > > > > > hundreds of > > > > > > > > > > machines (due to their size). So, you have lots of > > > > > > > > > > requests per > > > > > > > > > > second and tons of disk seeks. Apache didn't really work > > > > > > > > > > out, so they > > > > > > > > > > then went to a modified version of lighttpd that put the > > > > > > > > > > disk reads > > > > > > > > > > into worker threads -- but they ran into issues with that > > > > > > > > > > as well. > > > > > > > > > > They finally went to Google's BTFE. How would Erlang look > > > > > > > > > > at this > > > > > > > > > > problem -- would Yaws help at all? > > > > > > > > > > > > > > > I'm not too familiar with this problem, but if it's static > > > > > > > > > data, it's > > > > > > > > > generally better to serve if from lighttpd than Yaws. > > > > > > > > > > > > > > Agreed LightHttpd or apache will outperform Yaws with static > > > > > > > > content. > > > > > > > > If its lots of small files/images look at using a cache like > > > > > > > > server > > > > > > > > with lots and lots of RAM also consider using solid state disks > > > > > > > > (SSDs) > > > > > > > > in Raid 0 configs, these are much faster than traditional disks > > > > > > > > for > > > > > > > > random small files, they blow away performance of even 15K scsi > > > > > > > > arrays > > > > > > > > for this job, as seeks on SSD flash are near zero in > > > > > > > > comparison. The > > > > > > > > limit here is capacity. You can get 64GB SSDs with Sata > > > > > > > > interfaces > > > > > > > > (Sata II soon from Samsung) raid these up with Sata Raid Boards > > > > > > > > on > > > > > > > > fast PCIe interfaces + built in Sata ports in a mirror config > > > > > > > > You will > > > > > > > > be surprised at how kick ass fast these are for the job. You > > > > > > > > also need > > > > > > > > good server Gigabit ports that can be aggregated. > > > > > > > > > > > > > > > > 4. They use MySql to store metadata, but as the site got > > > > > > > > > > huge, they > > > > > > > > > > ran into some issues with it. They went from having one > > > > > > > > > > database to > > > > > > > > > > doing db replication. That caused issues eventually, one > > > > > > > > > > of them > > > > > > > > > > being that spreading read load (being asynchronous) caused > > > > > > > > > > the > > > > > > > > > > database to serve outdated data from time to time. They > > > > > > > > > > then went to > > > > > > > > > > partitioning the database into shards. Overall, though, > > > > > > > > > > they're > > > > > > > > > > running into issues due to the fact that they're trying to > > > > > > > > > > do more and > > > > > > > > > > more stuff with the data. For example, recommendation > > > > > > > > > > systems and > > > > > > > > > > data mining gets really hard on 100s of millions of views > > > > > > > > > > per day, so > > > > > > > > > > they are needing some solutions that can do parallel > > > > > > > > > > queries and > > > > > > > > > > handle distributed computation. Would Mnesia be able to > > > > > > > > > > help handle > > > > > > > > > > these issues, or anything else from the Erlang world that > > > > > > > > > > could deal > > > > > > > > > > with these issues? > > > > > > > > > > > > > > > Mnesia is more suited for storing live session data than > > > > > > > > > large amounts > > > > > > > > > of persistent data. And Mnesia isn't really suited for data > > > > > > > > > mining -- > > > > > > > > > just for simple queries. However, Erlang helps in that it > > > > > > > > > allows you > > > > > > > > > to connect to multiple databases using its great connection > > > > > > > > > pooling > > > > > > > > > capabilities (a process is spawned for each database > > > > > > > > > connection, and a > > > > > > > > > dispatcher process is responsible for routing queries to > > > > > > > > > connection > > > > > > > > > processes). If I were building YouTube in Erlang, I would > > > > > > > > > consider > > > > > > > > > doing all replication and partitioning work in the > > > > > > > > > application code > > > > > > > > > rather than relying on the database engine. > > > > > > > > > > > > > > Use flat files for the metadata and cache them where possible > > > > > > > > across > > > > > > > > machines, consider an appending meta file storage controller > > > > > > > > (write it > > > > > > > > yourself) and file formats that enable appending rather than > > > > > > > > editing. > > > > > > > > The trick heres is to only append to files where possible, > > > > > > > > editing is > > > > > > > > expense (Well percolating the changes is).Break the files up > > > > > > > > like you > > > > > > > > would database tables and crate summarized view files for common > > > > > > > > queries. > > > > > > > > > > > > > > If there is a lot of data + analysis consider something like a > > > > > > > > map > > > > > > > > reduce pattern to create views on the backend, erlang is > > > > > > > > excellent for > > > > > > > > this sort of stuff, blows the socks of most others. > > > > > > > > > > > > > > regards > > > > > > > > Al > > > > > > > > > > > > > > Regards > > > > > > > > Al > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "erlyweb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en -~----------~----~----~----~------~----~------~--~---
