HtmlToText
advanced search - powered by google consortium activities projects forge events rubis project links · home · download · documentation · mailing list · experimental results · license · history developers' corner · getting involved · objectweb forge site · cvs repository about · contacts · team · jmob recent news september 17th 2008: rubis virtual appliance v1.0. to make rubis easier to setup and use, we are pleased to announce the availability of the rubis virtual appliance v1.0, a xen virtual machine that contains all the components of the rubis benchmark with auto-deployment scripts. the release also contains a new documentation and tutorial videos. download it from the ow2 forge march 24th 2004: howto install rubis with jonas a howto for installing rubis with jonas is now available thanks to jacques cayuela from the jonas project. december 3rd 2003: new contributions to rubis. mark brody and george candea from stanford university wrote a guide to install rubis 1.4.1 on jboss 3.2.2 . daniel pfeifer from university of karlsruhe contributed his version of rubis which is fully controlled by ant and includes a client emulator for windows. the things he changed in rubis for his experiments are described in section 5.1 of his paper . download remigius kuzyna from university of muenster added some changes to the client emulator: logwriter, initialization methods, etc. download rubis: rice university bidding system rubis is a jmob project current release: 1.4.2 overview rubis is an auction site prototype modeled after ebay.com that is used to evaluate application design patterns and application servers performance scalability. our auction site benchmark implements the core functionality of an auction site: selling, browsing and bidding. we do not implement complementary services like instant messaging or newsgroups. we distinguish between three kinds of user sessions: visitor, buyer, and seller. for a visitor session, users need not register but are only allowed to browse. buyer and seller sessions require registration. in addition to the functionality provided during visitor sessions, during a buyer session users can bid on items and consult a summary of their current bids, rating and comments left by other users. seller sessions require a fee before a user is allowed to put up an item for sale. an auction starts immediately and lasts typically for no more than a week. the seller can specify a reserve (minimum) price for an item. rubis is a free , open source initiative. design patterns several versions of rubis are implemented using three different technologies: php , java servlets and ejb (enterprise java bean). in php and java servlets, the application programmer is responsible for writing the sql queries. in order to arrive at a fair comparison, we use exactly the same queries to the database in both environments. an ejb server provides a number of services such as database access (jdbc), transactions (jta), messaging (jms), naming (jndi) and management support (jmx). the ejb server manages one or more ejb containers. the container is responsible for providing component pooling and lifecycle management, client session management, database connection pooling, persistence, transaction management, authentication and access control.ejb containers automatically manage bean persistence, relieving the programmer of writing sql code. we use these facilities to implement various ejb versions of rubis. while using ejb 1.1 or 2.0 cmp model, we use session beans for complex queries that cannot be executed using cmp. the java servlets are used only as the presentation tier, to generate the html reply from the information retrieved from the bean. benchmark tool rubis can be used from a web browser for testing purposes or with the provided benchmarking tool. we designed a client that emulates users behavior for variours workload patterns and provides statistics. our auction site defines 26 interactions that can be performed from the client’s web browser. among the most important ones are browsing items by category or region, bidding, buying or selling items, leaving comments on other users and consulting one’s own user page (known as myebay on ebay). browsing items also includes consulting the bid history and the seller’s information. we define two workload mixes: a browsing mix made up of only read-only interactions and a bidding mix that includes 15% read-write interactions. the bidding mix is the most representative of an auction site workload. we implement a client-browser emulator. a session is a sequence of interactions for the same customer. for each customer session, the client emulator opens a persistent http connection to the web server and closes it at the end of the session. each emulated client waits for a certain think time before initiating the next interaction. the next interaction is determined by a state transition matrix that specifies the probability to go from one interaction to another one. the think time and session time for all benchmarks are generated from a negative exponential distribution with a mean of 7 seconds and 15 minutes, respectively. we vary the load on the site by varying the number of clients. database we use a mysql database that contains 7 tables : users , items , categories , regions , bids , buy_now and comments . the users table records contain the user’s name, nickname, password, region, rating and balance. besides the category and the seller’s nickname, the items table contains the name that briefly describes the item and a more extensive description, usually an html file. every bid is stored in the bids table, which includes the seller, the bid, and a max_bid value used by the proxy bidder (a tool that bids automatically on behalf of a user). items that are directly bought without any auction are stored in the buy_now table. the comments table records comments from one user about another. as an optimization, the number of bids and the amount of the current maximum bid are stored with each item to prevent many expensive lookups of the bids table. this redundant information is necessary to keep an acceptable response time for browsing requests. as users only browse and bid on items that are currently for sale, we split the item table in a new and an old item table. the very vast majority of the requests access the new items table, thus considerably reducing the working set used by the database. we sized our system according to some observations found on the ebay web site. we always have about 33,000 items for sale, distributed among ebay’s 20 categories and 62 regions. we keep a history of 500,000 auctions in the old-items table. there is an average of 10 bids per item, or 330,000 entries in the bids table. the buy_now table is small, because less than 10% of the items are sold without auction. the users table has 1 million entries. we assume that users give feedback (comments) for 95% of the transactions. the comments table contains about 506,500 comments refering either to items or old items. the total size of the database, including indices, is 1.4gb. learn more about rubis in the documentation section and download the code or the experimental results. getting involved any input or personal view for improving and/or developing rubis is welcome. rubis, as an open source project, also welcomes external contributions . interested? contact us . copyright © 1999-2009, ow2 consortium | contact | webmaster | last modified at 2009-10-07 08:43 pm
rubis.ow2.org rapport :
Visitez le site