Hi Patrick
On Fri, Apr 25, 2014 at 3:29 PM, Patrick Ohly <[email protected]> wrote: > > On Fri, 2014-04-25 at 15:03 +0530, Sachin Gupta wrote: > > Hi Lukas/Patrick, > > > > > > I have to run some test cases using syncevolution as client to test a > > SyncML server performance. Expectation is to put load of around 2500 > > users syncing concurrently for an hour. > > That's a bit vague. What kind of changes are supposed to be synced > during that hour? The load will depend a lot on that. At the low end you > just have 2500 users connecting repeatedly without data changing on > client or server. The high end is open-ended; lots of items and slow > syncs will be more expensive than few items and incremental changes. > I would be syncin 1 contact for initial slow sync and post that 100 contacts per user for fast syncs. Not focusing on modifications for now. > > Can you suggest how i can test SyncML Server performance and have 2500 > > users/syncevolutions connecting simultaneously? > > There's no ready-made solution. You'll have to write your own scripts > for configuring SyncEvolution and running the desired benchmark. > > Note that each context in SyncEvolution gets its own device ID. So if > you want to simulate n different devices, use: > > syncevolution --configure ... client-1@client-1 > ... > syncevolution --configure ... client-n@client-n > I figured so. So wrote scripts which will launch syncevo each with unique device ids and seperate user accounts. But the concern is managing these number of syncs through a time period. Exploring if JMETER can help me out in this.\ Also being a process, it would not be possible to launch so many processes in parallel. Memory and CPU would be issues, right? Would need very high end systems for this? Would it be possible doing this launching processes or shall i look into creating threads within the Syncevolution launching and controlling sessions from there? > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > > Regards Sachin _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
