But performance that should be better then 1.1
I think the bottlenecks will not be in the wicket code but more in the layers beneath it like the database.
Only memory consumption should be monitored, but for that we have detachable models.
johan
On 3/12/06, Vincent Jenks <[EMAIL PROTECTED]> wrote:
Sure, I'd be interested to see how it stacks up. Where is 1.2 in terms of relative stability vs. 1.1.1? Is it at or near "production" quality for say, a mid-sized application w/ maybe a few dozen concurrent users, tops? Are there any glaring, known-issues?
Sorry if I'm asking redundant questions...I'm sure it's been asked 1000x now.
I ran this same benchmark on Gentoo Linux w/ the 2.6.15 kernel using mysql 4.1 and it wasn't nearly as fast...and that box has a 3GHz proc w/ HT. I'm stuck w/ MSSQL for my work projects but I'd like to see how different db's stack up w/ JBoss EJB3.
-vOn 3/11/06, Johan Compagner <[EMAIL PROTECTED]> wrote:can you do these test with the current 1.2 code?
there are a lot of performance enhancements in 1.2, but ofcourse there are added functionality so don't know exactly how it did turn out.
johanOn 3/11/06, Vincent Jenks <[EMAIL PROTECTED] > wrote:Definitely helps, thanks much. I've been running more siege tests and yeah, performance goes right down the drain after running the test a few more times...to the point where it's taking 20+ seconds to load a page and the server's memory is getting sucked up quick.
In both cases, after running the test, the performance degrades and stays lower on each run...but the detached model version isn't nearly as bad.
I'm going to test this on a server here in my home office which should provide better results than a centrino laptop.
And yeah, I could probably get a lot better information by using better tests but for now, I'd like to see how it stands up in a read-only scenario. Since this is a shopping cart...there won't be a *ton* of insert/update activity...but it will certainly have to stand up to the load when activity *does* pick up.
Thanks Igor!On 3/11/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:one. you wouldve seen a huge hit when not using detachable models if you were running your test on a non-sticky cluster. because then all that data you are putting into the session would be replicated on every request.
two. detached models help you to reduce the amount of memory your server is using. you load the model, use it for rendering, and then throw it away. if you dont use a detachable model, then the object the model is pointing to remains in ram until the page expires. so cpu/memory trade off here.
three. your app is a read only app. sometimes wicket needs to clone the model to support undo. if you are not using a detachable model that points to a large object then that object might get cloned which is often undesirable ( ie if it is the hibernate session you dont want the whole thing getting cloned because it can be huge and even when the model is rolled back on a back button that session is useless )
hope this clarifies some things.
-IgorOn 3/11/06, Vincent Jenks <[EMAIL PROTECTED] > wrote:OK, I ran a test using the small CLI app "siege". I don't know how reliable this test is but the results logged are *definitely* impressive...to say the least...not at all what I expected given what I've done. This setup is as ghetto as it gets.
Here's my app:
Presentation: Wicket 1.1.1
Application: EJB3 on JBoss 4.0.4RC1 (non-clustered)
Database: MSSQL 2000 (Developer Edition)
The app is on my dev machine (my laptop) which is a single proc 2GHz Dell Latitude w/ 2GB ram.
I'm simply calling a collection of Entity beans from a stateless session bean and looping them in a table in Wicket. There's maybe 20 records in the table.
Here's my Wicket code (without detachable model):
---------------------------------------------------------------------------------------------
public class Home extends WebPage
{
public Home()
{
List<Product> products = this.getAllProducts();
add(new ListView("products", products)
{
protected void populateItem(ListItem item)
{
Product product = (Product)item.getModelObject();
item.add(new Label("description", product.getDescription ()));
}
});
}
private List<Product> getAllProducts()
{
Products p = null;
try
{
InitialContext ctx = new InitialContext();
p = (Products)ctx.lookup("MyEarProject/ProductsBean/local");
}
catch (NamingException exp)
{
exp.printStackTrace();
}
return p.getAll();
}
}
Here's the same code *with* detachable model (ctor only):
---------------------------------------------------------------------------------------------
public Home()
{
add(new HeaderPanel("headerPanel"));
add(new FooterPanel("footerPanel"));
IModel loadingModel = new LoadableDetachableModel()
{
Products p = null;
protected Object load()
{
try
{
InitialContext ctx = new InitialContext();
p = (Products)ctx.lookup("MyEarProject/ProductsBean/local");
}
catch (NamingException exp)
{
exp.printStackTrace();
}
return p.getAll();
}
};
add(new ListView("products", loadingModel)
{
protected void populateItem(ListItem item)
{
Product product = (Product)item.getModelObject();
item.add(new Label("description", product.getDescription()));
}
});
}
Here are the results without detachable model:
---------------------------------------------------------------------------------------------
Transactions: 5006 hits
Availability: 100.00 %
Elapsed time: 99.61 secs
Data transferred: 22311742 bytes
Response time: 1.46 secs
Transaction rate: 50.26 trans/sec
Throughput: 223990.98 bytes/sec
Concurrency: 73.32
Successful transactions: 5067
Failed transactions: 0
Longest transaction: 7.27
Shortest transaction: 0.02
...and with detachable model:
---------------------------------------------------------------------------------------------
Transactions: 5388 hits
Availability: 100.00 %
Elapsed time: 99.56 secs
Data transferred: 24014316 bytes
Response time: 1.32 secs
Transaction rate: 54.12 trans/sec
Throughput: 241204.47 bytes/sec
Concurrency: 71.47
Successful transactions: 5448
Failed transactions: 0
Longest transaction: 7.08
Shortest transaction: 0.35
Now, the real question is; shouldn't I have seen serious performance/scalability degredation by *not* detaching the objects? Really all we're talking about here are abstracted Hibernate sessions (JBoss EJB 3). It's probably safe to say that this would be a more dramatic difference w/ larger, more complex objects, correct?
I know these tests are rough and in no way "professional" benchmarks...but it's interesting nonetheless. It appears that I could get away w/ *not* using detached objects on this project (and cleaner code)...since we never anticipate 100 *concurrent* users....but even if we did...the app would probably still be highly available. Also, in production, All services won't be on the same machine...it'll likely start out on a dual-proc ( 2.8GHz xeon) app/web server w/ about the same amt. of ram and a separate database server w/ MSSQL 2K Enterprise (not my first choice in DB but I *have* no choice.) Obviously, we could easily scale up later by both throwing more hardware at it by clustering it and adding detachable models around the session beans, if it became necessary.
Any thoughts?
-v
