Skip to main content

Home/ Google AppEngine/ Group items tagged performance

Rss Feed Group items tagged

Esfand S

Using the Java Mapper Framework for App Engine « Ikai Lan says - 0 views

  • to write large batch processing jobs without having to think about the plumbing details.
  • it is a very easy way to perform some operation on every single Entity of a given Kind in your datastore in parallel
  • What would you have to build for yourself if Mapper weren’t available? Begin querying over every Entity in chained Task Queues Store beginning and end cursors (introduced in 1.3.5) Create tasks to work with chunks of your datastore Write the code to manipulate your data Build an interface to control your batch jobs Build a callback system for your multitudes of parallelized workers to call when the entire task has completed It’s certainly not a trivial amount of work
  • ...1 more annotation...
  • Some things you can do very easily with the Mapper library include: Modify some property or set of properties for every Entity of a given Kind Delete all entities of a single Kind – the functional equivalent of a “DROP TABLE” if you were using a relational database Count the occurrences of some property across every single Entity of a given Kind in your datastore
Esfand S

Does Eclipse upload 3rd-party GWT libraries to GAE? - Stack Overflow - 0 views

  • Cold-start latency is determined by the time it takes to load all the classes needed to handle the request. If you upload a JAR file, but nothing references it, it won't be loaded, and thus won't affect your cold-start latency.
  • Only those jars under WEB-INF/lib will be uploaded to GAE. You can prevent GWT jars from being uploaded by not placing them under WEB-INF/lib, rather by externally linking to them in your project build path.
Esfand S

Google App Engine Cold Start Tips - Don't Use JSP - 0 views

  • this tip can cut a few hundred milliseconds or more off of your cold start time. Using JSPs slows you down in two ways: If you have a file with a .jsp extension, anywhere in your website directory, appcfg will detect that you use JSP, and it will add 8 libraries that are used for processing JSPs into your lib directory before uploading to the app engine.  These libraries total two megabytes in size, and simply having them in your lib directory slows your cold starts down by a few hundred milliseconds. If you are interested in what libraries these are, you can see them in the temporary folder appcfg creates while uploading your app. The first JSP file accessed after a cold start, even an empty one, will take a few hundred additional milliseconds to be processed.  I'm not sure what causes this, maybe it has to do with initializing the JSP processor.
Esfand S

Google App Engine Cold Start Guide for Java - 0 views

  • Originally my application started out using Spring MVC and JDO. The first use of JDO took my application about 5 seconds to get everything set up.  Similarily, Spring MVC added around 6 seconds to the cold start  time
  •  If you are not using either JDO or JPA, you can safely delete all related libraries (ones that have JDO, JPA, or Datanucleus in their name) and use the command line tool to upload your app. Deleting these libraries shaves about 400ms off of cold start time.
Esfand S

DTO object - Google App Engine for Java | Google Groups - 0 views

  • From what I understand, you are "manually" copying the properties from the Entity to the DTO. But this process is automated in GWT 2.1 So, I am not sending my entities directly, but the proxies as per the documentation : http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html "An entity proxy is a client-side representation of an entity, otherwise known as a DTO (Data Transfer Object). With RequestFactory, entity proxies are interfaces that extend the EntityProxy interface, which is the hook used to indicate that an object can be managed by RequestFactory. RequestFactory automatically populates bean-style properties between entities on the server and the corresponding EntityProxy on the client, which simplifies using the DTO pattern. Furthermore, the EntityProxy interface enables RequestFactory to compute and send only changes ("deltas") to the server." "Entity proxies simply extend the EntityProxy interface and use the @ProxyFor annotation to reference the server-side entity being represented. It is not necessary to represent every property and method from the server-side entity in the EntityProxy, only getters and setters for properties that should be exposed to the client." The entity proxies are merely interfaces that are being populated by the new GWT 2.1 RequestFactory framework. I have no control over this copying process. Per definition, getters/setters of the real entity are injected into the EntityProxy whenever they are present; So my problem still stands : what about complex values like com.google.appengine.api.datastore.Email that are not known by the client side code ? How to transfer these complex values to the client.
  • When I copy my entities onto my dtos, some entity fields don't even make it into the dto. Others only have getters in the dto because they are read-only to the client. Those that do get into the dto get converted to native Java types. For instance, Text gets converted to String. Key gets encoded to a url friendly string. If I have Set fields on the entities to manager my relations (property lists), I remap those to ArrayList... First, don't serialize interfaces to GWT client, you'll get Javascript bloat. Then, Hashmap is costly to serialize because String.hashCode() is not the same on in Java and in Javascript. Hence, all the items need to be re-inserted into a client side map. Of course, in Web mode, performance is good enough... but in development mode, your data transfers will become really slow for somewhat big transfers.
‹ Previous 21 - 30 of 30
Showing 20 items per page