-
FEATURED COMPONENTS
First time here? Check out the FAQ!
I strongly favor ZK's programming model. But I must have some settings off. Any help from those with experience deploying ZK under load is appreciated. My experience with initial load testing has not been favorable in that running "ab" a few times on a simple page brings the app to its knees.
Thanks!
For example:
Environment
Macbook Pro, 2.6GHz Dual Core, 4MB RAM
Java 6, 64bit
Tomcat 6.0.26
Run the following apache bench 6 times to drown ZK app
> ab -n 2000 -c 50 http://localhost:8080/
index.zul
<?variable-resolver class="org.zkoss.zkplus.spring.DelegatingVariableResolver"?>
<window title="My First window" border="normal" >
<hbox>
<label value="${message.text}"/>
</hbox>
</window>
Message class (Just straight pojo)
public class Message extends Object {
private String text;
public String getText() { return text; }
public void setText(String text) { this.text = text; }
}
Spring Bean
<bean id="message" class="org.test.zk.Message">
<property name="text" value="Hello ZK Spring World" />
</bean>
The issues above seem simply to be related to vm memory and thread management--its a server-side, stateful framework after all...right.
-Increasing servlet container heap allowed more connections as expected.
-What I didn't understand was how zk processes events and the options available. This article provides some good tips and the trade-offs using the event processing thread vs. servlet threads to handle events.
http://docs.zkoss.org/wiki/Performance_Tip#Use_the_Servlet_Thread_to_Process_Events
After increasing the heap to 1g and switching to servlet event handling
With these changes I was able to run the following apache bench 11 times before maxing out the heap
ab -n 10000 -c 100 http://localhost:8080/
*Note that compared to the previous post this is 5x the hits, 2x the concurrency, and 2x the runs as before
*Requests/second for each of these runs was between 480 and 1100 with most ~ 650 req/s
QUESTION: So my question for you experienced ZK 5.x users is why would I use the event processing thread? Performance and memory consumption is drastically degraded with that setting...maybe as bad as 50% more memory use and 1/3rd the performance. Any insight appreciated.
Hi
thanks for your testing result
I have a theory about this
I think disable thread processing is good when need memory.
On the other hand
When I need to suspend the processing thread, I will need to enable the event processing thread.
For example, when a event need to use concurrent thread to calculate the result, and get result from these coucurrent thread when finish, then I will have to suspend the event thread and wait for the result
I think use thread is a good option when need concurrent computation
I am wondering, could someone provide the real case to use event processing thread ?
Obviously, with the Event processing thread, the programming model for Modal dialog is much more straight-forward. If using the servlet thread, you'll have to fake the Modal window, and write extra code to figure out the state when a Modal dialog is closed because the processing returns immediately after opening the dialog window.
Asked: 2010-06-14 15:47:53 +0800
Seen: 257 times
Last updated: Jun 15 '10