Hi cesar, and thanks for the optimization - if you see anything like that please let me know. I will need a little bit more informaiton from
you - what version of GeoServer / GeoTools etc? The implementation of AttributeExpressionImpl has changed in the last 6 months.
Cheers,
Jody
cesar wrote:
Hi Jody
THE SCENARY:
We have verified a test stress with geoserver-geotools and google-maps, this test have realized with tptp plugin from Eclipse,
we are using MySql-spatial and the table has a lot of fields, the test was with 3 fields (ID, GEOMETRY, NAME) and 380 fields.
THE WORKAROROUND:
the results with 3 fields was seemed , but with 380 came down, too slow.
tptp was clear, a method "setAttributePath" from AttributeExpressionImpl class, was the responsable.
THE CODE:
/**
* Constructor with minimum dataset for a valid expression.
*
* @param attPath The initial (required) sub filter.
*
* @throws IllegalFilterException If the attribute path is not in the
* schema.
*/
public void setAttributePath(String attPath) throws IllegalFilterException {
LOGGER.entering("ExpressionAttribute", "setAttributePath", attPath);
LOGGER.finest("schema: " + schema + "\n\nattribute: " + attPath);
if (schema != null) {
if (schema.hasAttributeType(attPath)) {
this.attPath = attPath;
} else {
throw new IllegalFilterException(
"Attribute: " +attPath+ " is not in stated schema "+schema.getTypeName()+".");
}
} else {
this.attPath = attPath;
}
}
and the line:
LOGGER.finest("schema: " + schema + "\n\nattribute: " + attPath);
you can see that schema call toString method from DefaultFeatureType class.
the code:
public String toString() {
String info = "name=" + typeName;
info += (" , namespace=" + namespace);
info += (" , abstract=" + isAbstract());
String types1 = "types=(";
for (int i = 0, ii = this.types.length; i < ii; i++) {
types1 += this.types[i].toString();
if (i < ii) {
types1 += ",";
}
}
types1 += ")";
info += (" , " + types1);
return "DefaultFeatureType [" + info + "]";
}
with 380 fields this a lot of workaround.
THE SOLUTION:
but with the simple code for the method setAttributePath:
if (LOGGER.isLoggable(Level.FINEST)) LOGGER.finest("schema: " + schema + "\n\nattribute: " + attPath);
Don´t call (schema) tostring method.
THE INFO: http://logging.apache.org/log4net/release/sdk/log4net.ILog.IsDebugEnabled.html
with the original line:
LOGGER.finest("schema: " + schema + "\n\nattribute: " + attPath);
Hits: 815
Average hits per second: 2,69
with the new code
if (LOGGER.isLoggable(Level.FINEST)) LOGGER.finest("schema: " + schema + "\n\nattribute: " + attPath);
Hits: 3152
Average hits per second: 37,524
WOOOOOOOOOWWWWWWWWW .
there are a lot of LOGGER.finest
Thanks,
Cesar.
Hi cesar, and thanks for the optimization - if you see anything like that please let me know. I will need a little bit more informaiton from
you - what version of GeoServer / GeoTools etc? The implementation of AttributeExpressionImpl has changed in the last 6 months.
Cesar, what kind of workload is this? What is GeoServer doing to create
that many attribute types?
Cheers
Andrea
Andrea, the problem whith "toString" is with the minimal fields attributes, (ID, GEOMETRY, FIELD), if you change the line-code with:
if (LOGGER.isLoggable(Level.FINEST)) LOGGER.finest("schema: " + schema + "\n\nattribute: " + attPath);
the performance go up. in this test-case the fields are population pyramid, in ranges of 5 years, and others fields, I agree that there are too fields, but I´ve tested it with only three minimal attributes, the test was realized with tptp plugin from Eclipse, with a project with geoserver and other with geotools(jar-lib) and in src the main. the workload was with mercury tool. ( 2 users, 10 queries, 5 minutes).
anyway is the schema.toString() make a overcharge of work because work with in any Level and without logger.
if you need other test of workload, send me the sql-data dump. Now I´m ready the scenary to make it.
Cheers
Cesar
----- Original Message ----- From: "Andrea Aime" <aaime@anonymised.com>
To: "Jody Garnett" <jgarnett@anonymised.com>
Cc: "cesar" <cgamboa@anonymised.com>; <geoserver-devel@lists.sourceforge.net>
Sent: Tuesday, July 31, 2007 8:13 PM
Subject: Re: [Geoserver-devel] Logger and Performance
Jody Garnett ha scritto:
Hi cesar, and thanks for the optimization - if you see anything like that please let me know. I will need a little bit more informaiton from
you - what version of GeoServer / GeoTools etc? The implementation of AttributeExpressionImpl has changed in the last 6 months.
Cesar, what kind of workload is this? What is GeoServer doing to create
that many attribute types?
Cheers
Andrea
Andrea, the problem whith "toString" is with the minimal fields attributes, (ID, GEOMETRY, FIELD), if you change the line-code with:
if (LOGGER.isLoggable(Level.FINEST)) LOGGER.finest("schema: " + schema + "\n\nattribute: " + attPath);
the performance go up. in this test-case the fields are population pyramid, in ranges of 5 years, and others fields, I agree that there are too fields, but I´ve tested it with only three minimal attributes, the test was realized with tptp plugin from Eclipse, with a project with geoserver and other with geotools(jar-lib) and in src the main. the workload was with mercury tool. ( 2 users, 10 queries, 5 minutes).
anyway is the schema.toString() make a overcharge of work because work with in any Level and without logger.
if you need other test of workload, send me the sql-data dump. Now I´m ready the scenary to make it.
Cesar, you're describing the issue, I asked what workload shows the problem. What kind of requests to Geoserver are you making to make that
log statement so evident in the profiles? Is this WFS or WMS?
And which operation, GetFeature, GetMap?