Hey Pampero’'s everybody,i always have a question about JM scaling application.now Is Pampero have a developing plan in Roadmap,how much people is do this project.what step is it now?
May we view it seem browse Projects jivemessenger roadmap?whether pampero’'s developer can interpret it,i have some interest to dedicate it although i have a few knowlege to it.
We’‘re still in the brainstorming phase. Until we get a clear idea of the design and direction we’‘re going I don’'t think we can really lay out a useful roadmap. I guess we should probably set some deadlines to work against or this initial brainstorming could drag on forever though.
-iain
Hey iain,i want your view is right,some deadline is required,because more people have a interesting to Pampero,but we aren’'t meet to who already began it.whether anybody implement initially it that notify this steping, maybe us together accomplished this big project.
-tom
I think that there are some preliminaries that need to be addressed.
I’‘ve already taken the liberty to start the profiling section. Load generation is accomplished using Winfessor’‘s SoapBox XMPP Stress tool. I like it because it’‘s quick and does the job on my windows platform, but I think that it’‘s not a suitable choice in the long run. It also doesn’‘t simulate the a typical users’’ interaction with the system. It just throws messages at the server (with UUIDs of a fix length format).
I would like something that runs from ant and is deployable to more than one load generator. Everyone’‘s thrown their ideas into the pot. Let’'s pick one. (Jive Forum needs a polling system
We’'ve had a discussion, but nothings been decided on.
Someone needs to take the first stroke and put some “color to the canvas.” I’‘m working my way there but I need to understand item 2 better before we start. It also requires revisiting item 1, which is where I’'m currently at.
At this point, everyone has an opinion about which IO framework is going to save the day. This has the potential to cause the entire project to come to halt. I’'d suggest that either we all agree on one or we designate one individual to just pick one and run with it. Either way, if items 1 and 2 are in place, easy to use and people who are knowledgeable/interested in the project can easily access them, then we can all fire away at the first cut.
At this point, we’'ve bootstrapped the project into a release cycle. Build, test, analyize, repeat.
As far as status, I’‘m the only one contributing to the Pampero branch and I’‘m currently in a deadlock until I receive a resolution from Matt and Gato at Jive. I’‘m hoping someone will tackle the load generator problem and then it’‘s into the meat of the problem. I’'d also like to volunteer to be the individual that takes the first crack at 0.0.0.1 unless design by committee is desired.
How’'s that for a roadmap
Noah
I agree with your assessments.
1 (profiling and stress testing)
JMeter seems like a good foundation for building out a tool. I created a similar setup for testing with NNTP and once you get beyond the initial pain of learning the framework it can go pretty quickly.
One thing to consider is a partnership with Winfessor to build the tool - possiblying building on their existing one. They use .NET and I’‘m not sure how many Messenger people own visual studio .NET (I don’‘t). But maybe we could port their existing stuff and expand from there? Or request tweaks to Winfessor’‘s tool that would allow us to use it as-is but coordinate distributed tests using some glue code whether .NET, perl or java or whatever. In any case, testing tools is something that can benefit both of us and the Winfessor guys are very cool about sharing technology and ideas… And neither of us is focused on testing itself - it’'s just an ends to a means so anything that helps us get better tools would probably be interesting to everyone.
2 protocol
Agreed… Thinking about it, maybe we need to design the transport integration points in Messenger CM and Core rather than the actual protocol. That would let people try different protocol implementations quickly and in parallel. If someone comes up with a custom binary protocol, or wants to use straight XMPP XML, or wants some other scheme they can try it out in parallel.
That way we can explore as many solutions as possible and use the testing tools to determine the best solution. I imagine it will depend a lot on the specifics of the task at hand which could suggest we need to negotiate protocols or at least provide for a few reasonable options. I also have a hope that such a design would encourage academic research using the Messenger codebase which could result in really innovative technology in the future.
3 prototype
I prefer to see design by indivdual or very small group rather than design by committee. If we could create a pluggable transport to sidestep issue #2 I think hacking out a fast first prototype asap is the best way to proceed. Keep it fast and simple and be prepared for refactoring and rewriting and get something to start with seems like the best strategy. Motion in any direction is better than no motion at all (and all that jazz).
Since you’‘re ready to go i’‘d say you should just code a quick and dirty first crack 0.0.0.1 and check it in. Use anything for the CM <–> Core communication… I’‘d suggest just using RMI for now. That’‘s probably the quickest and dirtiest first pass - our packets implement Serializable don’‘t they? The strawman should give us something to at least talk against, figure out where the real protocol integration points can be, etc. It would also give us something to test the testing tools agaist (comparing this strawman against standard Messenger). By the time we get the build system, testing, and basic design idea done from this, we’'ll be at a point where we can refactor the strawman, know something about the tradeoffs with actual protocols, and be in a good spot to take a crack at pampero 1.0… IMO
-iain
Jmeter it is (unless there are any nay sayers). It looks robust enough to serve our needs.
Pure java
Distributed capabilities
Friendly GUI
Apache license
We’'ll use this until it becomes too cumbersome or a better alterative presents itself.
Noah
Message was edited by:
noahcampbell - http://www.jivesoftware.org/community/thread.jspa?threadID=16310&tstart=0Thanks noahcampbell and iain’'s idea:) if plan can action in roadmap,we may test it and provide bug report or add some function in Pampero.
Hey guys,
It seems that you have agreed on a stress testing tool. It would be nice if you can start defining an initial set of stress tests to implement and then implement them. I would like to use them against JM 2.3.0 beta 1 so I can easily profile the server and find hotspots that might be improved.
Regards,
– Gato
Where should it be checked into? I can commit it to Pampero branch and you can merge it the main trunk if you want.
Noah
Hey Gato,we may test jm stress effection,where have this test tools and track record? it should convenience us to begin this test.
–Tom
Thanks,good idea !
I think test it and provide bug report or add some function in Project Pampero !
email: zhuaming@gmail.com