dj-kenpo Posted August 18, 2007 Share Posted August 18, 2007 (take this lightly, I'm not an idiot, so yes I know there's no deffinate answer!) how do you tell how much cpu your app requires? can anyone give examples as to user count/ app complexity? I'm doign a content management system, right now mostly for friends while I beta it, and it's doing fine with 10+ users on shared hosting. the front end is slowly being converted so it's all cached, so mostly html except for when soemthign changes and is rebuilt. the backend is not insane, but not light either mysql calls + lotta looping arrays etc. image manipulation scripts that are pretty long running building 8 different images for each one added sometimes (various thumbnails...) so when does someone switch from shared-> vps -> dedicated? what sort of numbers slash complexity would you wager for YOUR app...? I'd like to avoid paying $100/month as long as possible, but obviously also not go that route to soon if $20 will cut it Quote Link to comment Share on other sites More sharing options...
phpknight Posted August 18, 2007 Share Posted August 18, 2007 I would just let speed determine when to make the move. When your site is too slow (or your database hits max_questions), it is time to go. In fact, I went straight from shared to managed dedicated (for a speed reason unrelated to the size of my site but bad service, lol). It is not perfect yet, but I noticed immediately that it is a lot better. You can get somebody on the phone in a minute instead of waiting on hold for 29 minutes only to get somebody on the phone who is clueless. I have done pretty extensive testing on image manipulation, specifically resizing large images. If you can post some times about what you are doing and how long it typically takes, I can let you know what sort of performance I am getting. IMHO, it sounds like you are already dissatisfied with your shared host. If you have the money, don't mess around with vps. You could end up in a bottleneck just as well. Quote Link to comment Share on other sites More sharing options...
dj-kenpo Posted August 18, 2007 Author Share Posted August 18, 2007 that's the problem at this point I just have friends on it, so I'm not rolling in the money for the project. I'm on dreamhost shared right now and no, I'm not satisfied with it, but there doesn't seem to be much better. mediatemple seems ok, but also has it's issues, most other shared hosts are crap, low storage/andwidth for higher cost. the vps would be another bottleneck but at say $50-100/month atleast nto crazy in price. I'm even considering a server colocation and just throwing in a 1 or 2ghz system on it, it would be cheaper then a comparible dedicated, and really, probably not that many issues. but that's all off topic... some of my issues are in say a simple resize/crop, taking a 2megapixel digicam image, inside a folde,r maybe there's 200 images, then runnign it through a first crop, that make sit either 500wide or 500px tall (depends on portrait or landscape) as well as a cropped 140px x 105px thumb. simpel really, but on both my laptop (1.3ghz pentium mobile, equiv to 2.2ghz p4) and on dreamhost, I get about 19 images and then a stall a 30 second, script kill. not a huge issue, I coded in a line to make it stop at 15 then give a button to continue onto the next 15, but on a vps or shared this *might* not be as much of an issue? what sort of speed do you get comparativly then, as you asked for an example. Quote Link to comment Share on other sites More sharing options...
phpknight Posted August 18, 2007 Share Posted August 18, 2007 Well, you can increase the script timeout with a set_ini call. To give you an example, I can resize a complicated png 5000x5000 image (18 MB) to 500x500 thumbnails 20x, saving separate files, in 43 seconds. I can resize a 2000x2000 (4.3 MB) to the same size 20x in 11.5 seconds. I am not sure how fast this is because I never tried it on the shared server, but considering the size of the images in MB, I thought it was pretty quick. Let me know if that helps or not and what you think of the speed. Quote Link to comment Share on other sites More sharing options...
dj-kenpo Posted August 18, 2007 Author Share Posted August 18, 2007 acctually, that doesn't really seem any faster than a shared host. I guess shared hosts (some) burst up in speed perhaps? I guess the difference would come in if you had 10 users trying to do this all around the same time, and I had 10 years trying to do this all around the same time, then yours would be faster and mine probably wouldn't run at all.. I'm guessing anyways. that does in a way help, and also not, it still leaves me very confused on the issue, in a way, even more so now. Quote Link to comment Share on other sites More sharing options...
Hypnos Posted August 18, 2007 Share Posted August 18, 2007 CPU usage is always the issue with popular shared hosts like Dreamhost. You normally can't reach your bandwidth limit without exceding a CPU quota. Image manipulation is the largest CPU hog you will face. I can only hope you're not doing a resize per load, and that you're actually saving the output of the resize to the file system. If your site does get popular, you might want to write a queue system to resize images in the background. That way you can limit how many resizes are happening at once. MySQL selects will not be an issue on shared hosting, for tables under 100k rows. If you want to tweak your page code for faster execution, put your logic in a while loop and put a timer on it. If you need access to more CPU power, you may want to try researching lesser known hosts, where there are fewer clients per host. Just make sure they aren't a reseller of someone else's. Quote Link to comment Share on other sites More sharing options...
dj-kenpo Posted August 18, 2007 Author Share Posted August 18, 2007 well, that is an issue then. the images are fine, render once I always say, but the 100k db limit. I'm keeping my own site stats and it really doens't take long to reach 100,000 hits for a website, so the table will reach 100k, for that part of the table alone, very soon. bots are kept in a seperate table and 1 row per day for ALL bots, so that's not bad, 365 rows per year per user, but the main human stats table is growing fast. not sure if I should cut it up and create a seperate table for daily stats and then have it delete the extra records from the main table, so it works as a sort of temp space... or just say screw it and get more server horse power... the problem with creating daily stats then becomes how do you store that info (ie top 20 pg view, top 20 referrers + normal hit counts) so that it's also available for a monthly view. storing it as a text field for the 20 items wouldn't work cuz then I couldn't sort 30 days of it well, or I could? I guess php can break the text into array data again but that seems really round about... ahhh cpu.. how you cost me. Quote Link to comment Share on other sites More sharing options...
Hypnos Posted August 18, 2007 Share Posted August 18, 2007 If you aren't selecting from that table for every page, I don't think it will be an issue. Selecting from large tables (especially without indexes) is what you want to avoid. Total DB size doesn't matter too much. Quote Link to comment Share on other sites More sharing options...
dj-kenpo Posted August 18, 2007 Author Share Posted August 18, 2007 unfortunetly I am selecting from the table on every page load. the system checks if a user already has a session id by searching the table for a session id on this day. if so, it increments the click count by 1, otherwise it inserts a new entry. so it will cause the front end to become slow. right now I have an index on session_id (32 char) user_id and timestamp. I'm worried about 1 year form now when it's ready to burst Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.