Author:
Ikewu| Reprinted, but the original source, author information, and copyright statement of the article must be indicated in hyperlink form
Web: http://www.dbanotes.net/arch/google_app_engine-summary.html
Press: This is the guest blog series. Contributed by Wu zhuhua, who has been engaged in cloud computing-related research at the IBM China Research Institute, is now working on cloud computing technology.
This is the final chapter of this series. I will summarize the usage notes, best practices, and applicable scenarios of the App Engine. Finally, I will talk about some of my expectations for the App Engine.
Notes
- Slow execution speed: due to its distributed design, the speed is not optimal. For example, a common memcache can complete operations in several milliseconds, the memcache of App Engine takes about 50 (NO) seconds to complete the operation.
- Private APIs: many of their APIs are private, especially in terms of their services. Although Google provides good documentation, it costs a lot in terms of learning and porting.
- Execution may fail: based on the actual experience of many people, the App Engine may fail to execute tasks from time to time, especially for datastore and urlfetch, although Google has reduced the chance of errors in datastore from 0.4 to 0.1, it is difficult to avoid failure.
- Sometimes there will be downtime: although the downtime is not frequent in general, the failure of up to 136 minutes at the beginning of this year may lead to the failure of some users' applications, the cause is that a problem occurs in the backup data center.
- You cannot select an appropriate data center. For example, if your application is mainly located in Europe, the app engine server to which your application belongs may be deployed in a data center in the United States, although your application may move to a data center in Europe in the future, you cannot control the entire process.
- Sometimes request processing times out: although a massive number of requests can be completed between 100 and Ms On average, sometimes the request processing times out.
- Bare domain names are not supported: Only cname-like subdomain names are supported.
Best practices
- Adapt to the data model of App Engine: because of its data model, it is not a traditional relational model, and its performance is also very different from that of relational databases, therefore, if you want to make good use of the key datastore, it is essential to understand and adapt its data model.
- Splitting an application: Because the App Engine imposes certain resource restrictions on each application, and to make the application more SOA-oriented and modular, you can split multiple sub-applications into one application. For example, it can be divided into one web application for the frontend and multiple background applications for the rest service.
- Memcache is very likely to be used in many ways, which not only reduces expensive datastore operations, but also reduces the pressure on datastore.
- As mentioned above, because the App Engine may fail to execute some operations, such as datastore, it is necessary to handle exceptions in the design and implementation aspects.
- Because datastore is not a relational database, it is a little "too slow" to perform common total number operations. Therefore, it is best to use the sharded counters technology recommended by Google to calculate the total number.
- Because blobstore is just out of the test phase, and other modules do not support static files (such as slice), for example, datastore only supports objects within 1 MB, at the same time, each application can only upload up to one thousand files, and the speed is not optimal. Therefore, we recommend that you use other professional cloud storage products, such as Amazon S3 or Google storage, which will be launched soon.
- Try to use the batch processing method, whether it is using datastore or sending emails.
- Do not manually create an index: Because App Engine automatically creates an index based on your query in the code.
Applicable scenarios
Currently, app engne is applicable to the following three scenarios:
- Web Hosting: This is the most common scenario. Hundreds of thousands of small websites have been deployed on the App Engine (many of which are mainly for the purpose of learning ), some websites with high traffic bursts have also been deployed. The most famous example is the White House's "open for questions" website, which is mainly used to ask questions from the American people to President Obama, in just a few hours, this site handles nearly millions of traffic.
- Rest service: this is also a common scenario on the App Engine platform. The most famous example is buddypoke. The client of buddypoke is a flash application that runs on your browser, its server is placed on the app engine in the form of a rest service. Whenever the flash client needs to read and store data, it will send a request to the back-end rest service, to perform related datastore operations.
- Applications that rely on the Google service: for example, applications can send large-scale emails through the email service of the App Engine.
Future Expectations
- More stable performance, less timeout exceptions and faster response speed, especially in datastore and memcached.
- Supports data center selection. Although the App Engine will adjust the data center where the application is located based on the user group of the application, the entire process is uncontrollable for developers, therefore, we hope that users can select their own data centers when creating applications.
- SLA. If the App Engine can set some SLA terms like S3, users can deploy applications on the App Engine with greater confidence.
- New languages: such as PHP. However, if you add a new language to the existing App Engine architecture, the workload will be very high, because nearly half of App Engine modules are language-specific, such as application servers and development environments, I think it is unlikely to support new languages in the short term.
In general, Google App Engine is an integral part of Google's big strategy, because Google hopes to reduce the difficulty of Web application development through App Engine, as long as the difficulty is reduced, the overall speed of replacing client applications with Web applications will be accelerated. If such a situation occurs, it will be very advantageous for the future development of Google.
This series of articles is over.
References:
- Google's dr. Kai-fu Lee on cloud computing
- The cost of latency
- Google App Engine blog
- Bigtable: a distributed storage system for structured data
- From Spark Plug to drive train: life of an App Engine request
- Google External Store
- Google App Engine official documentation
- Google Architecture
- Google App Engine-a first look
- Google chose jetty for App Engine
- Google App Engine is down-Backup Data Center having problems
- Cloud Services for virtual infrastructure, Part 1: Platform as a service (PAAs) and appscale
- Uploading: Google is developing a new Server File System
- Google File System
- Designs, lessons and advice from building large Distributed Systems
- The chubby lock service for loosely-coupled distributed systems
- Google's will power and data center Efficiency
- Mapreduce
- Mapreduce Thesis
- Introduction to Protocol Buffer
- Google data centers snub Africa, Oz, and anything near Wyoming or do they?
- Google secrets server Innovation Technology built-in battery replacement UPS
- Share nothing)
- Google File System II: Dawn of the multiplying master nodes
- Transactions internal SS datacenters
- Exploring Google's global data centers and Chinese data centers
- Unveil the five secrets of Google's data center
- Google data centers in Oregon consume amazing power
- Google App Engine for Java-microblogging Case Study
- Under the covers of the App Engine datastore
- Google External Store
- External Store/bigtable replication article
-- EOF--
