search

onaseef / yomobi

YoMobi Mobile Builder Platform
http://www.yomobi.com
2 stars 2 forks source link

Please check New Relic results for areas where can improve response time. #256

Open onaseef opened 12 years ago

onaseef commented 12 years ago

I forwarded you the email from new relic. It says our response time is 8.8 seconds to load a site, which hopefully we can improve on. When you've had a chance to look at it, please let me know your thoughts.

gilbert commented 12 years ago

This is most likely due to the number of requests the browser client has to make. Solving this would require implementing the sprockets library, which aggregates and compresses javascript and css files. This would take up to 4 hours to do.

onaseef commented 12 years ago

What do you suppose the ROI in terms of speed will be for this and how sure are you that you have isolated the cause of the slowness and why was sprockets not initially implemented?

Sent from my iPhone

On May 14, 2012, at 8:40 PM, Gilbert reply@reply.github.com wrote:

This is most likely due to the number of requests the browser client has to make. Solving this would require implementing the sprockets library, which aggregates and compresses javascript and css files. This would take up to 4 hours to do.

Reply to this email directly or view it on GitHub: https://github.com/onaseef/yomobi/issues/256#issuecomment-5706566

gilbert commented 12 years ago

As we discussed a bit before, page load optimization is a separate aspect of web development. It only makes sense to do it once you have all your site's assets in place.

If you look at this tool's results, you'll see that most of the time is spent making http requests. The green part of a bar is the time of the request, while the blue part is the time of the actual download. If all those javascript files were to be concatenated, there would be one bar with a bit of green and more blue, taking less time overall.

I can't estimate a specific amount of time that it will save, only that it will be one step faster. This and icon sprites are the lowest hanging fruit. Other things that may speed things up are listed here.

onaseef commented 12 years ago

What are icon sprites?

How much work would it be to move the icon files from being stored on Heroku to being in an AWS bucket, which I imagine has greater throughput? That would also make it easier to add new icons without having to do a push to Heroku and allow in the future for user uploaded custom icons.

Sent from my iPhone

On May 15, 2012, at 9:33 AM, Gilbert reply@reply.github.com wrote:

As we discussed a bit before, page load optimization is a separate aspect of web development. It only makes sense to do it once you have all your site's assets in place.

If you look at this tool's results, you'll see that most of the time is spent making http requests. The green part of a bar is the time of the request, while the blue part is the time of the actual download. If all those javascript files were to be concatenated, there would be one bar with a bit of green and more blue, taking less time overall.

I can't estimate a specific amount of time that it will save, only that it will be one step faster. This and icon sprites are the lowest hanging fruit. Other things that may speed things up are listed here.

Reply to this email directly or view it on GitHub: https://github.com/onaseef/yomobi/issues/256#issuecomment-5717288

gilbert commented 12 years ago

Icon sprites are another way of reducing the number of http requests. For example, there about 20 standard yomobi icons, each of which must be requested individually, since they are each contained in their own file. By manually combining these files into a single file (usually through photoshop), the browser only has to make one request for all 20 icons. It only makes sense to do this for the standard icons, since they are the most common.

Moving the icons to AWS might make the app server available to more users, but will probably increase throughput only a little. It would take up to 2.5 hours to do.

onaseef commented 12 years ago

Aggregating the CSS and JS files seems like a good idea. I would like to move the icons to AWS as part of the larger goal of allowing users to upload their own custom icons. A lot of the work for custom icons is in the custom-icon branch. The stopping point was that the icons are located on the heroku server and so 2 difference mechanisms would be needed to get the icon files. One to load from heroku if the file is from our library and one to load from AWS if the file is a custom user image.

If you were to use the code in the custom-icon, how long would it take altogether to move the existing icons to AWS with backwards compatibility which I think can be accomplished by leaving the icons also on the server, and implementing the custom icon feature?

gilbert commented 12 years ago

Oops. Apparently hitting ctrl-enter submits the form (I pressed enter a few times with my finger on the control key).

Anyways, what was done in custom-icon? I'm looking at it, but all I see is a bit of code that writes an uploaded file to the local filesystem (which will not work on heroku). I'm probably missing something.

onaseef commented 12 years ago

Some UI changes were added to the "Change Icon" dialog in the widget editor that allows the user to select a file to upload as an icon. It than uses a library to convert the image into the the right dimensions for an icon and saves it. Than it was discovered that they couldn't save to the local file system with heroku, so they thought they'd have to change the core mechanism to support user uploaded vs yomobi library icons.

From what I saw, the UI and transformation of the image to an icon are in place, and what needs work is storing it to AWS and knowing to pick the right image.

onaseef commented 12 years ago

Do you think the existing work gets you most of the way to implementing user uploaded custom icons? And if so, how much time do you think that would be?

gilbert commented 12 years ago

The custom-icon changes add a bunch of code that implements duplicate functionality. If they took a closer look at the project, they would have seen it uses the paperclip gem, which supports resizing and uploading to AWS.

Most of the icon upload work resides in the frontend. It looks like most of the code they contributed was in the backend. I can't find the changes to the UI. Basically, based on this commit, I don't see anything that will help reduce development time.

My original estimate is stated here. I don't have the time to take it on.