[google-appengine] Is there any java library that will get the current facebook/yahoo/yammer logged-in user?
Hi, I am using gaej web application. I am trying to put facebook authentication along with the google. If it is google then I was able to get the current logged-in user through the userService. Now, how would I get the current user, If he has logged-in through facebook. Is there any common library like userService in java, which is used to get the current logged-in user through all the service providers like google, facebook, yahoo etc. Any suggestions would be appreciated. -- Thanks Regards Sarath U -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Re: Snapchat
I would like to see Snapchat numbers. On Tuesday, 21 January 2014 20:33:38 UTC-2, Rafael Sanches wrote: Jim, It seems you're talking from a point of view of a big corporation. Since snapchat didn't had big funding since short time ago, I was supposed we're talking about startups. Big corporations are another beast where server costs are irrelevant in it's sea of other useless costs and lazy people. I am talking from the point of view of a startup that struggles with cash flow and find itself obligated to raise capital just to pay server costs. I don't know why some people think I am insulting their family when I say that appengine is very expensive for high traffic apps. Can you give me an example where it's not expensive? I am giving my own because I've built high traffic services for appengine, aws, hetzner, rackspace etc. Is geographically dispersed services an essential feature for a startup? It's simple till you complicate it. thanks rafa On Tue, Jan 21, 2014 at 1:50 PM, Jim jeb6...@gmail.com javascript:wrote: Yes, I'm quite aware of the various cloud stacks out there and have worked on projects using several of them including AWS and CloudStack. Glad to see you're moving away from your $50 a month claim and it's now at 10 X $50 a month. Now let's talk about geographically dispersed services with automated fail-over. Then let's talk about what that good engineer you have costs you. You really want to run your business on a platform with a single engineer behind it? Does he/she get to sleep or go on vacation? What happens when he/she quits? You sure that cheap little hosting provider has the network bandwidth and resiliency you are going to need? Now triple your infrastructure to be able to handle the hoped-for huge spike in volume. Now crunch the numbers again and tell me what the savings really is. It ain't anywhere close to $3,950 a month, that I am sure of. On Tuesday, January 21, 2014 1:58:56 PM UTC-6, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with: http://c1.picmix.net/61757192=s682=h300or http://c1.picmix.net/61757192=s300=h600 By the way, another way to reduce server costs is to pay the $400 or $200 a month in support. That way you get access to discounted instance hours. It decreased our bill a bit and give access to a place to get feedback when appengine is having problems or when you need to tweak your scheduling and performance parameters that you don't have access from XML config. About three months ago I spent a whole month optimizing my servers to reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for the performance it's delivering. thanks rafa On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral kaan...@gmail.com wrote: I think he gets it much more than you give him credit for Hetzner example, as I interpret it, and think about it myself, is about the price of computing/ram/bandwith, although it's not comparable 1:1, it's important to know how cheap computing and hosting has become over the years, especially in this last 5-10 years It was really interesting to hear about your story Rafael, it was the approximate reason why I started this discussion, to learn and speculate about major services The 2000$ to 300$ cdn comparison is interesting, however no other service that I know of matches the extreme capabilities of google images service I use the =s/-c resizing/cropping extensively, that's why I could never easily replace appengine, or the cdn You seem to have lived my worst case scenario, going out of money and having to ask others for money. Anyway if you don't mind it would be great to learn more about your product/story, but I'm guessing it's better to keep things as private as possible :) On Tuesday, January 21, 2014 9:16:18 PM UTC+2, Jim wrote: 1970's? What on earth about my post made you think of the 1970's? My description of geographically redundant, web based applications? Please indeed. The link you provided is for a LAMP hosting service... basically what I described in my third scenario about. That's apples-vs-oranges as compared to GAE. I suggest you consult with the Application Architects where you work and politely ask them to describe the differences to you.
Re: [google-appengine] Re: Snapchat
:) haha. That's true!!! Some people think we are insulting their family when we say that google app engine is very expensive telling oh, I am a developer with hundred of years of experience C'mon guys: open your eyes Google app engine is very expensive for companies that are beginning On Jan 22, 2014 10:20 AM, Alexandre Cassimiro Andreani alexandre.c.andre...@gmail.com wrote: I would like to see Snapchat numbers. On Tuesday, 21 January 2014 20:33:38 UTC-2, Rafael Sanches wrote: Jim, It seems you're talking from a point of view of a big corporation. Since snapchat didn't had big funding since short time ago, I was supposed we're talking about startups. Big corporations are another beast where server costs are irrelevant in it's sea of other useless costs and lazy people. I am talking from the point of view of a startup that struggles with cash flow and find itself obligated to raise capital just to pay server costs. I don't know why some people think I am insulting their family when I say that appengine is very expensive for high traffic apps. Can you give me an example where it's not expensive? I am giving my own because I've built high traffic services for appengine, aws, hetzner, rackspace etc. Is geographically dispersed services an essential feature for a startup? It's simple till you complicate it. thanks rafa On Tue, Jan 21, 2014 at 1:50 PM, Jim jeb6...@gmail.com wrote: Yes, I'm quite aware of the various cloud stacks out there and have worked on projects using several of them including AWS and CloudStack. Glad to see you're moving away from your $50 a month claim and it's now at 10 X $50 a month. Now let's talk about geographically dispersed services with automated fail-over. Then let's talk about what that good engineer you have costs you. You really want to run your business on a platform with a single engineer behind it? Does he/she get to sleep or go on vacation? What happens when he/she quits? You sure that cheap little hosting provider has the network bandwidth and resiliency you are going to need? Now triple your infrastructure to be able to handle the hoped-for huge spike in volume. Now crunch the numbers again and tell me what the savings really is. It ain't anywhere close to $3,950 a month, that I am sure of. On Tuesday, January 21, 2014 1:58:56 PM UTC-6, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with: http://c1.picmix.net/61757192=s682=h300or http://c1.picmix.net/61757192=s300=h600 By the way, another way to reduce server costs is to pay the $400 or $200 a month in support. That way you get access to discounted instance hours. It decreased our bill a bit and give access to a place to get feedback when appengine is having problems or when you need to tweak your scheduling and performance parameters that you don't have access from XML config. About three months ago I spent a whole month optimizing my servers to reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for the performance it's delivering. thanks rafa On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral kaan...@gmail.com wrote: I think he gets it much more than you give him credit for Hetzner example, as I interpret it, and think about it myself, is about the price of computing/ram/bandwith, although it's not comparable 1:1, it's important to know how cheap computing and hosting has become over the years, especially in this last 5-10 years It was really interesting to hear about your story Rafael, it was the approximate reason why I started this discussion, to learn and speculate about major services The 2000$ to 300$ cdn comparison is interesting, however no other service that I know of matches the extreme capabilities of google images service I use the =s/-c resizing/cropping extensively, that's why I could never easily replace appengine, or the cdn You seem to have lived my worst case scenario, going out of money and having to ask others for money. Anyway if you don't mind it would be great to learn more about your product/story, but I'm guessing it's better to keep things as private as possible :) On Tuesday, January 21, 2014 9:16:18 PM UTC+2, Jim wrote: 1970's? What on earth about my post made you think of the 1970's? My description of geographically redundant, web based applications?
Re: [google-appengine] Re: Snapchat
Rafa, You are correct that I have a lot of large corporate experience, working for good sized commercial software houses. That's where I had the pleasure of building these sorts of highly available, scalable, secure, etc platforms from the ground up to host products my teams built. That's why I know how hard, time consuming and expensive it can be to build something that begins to approach what GAE offers. But I have also worked in two start-ups. One early in my career and now for the past three years running my own. We're using GAE now and I would not consider it 'expensive' because we do want and need the things that it offers. I don't want to build on generic LAMP stack and be at the mercy of a handful of machines in a rented data center and have to pay a couple of systems engineers when I could pay application developers instead who are going to bring new functionality to my products. To me, new functionality equals value...systems engineering is something I want to outsource to Google. It's something they've proven themselves to be incredibly good at. We're a very lean startup and I want ALL of our resources focused either directly on our Customers or directly on software functionality that will directly benefit our Customers. To me, anything else is extraneous and will be outsourced to somebody who can do it better. In Austin, TX I can't even begin to hire a single really good systems engineer for what I'm paying Google, and with our business model even when we're blowing out our revenue projections we won't even be close then. But then that's me, our requirements, and our application profile. I'm not insulted, I'm just try to stimulate a more meaningful conversation than blanket statements that don't take into account all of the real factors involved in such a complex decision. By the way, you never answered my questions about what your engineers cost and how that impacts your capital issues. I have a hard time believing the time/value your engineering staff spends setting up, configuring, managing and monitoring machines doesn't exceed $48,000 per year. Is geographically dispersed essential? Well yeah, if you believe, like I do, that you engineer things right from the beginning. I've been building large, complex software products for a LONG time and I've found that it's very hard to come back and fix or re-do things after the momentum gets going. Once things get rolling there will always be many competing demands and telling the CEO that you've got to put the brakes on the product roadmap for six months so you can migrate to a different stack/data-center can be a career-shortening conversation. If you believe your customers will demand a solution that is engineered for scalability and resiliency and fault-tolerance, then running in distributed data centers is essential. Maybe not back in the 1970's, but in this century and decade anyway. Jim On Tuesday, January 21, 2014 4:33:38 PM UTC-6, Rafael Sanches wrote: Jim, It seems you're talking from a point of view of a big corporation. Since snapchat didn't had big funding since short time ago, I was supposed we're talking about startups. Big corporations are another beast where server costs are irrelevant in it's sea of other useless costs and lazy people. I am talking from the point of view of a startup that struggles with cash flow and find itself obligated to raise capital just to pay server costs. I don't know why some people think I am insulting their family when I say that appengine is very expensive for high traffic apps. Can you give me an example where it's not expensive? I am giving my own because I've built high traffic services for appengine, aws, hetzner, rackspace etc. Is geographically dispersed services an essential feature for a startup? It's simple till you complicate it. thanks rafa On Tue, Jan 21, 2014 at 1:50 PM, Jim jeb6...@gmail.com javascript:wrote: Yes, I'm quite aware of the various cloud stacks out there and have worked on projects using several of them including AWS and CloudStack. Glad to see you're moving away from your $50 a month claim and it's now at 10 X $50 a month. Now let's talk about geographically dispersed services with automated fail-over. Then let's talk about what that good engineer you have costs you. You really want to run your business on a platform with a single engineer behind it? Does he/she get to sleep or go on vacation? What happens when he/she quits? You sure that cheap little hosting provider has the network bandwidth and resiliency you are going to need? Now triple your infrastructure to be able to handle the hoped-for huge spike in volume. Now crunch the numbers again and tell me what the savings really is. It ain't anywhere close to $3,950 a month, that I am sure of. On Tuesday, January 21, 2014 1:58:56 PM UTC-6, Rafael Sanches wrote: Jim, In 2014 a
Re: [google-appengine] Is there any java library that will get the current facebook/yahoo/yammer logged-in user?
Hello, Unfortunately, facebook is not an OpenId provider (they user their own-baked opeinId like mechanism called facebook connect). the AppEngine UserService can track openId providers logins, but not facebook connect ;) I think your best option is to make your own user-check mechanism. Im not using the UserService for exactly the same reason, and make my own ExtendedUserService classes. Good luck! Alejandro González Rodrigo *www.nextinit.com* https://www.nextinit.com/ *alejandro.gonza...@nextinit.com alejandro.gonza...@nextinit.com* *+34 666 57 79 13* 2014/1/22 sarath upadrista sar...@veersoftsolutions.com Hi, I am using gaej web application. I am trying to put facebook authentication along with the google. If it is google then I was able to get the current logged-in user through the userService. Now, how would I get the current user, If he has logged-in through facebook. Is there any common library like userService in java, which is used to get the current logged-in user through all the service providers like google, facebook, yahoo etc. Any suggestions would be appreciated. -- Thanks Regards Sarath U -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] How can I use java.io.File(filePath) in AppEngine?
What you mean when say then read file normally is that I can use the same new ava.io.File(filePath) function? I guess this line: *InputStream stream = this.getServletContext().getResourceAsStream(path);* is only to collect the inputsream that you refer, but I don't use *stream * variable? El martes, 21 de enero de 2014 22:39:14 UTC-6, Vinny P escribió: On Tue, Jan 21, 2014 at 3:55 PM, Juan de Dios Becerra j.bece...@gmail.comjavascript: wrote: I am trying to use Google + Domains API in GAE, but when I try to create a GoogleCredential I need to use this: .setServiceAccountPrivateKeyFromP12File(new java.io.File(filePath)) Where filePath is a .p12 extension file(private key for authentication) this file I put in WEB-INF folder and I granted permissions to all, but when I try to create the GoogleCredential I get this error: java.security.AccessControlException: access denied (java.io.FilePermission /WEB-INF/file.p12 read) Obviously the file has the correct name in my folder, this process works in my project which is not AppEngine, so I guess is a problem in the way to access files in AppEngine using java.io.File. Java I/O classes, such as File, are limited on App Engine. Try using ServletContext's stream services to collect an inputstream, then read the file normally. For example: *InputStream stream = this.getServletContext().getResourceAsStream(path);* - -Vinny P Technology Media Advisor Chicago, IL App Engine Code Samples: http://www.learntogoogleit.com -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] How can I use java.io.File(filePath) in AppEngine?
Hello Juan, maybe with an example is more clear: URI keyURL; String fileName = google_bigq.p12; keyURL = BigQueryAPIManager.class.getClassLoader().getResource(fileName).toURI(); GoogleCredential credential = new GoogleCredential.Builder().setTransport(TRANSPORT) .setJsonFactory(JSON_FACTORY) .setServiceAccountId(EMAIL_ID) .setServiceAccountScopes(SCOPES) .setServiceAccountPrivateKeyFromP12File(new File(keyURL)) .build(); Regards, Alejandro Alejandro González Rodrigo *www.nextinit.com* https://www.nextinit.com/ *alejandro.gonza...@nextinit.com alejandro.gonza...@nextinit.com* *+34 666 57 79 13* 2014/1/22 Juan de Dios Becerra j.becerra4...@gmail.com What you mean when say then read file normally is that I can use the same new ava.io.File(filePath) function? I guess this line: *InputStream stream = this.getServletContext().getResourceAsStream(path);* is only to collect the inputsream that you refer, but I don't use *stream *variable? El martes, 21 de enero de 2014 22:39:14 UTC-6, Vinny P escribió: On Tue, Jan 21, 2014 at 3:55 PM, Juan de Dios Becerra j.bece...@gmail. com wrote: I am trying to use Google + Domains API in GAE, but when I try to create a GoogleCredential I need to use this: .setServiceAccountPrivateKeyFromP12File(new java.io.File(filePath)) Where filePath is a .p12 extension file(private key for authentication) this file I put in WEB-INF folder and I granted permissions to all, but when I try to create the GoogleCredential I get this error: java.security.AccessControlException: access denied (java.io.FilePermission /WEB-INF/file.p12 read) Obviously the file has the correct name in my folder, this process works in my project which is not AppEngine, so I guess is a problem in the way to access files in AppEngine using java.io.File. Java I/O classes, such as File, are limited on App Engine. Try using ServletContext's stream services to collect an inputstream, then read the file normally. For example: *InputStream stream = this.getServletContext().getResourceAsStream(path);* - -Vinny P Technology Media Advisor Chicago, IL App Engine Code Samples: http://www.learntogoogleit.com -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Re: Snapchat
I'm the only engineer working on backend, so I pay $0 per year to configure, manage and monitor machines. Startups don't have cash to hire systems engineers. In my startup I'm an engineer, not a systems engineer or software engineer or bathroom cleaner engineer. If people can build code complex code, why they can't build scripts to automate the cloud configuration? Most people have those already built from past jobs anyway. It seems that you are taking a defensive position from a strict engineer perspective. For a startup to succeed, you might find yourself doing tasks from cleaning bathrooms, sys admin, community management among other things. Paying more now so you don't get fired in the future might not be the best option for a startup. cheers, rafa On Wed, Jan 22, 2014 at 5:24 AM, Jim jeb62...@gmail.com wrote: Rafa, You are correct that I have a lot of large corporate experience, working for good sized commercial software houses. That's where I had the pleasure of building these sorts of highly available, scalable, secure, etc platforms from the ground up to host products my teams built. That's why I know how hard, time consuming and expensive it can be to build something that begins to approach what GAE offers. But I have also worked in two start-ups. One early in my career and now for the past three years running my own. We're using GAE now and I would not consider it 'expensive' because we do want and need the things that it offers. I don't want to build on generic LAMP stack and be at the mercy of a handful of machines in a rented data center and have to pay a couple of systems engineers when I could pay application developers instead who are going to bring new functionality to my products. To me, new functionality equals value...systems engineering is something I want to outsource to Google. It's something they've proven themselves to be incredibly good at. We're a very lean startup and I want ALL of our resources focused either directly on our Customers or directly on software functionality that will directly benefit our Customers. To me, anything else is extraneous and will be outsourced to somebody who can do it better. In Austin, TX I can't even begin to hire a single really good systems engineer for what I'm paying Google, and with our business model even when we're blowing out our revenue projections we won't even be close then. But then that's me, our requirements, and our application profile. I'm not insulted, I'm just try to stimulate a more meaningful conversation than blanket statements that don't take into account all of the real factors involved in such a complex decision. By the way, you never answered my questions about what your engineers cost and how that impacts your capital issues. I have a hard time believing the time/value your engineering staff spends setting up, configuring, managing and monitoring machines doesn't exceed $48,000 per year. Is geographically dispersed essential? Well yeah, if you believe, like I do, that you engineer things right from the beginning. I've been building large, complex software products for a LONG time and I've found that it's very hard to come back and fix or re-do things after the momentum gets going. Once things get rolling there will always be many competing demands and telling the CEO that you've got to put the brakes on the product roadmap for six months so you can migrate to a different stack/data-center can be a career-shortening conversation. If you believe your customers will demand a solution that is engineered for scalability and resiliency and fault-tolerance, then running in distributed data centers is essential. Maybe not back in the 1970's, but in this century and decade anyway. Jim On Tuesday, January 21, 2014 4:33:38 PM UTC-6, Rafael Sanches wrote: Jim, It seems you're talking from a point of view of a big corporation. Since snapchat didn't had big funding since short time ago, I was supposed we're talking about startups. Big corporations are another beast where server costs are irrelevant in it's sea of other useless costs and lazy people. I am talking from the point of view of a startup that struggles with cash flow and find itself obligated to raise capital just to pay server costs. I don't know why some people think I am insulting their family when I say that appengine is very expensive for high traffic apps. Can you give me an example where it's not expensive? I am giving my own because I've built high traffic services for appengine, aws, hetzner, rackspace etc. Is geographically dispersed services an essential feature for a startup? It's simple till you complicate it. thanks rafa On Tue, Jan 21, 2014 at 1:50 PM, Jim jeb6...@gmail.com wrote: Yes, I'm quite aware of the various cloud stacks out there and have worked on projects using several of them including AWS and CloudStack. Glad to see you're moving away from
Re: [google-appengine] Re: Snapchat
Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes. For image heavy apps the difference really adds up... especially for mobile. My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated): https://code.google.com/p/googleappengine/issues/detail?id=9979 On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with: http://c1.picmix.net/61757192=s682=h300 or http://c1.picmix.net/61757192=s300=h600 By the way, another way to reduce server costs is to pay the $400 or $200 a month in support. That way you get access to discounted instance hours. It decreased our bill a bit and give access to a place to get feedback when appengine is having problems or when you need to tweak your scheduling and performance parameters that you don't have access from XML config. About three months ago I spent a whole month optimizing my servers to reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for the performance it's delivering. thanks rafa On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral kaan...@gmail.comjavascript: wrote: I think he gets it much more than you give him credit for Hetzner example, as I interpret it, and think about it myself, is about the price of computing/ram/bandwith, although it's not comparable 1:1, it's important to know how cheap computing and hosting has become over the years, especially in this last 5-10 years It was really interesting to hear about your story Rafael, it was the approximate reason why I started this discussion, to learn and speculate about major services The 2000$ to 300$ cdn comparison is interesting, however no other service that I know of matches the extreme capabilities of google images service I use the =s/-c resizing/cropping extensively, that's why I could never easily replace appengine, or the cdn You seem to have lived my worst case scenario, going out of money and having to ask others for money. Anyway if you don't mind it would be great to learn more about your product/story, but I'm guessing it's better to keep things as private as possible :) On Tuesday, January 21, 2014 9:16:18 PM UTC+2, Jim wrote: 1970's? What on earth about my post made you think of the 1970's? My description of geographically redundant, web based applications? Please indeed. The link you provided is for a LAMP hosting service... basically what I described in my third scenario about. That's apples-vs-oranges as compared to GAE. I suggest you consult with the Application Architects where you work and politely ask them to describe the differences to you. Clearly nobody here is getting through to you and I don't have the time or the inclination. On Tuesday, January 21, 2014 12:35:13 AM UTC-6, Rafael Sanches wrote: Guys, Please, we're not in 1970 anymore. There is no argue that appengine is the most expensive hosting on earth and possibly the universe. My company spend $4000 a month with appengine. We could host the same service with $50 in a more powerful environment: http://www.hetzner.de/en/hosting/produktmatrix/ rootserver-produktmatrix-exhttp://www.google.com/url?q=http%3A%2F%2Fwww.hetzner.de%2Fen%2Fhosting%2Fproduktmatrix%2Frootserver-produktmatrix-exsa=Dsntz=1usg=AFQjCNHB4pohCO2ZKGcxoTG5sY0nc6pvDw With $300 we could make it redundant and more reliable and faster than appengine. A dedicated server is also more reliable, because of appengine infamous hicupps due to its scheduling system and instance boot time. In one of my services I rent a rack with 20 spaces and it's filled with only 10 severs. It means I can scale my servers with 10 more. That configuration costs $1000.
Re: [google-appengine] How can I use java.io.File(filePath) in AppEngine?
This is how we load it during our DI phase: String certificate = /someuniqueid-privatekey.p12; File privateKey = new File(getClass().getResource(certificate).toURI()); ... builder.setServiceAccountPrivateKeyFromP12File(privateKey); In this example, the p12 file is in our src/main/resources. On Thursday, January 23, 2014 2:33:43 AM UTC+11, Alejandro Gonzalez wrote: Hello Juan, maybe with an example is more clear: URI keyURL; String fileName = google_bigq.p12; keyURL = BigQueryAPIManager.class.getClassLoader().getResource(fileName).toURI(); GoogleCredential credential = new GoogleCredential.Builder().setTransport(TRANSPORT) .setJsonFactory(JSON_FACTORY) .setServiceAccountId(EMAIL_ID) .setServiceAccountScopes(SCOPES) .setServiceAccountPrivateKeyFromP12File(new File(keyURL)) .build(); Regards, Alejandro Alejandro González Rodrigo *www.nextinit.com* https://www.nextinit.com/ *alejandro...@nextinit.com javascript:* * +34 666 57 79 13* 2014/1/22 Juan de Dios Becerra j.bece...@gmail.com javascript: What you mean when say then read file normally is that I can use the same new ava.io.File(filePath) function? I guess this line: *InputStream stream = this.getServletContext().getResourceAsStream(path);* is only to collect the inputsream that you refer, but I don't use *stream *variable? El martes, 21 de enero de 2014 22:39:14 UTC-6, Vinny P escribió: On Tue, Jan 21, 2014 at 3:55 PM, Juan de Dios Becerra j.bece...@gmail. com wrote: I am trying to use Google + Domains API in GAE, but when I try to create a GoogleCredential I need to use this: .setServiceAccountPrivateKeyFromP12File(new java.io.File(filePath)) Where filePath is a .p12 extension file(private key for authentication) this file I put in WEB-INF folder and I granted permissions to all, but when I try to create the GoogleCredential I get this error: java.security.AccessControlException: access denied (java.io.FilePermission /WEB-INF/file.p12 read) Obviously the file has the correct name in my folder, this process works in my project which is not AppEngine, so I guess is a problem in the way to access files in AppEngine using java.io.File. Java I/O classes, such as File, are limited on App Engine. Try using ServletContext's stream services to collect an inputstream, then read the file normally. For example: *InputStream stream = this.getServletContext().getResourceAsStream(path);* - -Vinny P Technology Media Advisor Chicago, IL App Engine Code Samples: http://www.learntogoogleit.com -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com javascript:. To post to this group, send email to google-a...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Re: Snapchat
Doug, Does that behaviour also happens in production? Compare prod vs dev. That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting. thanks rafa On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson d...@claystreet.com wrote: Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes. For image heavy apps the difference really adds up... especially for mobile. My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated): https://code.google.com/p/googleappengine/issues/detail?id=9979 On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with: http://c1.picmix.net/61757192=s682=h300or http://c1.picmix.net/61757192=s300=h600 By the way, another way to reduce server costs is to pay the $400 or $200 a month in support. That way you get access to discounted instance hours. It decreased our bill a bit and give access to a place to get feedback when appengine is having problems or when you need to tweak your scheduling and performance parameters that you don't have access from XML config. About three months ago I spent a whole month optimizing my servers to reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for the performance it's delivering. thanks rafa On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral kaan...@gmail.com wrote: I think he gets it much more than you give him credit for Hetzner example, as I interpret it, and think about it myself, is about the price of computing/ram/bandwith, although it's not comparable 1:1, it's important to know how cheap computing and hosting has become over the years, especially in this last 5-10 years It was really interesting to hear about your story Rafael, it was the approximate reason why I started this discussion, to learn and speculate about major services The 2000$ to 300$ cdn comparison is interesting, however no other service that I know of matches the extreme capabilities of google images service I use the =s/-c resizing/cropping extensively, that's why I could never easily replace appengine, or the cdn You seem to have lived my worst case scenario, going out of money and having to ask others for money. Anyway if you don't mind it would be great to learn more about your product/story, but I'm guessing it's better to keep things as private as possible :) On Tuesday, January 21, 2014 9:16:18 PM UTC+2, Jim wrote: 1970's? What on earth about my post made you think of the 1970's? My description of geographically redundant, web based applications? Please indeed. The link you provided is for a LAMP hosting service... basically what I described in my third scenario about. That's apples-vs-oranges as compared to GAE. I suggest you consult with the Application Architects where you work and politely ask them to describe the differences to you. Clearly nobody here is getting through to you and I don't have the time or the inclination. On Tuesday, January 21, 2014 12:35:13 AM UTC-6, Rafael Sanches wrote: Guys, Please, we're not in 1970 anymore. There is no argue that appengine is the most expensive hosting on earth and possibly the universe. My company spend $4000 a month with appengine. We could host the same service with $50 in a more powerful environment: http://www.hetzner.de/en/hosting/produktmatrix/rootserver- produktmatrix-exhttp://www.google.com/url?q=http%3A%2F%2Fwww.hetzner.de%2Fen%2Fhosting%2Fproduktmatrix%2Frootserver-produktmatrix-exsa=Dsntz=1usg=AFQjCNHB4pohCO2ZKGcxoTG5sY0nc6pvDw With $300 we could make it redundant and more reliable and faster than appengine. A dedicated
Re: [google-appengine] Re: Snapchat
Yes, the tests I conducted were on the production server. I'd even be content if the resized images used the same default (quality=85) as the Images service. A switch to a more reasonable default would instantly cut all dynamically served images to nearly 1/2 the size... that must be significant bandwidth even for Google. It's either an oversight on Google's part OR they deliberately chose not to utilize the extra CPU bandwidth required for additional compression (???). Serving yourself allows additional flexibility (such as in your gist) but you don't get the cost benefits of the dynamic image service (no CPU charges) On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote: Doug, Does that behaviour also happens in production? Compare prod vs dev. That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting. thanks rafa On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson do...@claystreet.comjavascript: wrote: Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes. For image heavy apps the difference really adds up... especially for mobile. My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated): https://code.google.com/p/googleappengine/issues/detail?id=9979 On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with: http://c1.picmix.net/61757192=s682=h300or http://c1.picmix.net/61757192=s300=h600 By the way, another way to reduce server costs is to pay the $400 or $200 a month in support. That way you get access to discounted instance hours. It decreased our bill a bit and give access to a place to get feedback when appengine is having problems or when you need to tweak your scheduling and performance parameters that you don't have access from XML config. About three months ago I spent a whole month optimizing my servers to reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for the performance it's delivering. thanks rafa On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral kaan...@gmail.com wrote: I think he gets it much more than you give him credit for Hetzner example, as I interpret it, and think about it myself, is about the price of computing/ram/bandwith, although it's not comparable 1:1, it's important to know how cheap computing and hosting has become over the years, especially in this last 5-10 years It was really interesting to hear about your story Rafael, it was the approximate reason why I started this discussion, to learn and speculate about major services The 2000$ to 300$ cdn comparison is interesting, however no other service that I know of matches the extreme capabilities of google images service I use the =s/-c resizing/cropping extensively, that's why I could never easily replace appengine, or the cdn You seem to have lived my worst case scenario, going out of money and having to ask others for money. Anyway if you don't mind it would be great to learn more about your product/story, but I'm guessing it's better to keep things as private as possible :) On Tuesday, January 21, 2014 9:16:18 PM UTC+2, Jim wrote: 1970's? What on earth about my post made you think of the 1970's? My description of geographically redundant, web based applications? Please indeed. The link you provided is for a LAMP hosting service... basically what I described in my third scenario about. That's apples-vs-oranges as compared to GAE. I suggest you consult with the Application Architects where you work and politely ask them to describe the
Re: [google-appengine] Re: Snapchat
Hi Doug, Just correcting your phrase a little bit: that must be significant bandwidth even for *YOU* We've cut thousands of dollars out of our total bill by serving the images ourselves, through a real cdn. Appengine output bandwidth is much more expensive than almost any other cdn out there. Again, keeping this thread on topic, my advices only make sense if you have your server bills are in the thousands and are struggling with server costs. If you're an early stage startup with $100 bill or an overfunded startup or a big corporation, who cares? :) thanks rafa On Wed, Jan 22, 2014 at 3:53 PM, Doug Anderson d...@claystreet.com wrote: Yes, the tests I conducted were on the production server. I'd even be content if the resized images used the same default (quality=85) as the Images service. A switch to a more reasonable default would instantly cut all dynamically served images to nearly 1/2 the size... that must be significant bandwidth even for Google. It's either an oversight on Google's part OR they deliberately chose not to utilize the extra CPU bandwidth required for additional compression (???). Serving yourself allows additional flexibility (such as in your gist) but you don't get the cost benefits of the dynamic image service (no CPU charges) On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote: Doug, Does that behaviour also happens in production? Compare prod vs dev. That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting. thanks rafa On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson do...@claystreet.comwrote: Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes. For image heavy apps the difference really adds up... especially for mobile. My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated): https://code.google.com/p/googleappengine/issues/detail?id=9979 On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with: http://c1.picmix.net/61757192=s682=h300or http://c1.picmix.net/61757192=s300=h600 By the way, another way to reduce server costs is to pay the $400 or $200 a month in support. That way you get access to discounted instance hours. It decreased our bill a bit and give access to a place to get feedback when appengine is having problems or when you need to tweak your scheduling and performance parameters that you don't have access from XML config. About three months ago I spent a whole month optimizing my servers to reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for the performance it's delivering. thanks rafa On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral kaan...@gmail.com wrote: I think he gets it much more than you give him credit for Hetzner example, as I interpret it, and think about it myself, is about the price of computing/ram/bandwith, although it's not comparable 1:1, it's important to know how cheap computing and hosting has become over the years, especially in this last 5-10 years It was really interesting to hear about your story Rafael, it was the approximate reason why I started this discussion, to learn and speculate about major services The 2000$ to 300$ cdn comparison is interesting, however no other service that I know of matches the extreme capabilities of google images service I use the =s/-c resizing/cropping extensively, that's why I could never easily replace appengine, or the cdn You seem to have lived my worst case scenario, going out of money and having to ask others for money. Anyway if you don't mind it would be great to learn more about
Re: [google-appengine] Re: Snapchat
I assume he caches the images somehow, might even be possible with appengine's services, pagecache etc. however I haven't looked into them, but I'm sure an external service could handle it easily - although I would definitely keep the simplicity of google's images service instead of going the manual route, although at a future point it might be doable On Thursday, January 23, 2014 1:53:12 AM UTC+2, Doug Anderson wrote: Yes, the tests I conducted were on the production server. I'd even be content if the resized images used the same default (quality=85) as the Images service. A switch to a more reasonable default would instantly cut all dynamically served images to nearly 1/2 the size... that must be significant bandwidth even for Google. It's either an oversight on Google's part OR they deliberately chose not to utilize the extra CPU bandwidth required for additional compression (???). Serving yourself allows additional flexibility (such as in your gist) but you don't get the cost benefits of the dynamic image service (no CPU charges) On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote: Doug, Does that behaviour also happens in production? Compare prod vs dev. That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting. thanks rafa On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson do...@claystreet.comwrote: Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes. For image heavy apps the difference really adds up... especially for mobile. My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated): https://code.google.com/p/googleappengine/issues/detail?id=9979 On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with: http://c1.picmix.net/61757192=s682=h300or http://c1.picmix.net/61757192=s300=h600 By the way, another way to reduce server costs is to pay the $400 or $200 a month in support. That way you get access to discounted instance hours. It decreased our bill a bit and give access to a place to get feedback when appengine is having problems or when you need to tweak your scheduling and performance parameters that you don't have access from XML config. About three months ago I spent a whole month optimizing my servers to reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for the performance it's delivering. thanks rafa On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral kaan...@gmail.com wrote: I think he gets it much more than you give him credit for Hetzner example, as I interpret it, and think about it myself, is about the price of computing/ram/bandwith, although it's not comparable 1:1, it's important to know how cheap computing and hosting has become over the years, especially in this last 5-10 years It was really interesting to hear about your story Rafael, it was the approximate reason why I started this discussion, to learn and speculate about major services The 2000$ to 300$ cdn comparison is interesting, however no other service that I know of matches the extreme capabilities of google images service I use the =s/-c resizing/cropping extensively, that's why I could never easily replace appengine, or the cdn You seem to have lived my worst case scenario, going out of money and having to ask others for money. Anyway if you don't mind it would be great to learn more about your product/story, but I'm guessing it's better to keep things as private as possible :) On Tuesday, January 21, 2014 9:16:18 PM UTC+2, Jim wrote: 1970's? What
Re: [google-appengine] Re: Snapchat
I wish! ;) On Wed, Jan 22, 2014 at 5:05 PM, Coto Augosto C. c...@me.com wrote: Rafa, do you work for snapchat? On Jan 22, 2014 8:59 PM, Rafael mufumb...@gmail.com wrote: Hi Doug, Just correcting your phrase a little bit: that must be significant bandwidth even for *YOU* We've cut thousands of dollars out of our total bill by serving the images ourselves, through a real cdn. Appengine output bandwidth is much more expensive than almost any other cdn out there. Again, keeping this thread on topic, my advices only make sense if you have your server bills are in the thousands and are struggling with server costs. If you're an early stage startup with $100 bill or an overfunded startup or a big corporation, who cares? :) thanks rafa On Wed, Jan 22, 2014 at 3:53 PM, Doug Anderson d...@claystreet.comwrote: Yes, the tests I conducted were on the production server. I'd even be content if the resized images used the same default (quality=85) as the Images service. A switch to a more reasonable default would instantly cut all dynamically served images to nearly 1/2 the size... that must be significant bandwidth even for Google. It's either an oversight on Google's part OR they deliberately chose not to utilize the extra CPU bandwidth required for additional compression (???). Serving yourself allows additional flexibility (such as in your gist) but you don't get the cost benefits of the dynamic image service (no CPU charges) On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote: Doug, Does that behaviour also happens in production? Compare prod vs dev. That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting. thanks rafa On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson do...@claystreet.comwrote: Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes. For image heavy apps the difference really adds up... especially for mobile. My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated): https://code.google.com/p/googleappengine/issues/detail?id=9979 On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with: http://c1.picmix.net/61757192= s682=h300 or http://c1.picmix.net/61757192=s300=h600 By the way, another way to reduce server costs is to pay the $400 or $200 a month in support. That way you get access to discounted instance hours. It decreased our bill a bit and give access to a place to get feedback when appengine is having problems or when you need to tweak your scheduling and performance parameters that you don't have access from XML config. About three months ago I spent a whole month optimizing my servers to reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for the performance it's delivering. thanks rafa On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral kaan...@gmail.comwrote: I think he gets it much more than you give him credit for Hetzner example, as I interpret it, and think about it myself, is about the price of computing/ram/bandwith, although it's not comparable 1:1, it's important to know how cheap computing and hosting has become over the years, especially in this last 5-10 years It was really interesting to hear about your story Rafael, it was the approximate reason why I started this discussion, to learn and speculate about major services The 2000$ to 300$ cdn comparison is interesting, however no other service that I know of matches the extreme capabilities of google images service I use the =s/-c resizing/cropping extensively, that's why I could never
Re: [google-appengine] Re: Snapchat
I think GAE is trying to remain competitive with Amazon Web Services etc... and not with CDNs. App Engine and Google Cloud Storage *is* competitive with Amazon Cloud Services EXCEPT those services offer tiered pricing (lower prices) for high volume clients... to my knowledge App Engine doesn't offer that (at least not publicly advertised). App Engine isn't much of a CDN as far as I can tell (I don't think that's a prime objective). It would be hard to argue against augmenting with an actual CDN where appropriate. Certainly technologies like Docker and OpenStack go a long way toward helping a lone wolf build a maintainable stack but I think you'll find that if you run that stack on Amazon's cloud (for instance) that GAE pricing *is* competitive. So I would contend that your pricing argument is more of a generic Anyone's Cloud vs Custom Hardware argument. I can certainly save a ton of money by storing data on local hard drives vs the cloud but then I have to worry about redundancy, drive and fan failures, rebuilds, backups etc. If you want multi-site redundancy and/or need rapid scaling/growth costs go up and the cloud starts to look intriguing again. Each (cloud and custom hardware) still has its place imo... On Wednesday, January 22, 2014 6:58:42 PM UTC-5, Rafael Sanches wrote: Hi Doug, Just correcting your phrase a little bit: that must be significant bandwidth even for *YOU* We've cut thousands of dollars out of our total bill by serving the images ourselves, through a real cdn. Appengine output bandwidth is much more expensive than almost any other cdn out there. Again, keeping this thread on topic, my advices only make sense if you have your server bills are in the thousands and are struggling with server costs. If you're an early stage startup with $100 bill or an overfunded startup or a big corporation, who cares? :) thanks rafa On Wed, Jan 22, 2014 at 3:53 PM, Doug Anderson do...@claystreet.comjavascript: wrote: Yes, the tests I conducted were on the production server. I'd even be content if the resized images used the same default (quality=85) as the Images service. A switch to a more reasonable default would instantly cut all dynamically served images to nearly 1/2 the size... that must be significant bandwidth even for Google. It's either an oversight on Google's part OR they deliberately chose not to utilize the extra CPU bandwidth required for additional compression (???). Serving yourself allows additional flexibility (such as in your gist) but you don't get the cost benefits of the dynamic image service (no CPU charges) On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote: Doug, Does that behaviour also happens in production? Compare prod vs dev. That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting. thanks rafa On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson do...@claystreet.comwrote: Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes. For image heavy apps the difference really adds up... especially for mobile. My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated): https://code.google.com/p/googleappengine/issues/detail?id=9979 On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with: http://c1.picmix.net/61757192=s682=h300or http://c1.picmix.net/61757192=s300=h600 By the way, another way to reduce server costs is to pay the $400 or $200 a month in support. That way you get access to discounted instance hours. It
Re: [google-appengine] Re: Snapchat
Doug, I agree. My argument is that, when costs is an issue, most startups can't afford to not be worry about things :) thanks rafa On Wed, Jan 22, 2014 at 5:11 PM, Doug Anderson d...@claystreet.com wrote: I think GAE is trying to remain competitive with Amazon Web Services etc... and not with CDNs. App Engine and Google Cloud Storage *is* competitive with Amazon Cloud Services EXCEPT those services offer tiered pricing (lower prices) for high volume clients... to my knowledge App Engine doesn't offer that (at least not publicly advertised). App Engine isn't much of a CDN as far as I can tell (I don't think that's a prime objective). It would be hard to argue against augmenting with an actual CDN where appropriate. Certainly technologies like Docker and OpenStack go a long way toward helping a lone wolf build a maintainable stack but I think you'll find that if you run that stack on Amazon's cloud (for instance) that GAE pricing *is* competitive. So I would contend that your pricing argument is more of a generic Anyone's Cloud vs Custom Hardware argument. I can certainly save a ton of money by storing data on local hard drives vs the cloud but then I have to worry about redundancy, drive and fan failures, rebuilds, backups etc. If you want multi-site redundancy and/or need rapid scaling/growth costs go up and the cloud starts to look intriguing again. Each (cloud and custom hardware) still has its place imo... On Wednesday, January 22, 2014 6:58:42 PM UTC-5, Rafael Sanches wrote: Hi Doug, Just correcting your phrase a little bit: that must be significant bandwidth even for *YOU* We've cut thousands of dollars out of our total bill by serving the images ourselves, through a real cdn. Appengine output bandwidth is much more expensive than almost any other cdn out there. Again, keeping this thread on topic, my advices only make sense if you have your server bills are in the thousands and are struggling with server costs. If you're an early stage startup with $100 bill or an overfunded startup or a big corporation, who cares? :) thanks rafa On Wed, Jan 22, 2014 at 3:53 PM, Doug Anderson do...@claystreet.comwrote: Yes, the tests I conducted were on the production server. I'd even be content if the resized images used the same default (quality=85) as the Images service. A switch to a more reasonable default would instantly cut all dynamically served images to nearly 1/2 the size... that must be significant bandwidth even for Google. It's either an oversight on Google's part OR they deliberately chose not to utilize the extra CPU bandwidth required for additional compression (???). Serving yourself allows additional flexibility (such as in your gist) but you don't get the cost benefits of the dynamic image service (no CPU charges) On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote: Doug, Does that behaviour also happens in production? Compare prod vs dev. That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting. thanks rafa On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson do...@claystreet.comwrote: Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes. For image heavy apps the difference really adds up... especially for mobile. My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated): https://code.google.com/p/googleappengine/issues/detail?id=9979 On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with: http://c1.picmix.net/61757192= s682=h300 or http://c1.picmix.net/61757192=s300=h600 By
Re: [google-appengine] Re: Snapchat
I believe they are using a very substantial network CDN for serving static content. I think they only charge bandwidth for items served from their CDN. You can always choose to use something else in addition. On Wed, Jan 22, 2014 at 5:11 PM, Doug Anderson d...@claystreet.com wrote: I think GAE is trying to remain competitive with Amazon Web Services etc... and not with CDNs. App Engine and Google Cloud Storage *is* competitive with Amazon Cloud Services EXCEPT those services offer tiered pricing (lower prices) for high volume clients... to my knowledge App Engine doesn't offer that (at least not publicly advertised). App Engine isn't much of a CDN as far as I can tell (I don't think that's a prime objective). It would be hard to argue against augmenting with an actual CDN where appropriate. Certainly technologies like Docker and OpenStack go a long way toward helping a lone wolf build a maintainable stack but I think you'll find that if you run that stack on Amazon's cloud (for instance) that GAE pricing *is* competitive. So I would contend that your pricing argument is more of a generic Anyone's Cloud vs Custom Hardware argument. I can certainly save a ton of money by storing data on local hard drives vs the cloud but then I have to worry about redundancy, drive and fan failures, rebuilds, backups etc. If you want multi-site redundancy and/or need rapid scaling/growth costs go up and the cloud starts to look intriguing again. Each (cloud and custom hardware) still has its place imo... On Wednesday, January 22, 2014 6:58:42 PM UTC-5, Rafael Sanches wrote: Hi Doug, Just correcting your phrase a little bit: that must be significant bandwidth even for *YOU* We've cut thousands of dollars out of our total bill by serving the images ourselves, through a real cdn. Appengine output bandwidth is much more expensive than almost any other cdn out there. Again, keeping this thread on topic, my advices only make sense if you have your server bills are in the thousands and are struggling with server costs. If you're an early stage startup with $100 bill or an overfunded startup or a big corporation, who cares? :) thanks rafa On Wed, Jan 22, 2014 at 3:53 PM, Doug Anderson do...@claystreet.comwrote: Yes, the tests I conducted were on the production server. I'd even be content if the resized images used the same default (quality=85) as the Images service. A switch to a more reasonable default would instantly cut all dynamically served images to nearly 1/2 the size... that must be significant bandwidth even for Google. It's either an oversight on Google's part OR they deliberately chose not to utilize the extra CPU bandwidth required for additional compression (???). Serving yourself allows additional flexibility (such as in your gist) but you don't get the cost benefits of the dynamic image service (no CPU charges) On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote: Doug, Does that behaviour also happens in production? Compare prod vs dev. That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting. thanks rafa On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson do...@claystreet.comwrote: Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes. For image heavy apps the difference really adds up... especially for mobile. My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated): https://code.google.com/p/googleappengine/issues/detail?id=9979 On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. Kaan, This is my gift to you: https://gist.github.com/mufumbo/8547036 It extends all of the appengine image features: =s/-c and includes the most useful one: =h Depending on appengine's image serving is a limitation, since vertical cropping is extremely useful on many elegant websites. For example, play around with:
Re: [google-appengine] Re: Snapchat
Absolutely agree. I used to rely on app engine services more than heroku or other PaaS but now I am disappointed after see that I have been billed for pagespeed while it was disabled and I was billed 3 months for back-end instances type B2 while we had B1. Other issue I had was when our application was down for 2 days and we didn't have a door to report it. We had to paid for gold support ($400) for gold support, I called and they fixed the issue in 3 minutes by restarting the instance. Do we have to pay to fix issues in Google end? I am pretty disappointed now :( On Jan 22, 2014 10:11 PM, Doug Anderson d...@claystreet.com wrote: I think GAE is trying to remain competitive with Amazon Web Services etc... and not with CDNs. App Engine and Google Cloud Storage *is* competitive with Amazon Cloud Services EXCEPT those services offer tiered pricing (lower prices) for high volume clients... to my knowledge App Engine doesn't offer that (at least not publicly advertised). App Engine isn't much of a CDN as far as I can tell (I don't think that's a prime objective). It would be hard to argue against augmenting with an actual CDN where appropriate. Certainly technologies like Docker and OpenStack go a long way toward helping a lone wolf build a maintainable stack but I think you'll find that if you run that stack on Amazon's cloud (for instance) that GAE pricing *is* competitive. So I would contend that your pricing argument is more of a generic Anyone's Cloud vs Custom Hardware argument. I can certainly save a ton of money by storing data on local hard drives vs the cloud but then I have to worry about redundancy, drive and fan failures, rebuilds, backups etc. If you want multi-site redundancy and/or need rapid scaling/growth costs go up and the cloud starts to look intriguing again. Each (cloud and custom hardware) still has its place imo... On Wednesday, January 22, 2014 6:58:42 PM UTC-5, Rafael Sanches wrote: Hi Doug, Just correcting your phrase a little bit: that must be significant bandwidth even for *YOU* We've cut thousands of dollars out of our total bill by serving the images ourselves, through a real cdn. Appengine output bandwidth is much more expensive than almost any other cdn out there. Again, keeping this thread on topic, my advices only make sense if you have your server bills are in the thousands and are struggling with server costs. If you're an early stage startup with $100 bill or an overfunded startup or a big corporation, who cares? :) thanks rafa On Wed, Jan 22, 2014 at 3:53 PM, Doug Anderson do...@claystreet.comwrote: Yes, the tests I conducted were on the production server. I'd even be content if the resized images used the same default (quality=85) as the Images service. A switch to a more reasonable default would instantly cut all dynamically served images to nearly 1/2 the size... that must be significant bandwidth even for Google. It's either an oversight on Google's part OR they deliberately chose not to utilize the extra CPU bandwidth required for additional compression (???). Serving yourself allows additional flexibility (such as in your gist) but you don't get the cost benefits of the dynamic image service (no CPU charges) On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote: Doug, Does that behaviour also happens in production? Compare prod vs dev. That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting. thanks rafa On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson do...@claystreet.comwrote: Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes. For image heavy apps the difference really adds up... especially for mobile. My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated): https://code.google.com/p/googleappengine/issues/detail?id=9979 On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote: Jim, In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested. Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. I am saying it's over priced to run a service like Snapchat. I don't think there's any argument
[google-appengine] Error 503 while uploading
I saw this issue back on December 12th, it lasted a few hours then it went away on its own. I see it again tonight. Tonight is vey disruptive because recaptha servers are down, so many public facing forms in my site are down, and I am trying to urgently upload a patch to disable recaptcha until recaptcha is fixed. What is your experience? Do you see that issue at all/often/more often than before? 06:07 PM Error 503: --- begin server output --- Try Again (503) An unexpected failure has occurred. Please try again. --- end server output --- PK http://www.gae123.com Sorry for interrupting the very intellectual “Snapchat” thread with really mundane stuff…. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Re: Snapchat
App Engine is very cheap for startups. I would even say it's a game-changer. I built two startups before PaaS became an option, and I can say with certainty that App Engine would have saved me millions of dollars each time. Most new applications can happily live within a free quota until they prove to be useful for a significant number of users. A well-built app will have a to serve a whole lot of users before it costs more than $200 per day on App Engine, and that's still cheaper than a single systems engineer or a DBA. I think that App Engine is difficult and expensive for less-experienced or less-qualified developers. Sloppy data models, unnecessary indexes, overly complex queries, unintended dependencies, large third-party libraries for simple tasks, wrong headers on static resources - these mistakes are not always noticeable when you run your own box, given how cheap and powerful the servers are these days. With App Engine these mistakes add up very quickly. On the other hand, App Engine gives you all the information you need to analyze your bill. Once you see that a certain item becomes significant, there are ways to optimize your application in order to reduce costs. I certainly advocate avoiding basic mistakes from day one, but there are certain optimizations that make sense only when volume picks up. For example, you can move a backend task to a Compute Engine instance, which is many times cheaper, but requires more work to set up and manage. Or you can split a complex data entity into two separate entities so that a minor change will not result in multiple datastore writes. Or you can unindex some properties and iterate through query results, saving on writes and data volume. Or you can set the correct chunk size on your queries - something that many developers probably forget to do. And so on. I am working on an app now that loads, processes and indexes 1 million web pages and creates app. 10 million datastore entities for less than $100 in App Engine costs. I don't know what your application does for your users, but that's a whole lot of processing power for a hundred bucks. Once we hit a million users or so, we will move some of our processing load to the Compute Engine, but the effort does not make economic sense before that. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Re: Snapchat
I don't understand why people keep adding DBA or systems engineer costs as a benefit of appengine. Most startups don't need those profiles at the beginning. Most engineers can do that work at design time. It's not that difficult to setup a fail-safe cluster. I have done all of those optimizations you are talking and many more, like the most crazy things: minifying the JAR's with proguard so classpath scanning is faster and boot time is reduced. Again, I love appengine and have been using it since day one, but it's expensive. It looks like you have a lot of experience on appengine. Please, be kind share your experiences you hit 1 million users access your site every day. It will be very insightful. thanks On Wed, Jan 22, 2014 at 6:14 PM, Andrei Volgin vol...@spiraluniverse.comwrote: App Engine is very cheap for startups. I would even say it's a game-changer. I built two startups before PaaS became an option, and I can say with certainty that App Engine would have saved me millions of dollars each time. Most new applications can happily live within a free quota until they prove to be useful for a significant number of users. A well-built app will have a to serve a whole lot of users before it costs more than $200 per day on App Engine, and that's still cheaper than a single systems engineer or a DBA. I think that App Engine is difficult and expensive for less-experienced or less-qualified developers. Sloppy data models, unnecessary indexes, overly complex queries, unintended dependencies, large third-party libraries for simple tasks, wrong headers on static resources - these mistakes are not always noticeable when you run your own box, given how cheap and powerful the servers are these days. With App Engine these mistakes add up very quickly. On the other hand, App Engine gives you all the information you need to analyze your bill. Once you see that a certain item becomes significant, there are ways to optimize your application in order to reduce costs. I certainly advocate avoiding basic mistakes from day one, but there are certain optimizations that make sense only when volume picks up. For example, you can move a backend task to a Compute Engine instance, which is many times cheaper, but requires more work to set up and manage. Or you can split a complex data entity into two separate entities so that a minor change will not result in multiple datastore writes. Or you can unindex some properties and iterate through query results, saving on writes and data volume. Or you can set the correct chunk size on your queries - something that many developers probably forget to do. And so on. I am working on an app now that loads, processes and indexes 1 million web pages and creates app. 10 million datastore entities for less than $100 in App Engine costs. I don't know what your application does for your users, but that's a whole lot of processing power for a hundred bucks. Once we hit a million users or so, we will move some of our processing load to the Compute Engine, but the effort does not make economic sense before that. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Re: Snapchat
The support pricing is a very sore point for me too. I can see why when GAE becomes perfect and all the support calls are because of user errors this might make sense. This is not the case as of yet. For instance, both last Saturday and tonight I am hitting customer embarrassing and confidence loosing” hurdles because of GAE (see issues 10399 and 10503). Asking me, or any other paying user, to pay extra, so that I can timely report these issues and then GAE can timely repair them, and restore the service where is should have been in the first place, is adding insult to injury… PK http://www.gae123.com On January 22, 2014 at 6:04:21 PM, Coto Augosto C. (c...@me.com) wrote: Absolutely agree. I used to rely on app engine services more than heroku or other PaaS but now I am disappointed after see that I have been billed for pagespeed while it was disabled and I was billed 3 months for back-end instances type B2 while we had B1. Other issue I had was when our application was down for 2 days and we didn't have a door to report it. We had to paid for gold support ($400) for gold support, I called and they fixed the issue in 3 minutes by restarting the instance. Do we have to pay to fix issues in Google end? I am pretty disappointed now :( On Jan 22, 2014 10:11 PM, Doug Anderson d...@claystreet.com wrote: I think GAE is trying to remain competitive with Amazon Web Services etc... and not with CDNs. App Engine and Google Cloud Storage *is* competitive with Amazon Cloud Services EXCEPT those services offer tiered pricing (lower prices) for high volume clients... to my knowledge App Engine doesn't offer that (at least not publicly advertised). App Engine isn't much of a CDN as far as I can tell (I don't think that's a prime objective). It would be hard to argue against augmenting with an actual CDN where appropriate. Certainly technologies like Docker and OpenStack go a long way toward helping a lone wolf build a maintainable stack but I think you'll find that if you run that stack on Amazon's cloud (for instance) that GAE pricing *is* competitive. So I would contend that your pricing argument is more of a generic Anyone's Cloud vs Custom Hardware argument. I can certainly save a ton of money by storing data on local hard drives vs the cloud but then I have to worry about redundancy, drive and fan failures, rebuilds, backups etc. If you want multi-site redundancy and/or need rapid scaling/growth costs go up and the cloud starts to look intriguing again. Each (cloud and custom hardware) still has its place imo... On Wednesday, January 22, 2014 6:58:42 PM UTC-5, Rafael Sanches wrote: Hi Doug, Just correcting your phrase a little bit: that must be significant bandwidth even for YOU We've cut thousands of dollars out of our total bill by serving the images ourselves, through a real cdn. Appengine output bandwidth is much more expensive than almost any other cdn out there. Again, keeping this thread on topic, my advices only make sense if you have your server bills are in the thousands and are struggling with server costs. If you're an early stage startup with $100 bill or an overfunded startup or a big corporation, who cares? :) thanks rafa On Wed, Jan 22, 2014 at 3:53 PM, Doug Anderson do...@claystreet.com wrote: Yes, the tests I conducted were on the production server. I'd even be content if the resized images used the same default (quality=85) as the Images service. A switch to a more reasonable default would instantly cut all dynamically served images to nearly 1/2 the size... that must be significant bandwidth even for Google. It's either an oversight on Google's part OR they deliberately chose not to utilize the extra CPU bandwidth required for additional compression (???). Serving yourself allows additional flexibility (such as in your gist) but you don't get the cost benefits of the dynamic image service (no CPU charges) On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote: Doug, Does that behaviour also happens in production? Compare prod vs dev. That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting. thanks rafa On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson do...@claystreet.com wrote: Rafael Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images? I filed the issue below a while ago and it has seemingly been ignored by Google. In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it). Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85. My app saves a large reference image (1440x1080) and I use dynamic image serving for a
