John Buckman said: > to AOLServer scalability and the ns_bdb module (which works very well). That's good to know, I may have some use for it.
> 1) scripting overhead, esp as the application matures and more and > more dependent code gets included on each page load How do you mean "included"? Actual code that is run? One of the things where AOLserver completely blows PHP out of the water is that PHP has to re-interpret everything on every page. So if you include a library and only use one function from it... AOLserver's library Tcl code is just there at no extra cost, other than at thread creation. > platform, at about 1/2 the speed of serving 1k GIFs, but about 10x > faster than PHP, 3x faster than lighthttpd-fastcgi. So, AOLserver is How could that be, PHP is better than anything, its popular for a reason! ;-) That's good info, though. I still plan to do my own benchmarks, with some simulated application so the database and it's drivers get benched too. Not sure if I will ever get around to it, though. > a good platform as far as scripting scalability is concerned, as long > as the developer takes care not to load too much dependent code per As I said becfore I am not clear about what you mean by this, can you elaborate? > end of the table, which is a common scenario. In my experience, many > applications that use SQL actually only need key-lookup capability I guess the answer here is "it depends"; rendering news.bbc.co.uk could be done from BDB. But people end up wanting to do queries like "how much money does the average customer spend per month" that only an RDBMS can provide easily. And the "R" in RDBMS is quite important too. I think the best use for BerkeleyDB is as a cache; save to the RDBMS, then export to Berkeley. Like saving all the fields in a blog entry, then rendering the page and stuffing it in a BerkeleyDB for viewing. > that it's tricky to get right. Google uses Berkeley DB for their > universal login, for just this reason. It's extremely usefull for that. Though many sites don't quite need to scale to Google-esque proportions. > Thirdly, you'll notice many sites have very poor full text searching > performance. Lucene, a recently popularized full text search engine, > appears to finally solve this problem. However, in my case I wanted But Lucene is probably hard to integrate unless you use Java, isn't it? I had a play with http://xapian.org/ two years ago. Seems very good, it'd be nice to have an AOLserver module for it. Some day, when I have time... > I know that going with Berkeley DB is controversial, but in my > opinion it's extremely difficult to scale up a SQL backed application Like I said, I would use DBD as a cache and store the "real data" in a nice relational schema. But maybe that's just my apprehension with a technology I haven't used beyond some experiments... > db platform and do extensive up-front design work to that effect, > which few people do. And those are the magic words. Most people don't, they just care about functionality; "it works, I am done." I am just finsihing up on a service (http://www.sativo.co.uk) where search is very important. I know that even with high concurrency it will do 20 searches/sec on the current hardware with 100K subscribers. I also designed in seperate pools for reading and writing, so if I do need to scale to multiple DBs, I can use a simple single master, multiple slaves setup with every web server reading from their own DB and writing to the master. Due to the low number of writes on this service, that will scale very well. > Just my opinion... all I can say is that AOLServer+berkeley-db, if > you can live with a key-lookup database only, is incredibly fast, at No surprise there really, AOLserver is the fastest server and BDB is pretty much the fastest thing out there for key/value lookups! Cheers, Bas. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
