[mapserver-dev] MapScript multithreading performance
Steve Lime
Steve.Lime at dnr.state.mn.us
Mon Feb 11 10:26:07 EST 2008
That's the expected bottleneck point. The locks are around pretty specific
pieces of code, mostly related to expression handling if I'm not mistaken. So
I wonder if moving to a threadsafe lexer/parser would help. Both bison and
flex support that. We'd have to carry the static variables associated with those
as a piece of the mapObj. I've not looked at doing that very closely but it's
probably relatively straight forward.
Steve
>>> "adrian kruk" <adrian.kruk at gmail.com> 02/11/08 6:15 AM >>>
Hi,
I did some multithreading performance tests using C# mapscript (We've
discussed about safety and performance before)
I have run 200 threads running simultanously and performing actions like:
create mapObject, zoom, pan, query, draw, etc
Testing application environment:
-4processors server (Intel Xeon E5320)
-Win2003EE+SP3
-4GM RAM
-MapScript 5.1-DEV from
http://www.coordinatesolutions.com/download/ASPNET20Sample_50.zip
-1GB data in shapefiles on RAID
I expected performance problems with parsing mapfile (static variables,
locks). But there were no problems with it.
During parsing mapfile by 200 threads processors was used in 98-100%. So it
is perfect result.
But, I find problem probably with draw method. Each thread was executing
methods on its own map object like:
drawLegend, drawScalebar, queryByAttributes, zoomPoint, setExtent, Draw.
During running test application, and executing those methods, processors was
used in 25-35% ONLY (25% - one processor).
Its very poor result. I guess that problem may be related with using locks
in drawing process{ imageObj img = map.draw() }, which takes much more time
than other mapObject methods.
How to improve performance? It is hard to fix it?
Regards,
Adrian Kruk,
infovidematrix.pl
More information about the mapserver-dev
mailing list