Currently new_server translates elements to new_foreign_client messages. This results in a lot of independent accesses to the clientdb. If (as I had initially implemented) I perform these in independent goroutines, the result is a crazy number of goroutines (which resulted in a crash before the stack size was limited in the gosa-si-server script). If (as implemented now) they are done in sequence in the same goroutine, the performance is slow, at least when looking at main/susikiller.
Of course susikiller is not a realistic test. Check timing data in the backbone to see if there is a problem. If there is, use susikiller + profiler to find out what takes most of the time when processing new_server messages. Create a new ticket for the actual optimization if any is required and close this task ticket.
From matthias...@gmail.com on March 26, 2013 19:00:11
Currently new_server translates elements to new_foreign_client messages. This results in a lot of independent accesses to the clientdb. If (as I had initially implemented) I perform these in independent goroutines, the result is a crazy number of goroutines (which resulted in a crash before the stack size was limited in the gosa-si-server script). If (as implemented now) they are done in sequence in the same goroutine, the performance is slow, at least when looking at main/susikiller.
Of course susikiller is not a realistic test. Check timing data in the backbone to see if there is a problem. If there is, use susikiller + profiler to find out what takes most of the time when processing new_server messages. Create a new ticket for the actual optimization if any is required and close this task ticket.
Original issue: http://code.google.com/p/go-susi/issues/detail?id=106